Consume Tags on L55 v12 from a Cmplx 5380 producer

Having some trouble getting a v12 L55 processor to consume tags from a new CompactLogix L306ER (5380) v29 producer.

This document (http://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm011_-en-p.pdf) says that because the newer controllers won't exist in pre-v24 firmware that you must represent the controller as another type of controller that has an on-board ethernet port, so I have attempted the 1769-L32E, but it's not working.

Yes, worst case I'll have to change it to a MSG, but it will break their standard.

I'd call TechConnect and ask if they're considering v12 when they say "pre v-24 firmware" (I can hear them saying that L55 is discontinued from 2011). I think firmware v12 is too old and declaring a surrogate controller will not work in this case.

It's a long shot but maybe a firmware upgrade could be helpful. As far I remember, L55 accepts v16.

I did call and they can't give a clear answer.
I changed the F/w to v16 and it works, so I am thinking it's a firmware issue and I may just have to use messaging.

phuz said:

I did call and they can't give a clear answer.
I changed the F/w to v16 and it works, so I am thinking it's a firmware issue and I may just have to use messaging.

Click to expand...

If V16 got it working, why do you think you'll need messaging ?

Can't the facility accept V16 over V12 for the L55 ?

daba said:

If V16 got it working, why do you think you'll need messaging ?

Can't the facility accept V16 over V12 for the L55 ?

Click to expand...

In a validated environment, changing firmware is a much bigger deal than you'd think.

You may break my long-standing claim that Produced/Consumed Tag connection problems are never firmware revision related !

What sort of connection error code did you get when you were Consuming the tags with a v12 controller ?

In V12, CompactLogix controllers were very new and they always behaved like the were in Slot 0 of a backplane.

I can see having the V12 controller unable to Consume tags being Produced by a modern CompactLogix. If it were the other way around, I would expect it to succeed.

EDIT: re-read question, got things backwards.

Ken Roach said:

You may break my long-standing claim that Produced/Consumed Tag connection problems are never firmware revision related !

What sort of connection error code did you get when you were Consuming the tags with a v12 controller ?

In V12, CompactLogix controllers were very new and they always behaved like the were in Slot 0 of a backplane.

I can see having the V12 controller unable to Consume tags being Produced by a modern CompactLogix. If it were the other way around, I would expect it to succeed.

EDIT: re-read question, got things backwards.

Click to expand...

Does it matter what slot the producing controller is in ?

Does it matter what the model, catalog, firmware revision the producing controller is specified as in the consumer ?

Aren't all produced tags formatted to adhere to the CIP protocol ?

I really can't see an issue, unless later controllers have broken the mould for the Producer/Consumer spec....

EDIT : Surely there's no requirement for the "producer" to be identifiable by type, isn't it just the case that there is a standard produced tag, from the path specified, for consumers to consume, I don't think the consumer checks that the producer is the correct module specified in the consumer's I/O configuration, it would be illogical, but I may be wrong....

phuz said:

In a validated environment, changing firmware is a much bigger deal than you'd think.

Click to expand...

Changing firmware revision in your "validated environment" might be a deal less than changing the code.

I can't think of any issues going from V12 to V16... but changing the data transfer code has higher risks...

The slot number of the Producing controller is definitely important, as the Consuming controller needs to request the connection from the Producer and negotiate the Tag Name and datatype and RPI for the connection. As far as I know, modern controllers still accept being addressed as "backplane and Slot 0" for backward compatibility purposes.

The identity of the Producing controller should not matter, or at least it never has. It doesn't matter if it's an L1 or L55 or L6x or L7x or what the firmware revision is. Identity checking has never been part of Produced/Consumed tag connection establishment.

But now with the CPU and the Ethernet module considered to be at the same endpoint rather than in different slots (5370 and 5380 series CompactLogix and 5580 series ControlLogix), maybe the old V12 controller can't deal with that.

daba said:

I can't think of any issues going from V12 to V16... but changing the data transfer code has higher risks...

Click to expand...

I can offer a very specific V12 to V16 issue we experienced several years ago. This was (is) an -L55 with M08SE Sercos motion. The V12 fault handling was not correctly programmed, using MASR instead of MAFR and not turning off feedback (no MSF) in the event of a fault. This basically worked in V12, but not in V16. The V16 axis would become unresponsive, "locked-up", and most quickly fixed by cycling power on the whole system. Proper fault handling corrected the issue, though left us wary of V12 to V16 upgrades.

Yes, the controller is set to slot 0 (default).

I took the same v12 program and migrated it to v16 for testing and it immediately succeeded, so I would think the answer is old firmware.