Produce / Consume between two Logix generations

[Ken Roach]

Recent Forum member and very-good-question-asker /DesertSurf520 has a thread that started a discussion about Compact 5000 I/O, but branched off into setting up a training lab connection between a 1756-L55 and a 1769-L24ER.

I'd like to move that discussion to this separate thread, for clarity.

The most recent post was:

So, a little separate but not totally unrelated, for my lab, shouldn't I be able to add the compactlogix to my controllogix project and vice versa? But I only was able to add the controllogix to the compactlogix side? However, I have version 30 on the compactlogix and version 20 on the controllogix, do they have to be the same version?

 

[Ken Roach]

These are great questions.

In order to send a MSG instruction from one Logix-family controller to another over Ethernet, you don't need to have the controllers shown in the I/O Tree of each other's projects. It makes it easier, for sure: you select a name from the tree as the CIP Path destination, and you don't need to know any of the details of CIP Paths, or the classic Backplane and Virtual Backplane objects, or the various CIP Port Numbers.

But you can definitely do CIP messaging over Ethernet with MSG instructions just with good old dead-reckoning: enter the pairs of Port and Address values separated by commas.

The feature you do need an I/O Tree entry for is Produced/Consumed Tags. Rockwell uses the I/O Tree as the repository for the low-level originator and target information for both ordinary cyclic I/O connections and P/C Tag connections, so you need the device objects entered into that structure.

So let's take a look at that, starting with the assertion that Produced/Consumed Tag exchange is almost universally compatible between Logix family controllers from 1998 until today.

 

[Ken Roach]

I only was able to add the ControlLogix to the CompactLogix side? However, I have version 30 on the CompactLogix and version 20 on the ControlLogix.

Let's start from there.

You have a CompactLogix 1769-L24ER controller, with v30 firmware and Studio 5000 Logix Designer v30.

That CompactLogix is a member of the fourth generation of 1769 Compact I/O based controllers. Rockwell call these the "5370" family, where the "5000" means it's a member of Logix, the "3" means it's a CompactLogix, and the "70" means that it shares architecture, CPU chips, and capabilities with the 1756-L7x family of controllers.

Your ControlLogix is older; you say that it has v20 firmware, so it uses RSLogix 5000 v20 software. You're familiar with the RA change from "RSLogix 5000" to "Studio 5000 Logix Designer" naming after v20.

You've got one of the most rare ControlLogix: a 1756-L60M03SE, which iwas the smallest L6, glued permanently to a 3-axis SERCOS motion control module. It got the nickname "Mouse-Three" because the Disney account manager once referred to it as the "Emm-Oh-Three-Ess-Eee" like the Mickey Mouse Club melody. Thanks, Linda, for cementing that in my head.

It makes sense that the CompactLogix with v30 understands the original 1756 ControlLogix architecture and has an object in its I/O tree schema for the 1756-L6x, even specifically the "Mouse-Three".

When you insert a 1756 Ethernet module and 1756 chassis into the I/O tree for another controller, but you don't intend to use it for I/O module connections, set the connection type to "None" instead of "Rack Optimized". The object is going to be a bridge, not an endpoint.

When you inserted the remote CPU, you of course found all the older CPUs: 1756-L1, 1756-L55, and the 1756-L6x family.

But the reverse isn't true. RSLogix 5000 v20 was the last of its generation, and it doesn't recognize or include any objects in its software configuration for anything above v20.

That includes ControlLogix and CompactLogix that have the Ethernet port and EtherNet/IP object built directly into the CPU, and don't use a physical or virtual backplane to access it.

 

[Ken Roach]

So how can I put a "fourth generation" CompactLogix with v30 firmware and the EtherNet/IP port built right into the CPU object into the I/O tree of an old Disney-and-General-Motors specific ControlLogix ?

You substitute something it *does* know about and understand: the 1769-L35E CompactLogix, the first model with Ethernet onboard (physically and logically a daughtercard).

It really is that simple: insert a 1769-L35E with the IP address of the 1769-L24ER into the I/O tree of the RSLogix 5000 v20 for your 1756-L60M03SE.

You'll be able to use that object as the target for your MSG instructions, or as the Producing controller for a Consumed tag.

The fact that the L24ER doesn't have a virtual backplane with a CPU in Slot 0 (like the -L35E did) doesn't matter: it happily recognizes that a message sent to Slot 0 should be answered by itself.

The fact that the L24ER has v30 firmware instead of v20 firmware (like the -L35E did) does not, by itself, matter. The fact that you selected a 1769-L35E with v20 firmware from the drop-down hardware browser does not matter.

It can make a practical difference: a v20 controller can't consume a 64-bit Integer from a v30 controller, for example. But that's because the older controllers don't support 64-bit integers, not because there's a firmware version check as part of the establishment of the connection.

 

[mike3475]

Much thanks for your detailed explanation.

 

[desertsurf520]

Wow

Thanks Ken. You're a wealth of information. So, the Sercos processor I traded out because it is such an oddball but I got a good price on it for the lab. I put in a 1756-L55 A in the controllogix rack. I can upgrade the firmware with controlflash if it makes sense. Thats whay I did with the compactlogix controller. I have seen both ways but I am unsure which is better or simpler, msg instructions or produced and consumed tags. It seemed to me msg instructions were easier but I've been wrong before.

Anyways, I am helping a customer out that I do instrumentation work for. I've been instrumentation for years and I've done PLC programming but mostly on micro controller which are easier and not as many nuisances like Rockwell. I am trying to simulate the list project in my lab before I do it on site just so I can get a little more comfortable. So, thank you for clearing that up about the project tree. I will see what I can do to initiate msg instructions between the two.

 

[alan_505]

The L55 will only be able to be flashed to version 16.
Where as the L63 would be able to be flashed to version 20.

 

[desertsurf520]

ok. Can any of those serial port processors be flashed to above version 20?

 

[Ken Roach]

There's a lot of overlap between Logix families and generations, but my recollection is that:


1756-L55 supports up to version 16 firmware.

1756-L61 supports up to version 20 firmware.

1769-L24ER supports up to current firmware, which is v35.

 

[TheWaterboy]

To get a serial port at a higher version firmware you need a 5069-serial module on a 5380 series PLC.
I don't think the L24 has any serial option. (but if it does it must not have supported DF1 which was what I needed at that time).

 

[JeremyM]

You substitute something it *does* know about and understand: the 1769-L35E CompactLogix, the first model with Ethernet onboard (physically and logically a daughtercard).

It really is that simple: insert a 1769-L35E with the IP address of the 1769-L24ER into the I/O tree of the RSLogix 5000 v20 for your 1756-L60M03SE.

You'll be able to use that object as the target for your MSG instructions, or as the Producing controller for a Consumed tag.

The fact that the L24ER doesn't have a virtual backplane with a CPU in Slot 0 (like the -L35E did) doesn't matter: it happily recognizes that a message sent to Slot 0 should be answered by itself.

This is interesting information. I think it could inform a slightly improved way to handle something I already do.

It can make a practical difference: a v20 controller can't consume a 64-bit Integer from a v30 controller, for example. But that's because the older controllers don't support 64-bit integers, not because there's a firmware version check as part of the establishment of the connection.

It’s curious that Rockwell even limits primitives along firmware lines. The very protocol that ties their hardware together defines and uses them, as does IEC-61131.

 

[TheWaterboy]

But that's how you sell more hardware and anger your customers at the same time. It's very efficient.
(Man I'm getting grouchy in my old age)