L62 ControlLogix communication with L36ERM CompactLogix

Hi All,

Fairly new to PLCs and in particular communications between processors. I'll explain the problem best as I can.

I have a new water treatment plant onsite with a 1769-L36ERM CompactLogix 5370 controller (Rev 30.014). The controller is connected to a Stratix switch along with the remote IO and VSDs. The control system is basically air gapped from the rest of the plant and uses IP addresses in the range of 10.30.53.X. The PLC program opens in Studio 5000 Logix Designer.

There is an existing water treatment plant onsite with a 1756-L62 ControlLogix5562 controller (Rev 16.7). The controller is connected to an existing Ethernet network for inter-PLC communications with IP addresses in the range of 192.168.11.X. In rack 1 of this controller is the ethernet module for connecting to the 192.168.11.X network (1756-ENBT/A) and I/O cards. There are no free slots in this rack. The remaining racks (2-5) are connected via ControlNet.

Basically I need to be able to communicate between the L36 and L62 controllers for exchanging a few key values (tanks levels, flows, etc).

The original intent was that the new L36 would be connected (from the Stratix) to the 192.168.11.x network switch, however the plant vendor did not know how to configure the Stratix for multiple networks and did not want to re-address all of their 10.30.53.x modules. Instead we decided to join the L62 into the 10.30.53.x network.

I have installed an ethernet module (1756-EN2T) in rack 4 (ControlNet) of the L62 panel and assigned an IP address in the 10.30.53.x range. I downloaded the program and the ethernet module is running without any faults. That ethernet module is connected to the Stratix switch at the new plant.

I am now attempting to add the L36 as a new module under the ethernet card, however in the "Select Module" dialogue box under the expanded list for "Communications" I cannot find 1769-L36ERM. It does list a 1769-L35E, however that is greyed out.

I'm wondering if I need to add the Stratix switch first? Or could this be a firmware issue? Or could this be because I've placed the ethernet module in a ControlNet rack instead of rack 1.

Any help would be greatly appreciated.

Welcome to the forum! The problem you have is that the older-firmware 1756-L62 doesn't know about the existence of the newer 5370 Compact Logix - it was released at v20, and your Control Logix is at v16. So you'll be able to add the 1756-L62 to the ethernet tree of the Compact Logix, but not the other way around.

The good news is, you can put just about any compact logix controller in the L62's ethernet tree, and it should work. The newer compact logix PLC's were designed with this in mind - though their architecture is somewhat different, if it receives data aimed at an old-style compact logix it its own IP address, it will assume that the data was meant for it, and respond in kind.

So, you should be able to go ahead and add the 1769-L35E to your ethernet tree, and set up some produced/consumed tags with no problems. I've done this before in very similar circumstances, and it worked right off the bat.

As to why the L35E is greyed out, I suspect that it may be because you say you've selected communication modules. The 1769-L35E is not a communication module, it's a PLC - so it's filtering it out of your list. This is only a guess - personally when I'm adding a device I don't bother with categories, I just start typing the part number in the filter box at the top until I see what I want. Try that, and see how you get on.

Your other option would be to flash the firmware of the L62 up to a newer version. Off the top of my head I don't know how high you can flash them, but it'll be at least v20, which should get you the 5370 series Compact Logix available. Of course, that procedure is not without risk, and if you're new to PLC's I wouldn't be jumping in that way without giving it proper consideration. If you entertain that idea, remember that the program in the PLC is erased when flashing firmware and if you haven't made a backup first you are completely rubber ducked.

Welcome to the PLCTalk forum community !

You can communicate between that ControlLogix and CompactLogix with unscheduled Message (MSG) instructions, reading and writing various Tags.

But you won't be able to use Produced/Consumed Tag data exchange, which works on a cyclic time basis like I/O connections do.

You've put your finger on the reason why: ControlLogix does not support more than one network between a CPU and an I/O device.

You could put the CompactLogix into the I/O tree and use cyclic Produced/Consumed Tags if the 1756-EN2T was in the same chassis with the 1756-L61 CPU. But because it's in a chassis linked by a ControlNet link, you can't "schedule" such a connection.

You can definitely use MSG instructions, though. If you can provide some slot numbers (location of the CPU, location of the ENBT) we can sort out the Path strings.

About the CompactLogix CPU not being in the list of selectable modules: the older 1756-L61 software doesn't know about the modern CompactLogix. The common workaround is to enter a 1769-L35E into the I/O tree to "fake out" the ControlLogix.

Until recently, Studio 5000 would let you create and attempt to run some unsupported network architectures, like putting an Ethernet "scanner" into a remote ControlNet chassis. Evidently v30 grayed out connections you can't run successfully.

Thank you for all the information so quickly! Very much appreciated. I will try to add a L35 in the first instance. Cheers

Ken Roach said:

You could put the CompactLogix into the I/O tree and use cyclic Produced/Consumed Tags if the 1756-EN2T was in the same chassis with the 1756-L61 CPU. But because it's in a chassis linked by a ControlNet link, you can't "schedule" such a connection.

Click to expand...

Whoops, skimmed over the part where the ethernet module wasn't in the local chassis. Ken is correct, produced/consumed tags aren't an option for you here.

What size is the chassis containing the processor? Could you replace it with a larger chassis? Changing the chassis size in the PLC program is a fairly trivial task, if you have the physical space to do it, that might be an option. It comes at the cost of a new chassis, and since explicit messaging is a possibility at zero cost, perhaps you'd be better to go that way.

Anecdote: I earned this knowledge the hard way.

I never occurred to me to try to bridge scheduled networks using a 1756 chassis, just because the conventional (and only) method requires the network's "root" modules to be in the chassis with the CPU. I knew that ControlNets could be bridged for messaging, but not for schedules, because I'd done some of the earliest ControlNet systems with PLC-5C15 and ControlLogix. I taught networking seminars that followed the conventional and correct rules.

But a customer did so, putting a 1756-ENBT into a remote chassis of a redundant ControlLogix, then connecting several (very large) Mitsubishi VFDs as EtherNet/IP I/O devices.

It turns out they were relying on a graphic in a brochure that described CIP networking features and benefits, and confusingly showed a green highlighted Ethernet connection to a remote ControlNet-connected chassis. They didn't ask Tech Support, or me, or consult any manuals, just that highlighted green line on a graphic in a two-page glossy brochure.

The worst part is that... it worked.

Well, it worked for a while, because the ControlLogix would create the connection but would use processor buffer resources that weren't permanently allocated to the connection. The drives connected and ran correctly until those buffers were needed by something else, commonly an instance of RSLogix 5000, or the new AssetCentre system we were installing on the same site. The drives, of course, had a 1st generation Ethernet interface from Mitsubishi, so there was vigorous finger-pointing.

In that system, we couldn't use messaging to handle the VFDs and had to find a hardwired workaround.

But in OP's case, if this is a continuous process system for which shutdowns and reschedules and reboots are not ideal, then MSG instructions will serve his purposes well. There are numerous threads on the Forum with great ideas about how to name your tags that participate in MSG instruction data transfer, and how to implement timeouts that work and are easy to understand ten years from now when you look at them again.