Produced/Consumed tags for a second CompactLogix

[ceilingwalker]

Hello all. I have a 1769-L16 that I inserted a 1769-L35E into. I was expecting it to create module defined tags automatically in my controller tags, like it did for my PowerFlex 525 (for example) but it didn't. Should I have used a generic ethernet module and then created an image table? Not sure exactly how to do this. Thank you.

 

[JeremyM]

That "image table" you speak of is the tag you created at the controller scope.

When a produce/consume connection is initiated by a consumer, a deep conversation between it and the producer takes placed. This includes information about the constitution of the data exchanged (UDT name, size). If the parties are mutually agreeable in having a) a definition of said type at each endpoint and b) an instance of each at the endpoint, then an endless conversation containing precisely the bits defined in those types will ensue*.

Which is to say: This exchange takes place after *both* controllers have the same shared data type, data type name, and data type size.


* until a cable is unplugged, a cable is broken, network switch(es) linking the nodes fails, a PLC fails, both PLC fails, or the alleged heat death of the universe occurs**
** whichever comes first

 

[cardosocea]

Something tells me that you come from a Siemens background... did you find the manual for the produced consumed tag creation? It's fairly straightforward to do and, in my honest opinion, better than the mechanism you were considering. On the other hand if you just need data with a slow update, you can always use messaging between them.

 

[ceilingwalker]

Something tells me that you come from a Siemens background... did you find the manual for the produced consumed tag creation? It's fairly straightforward to do and, in my honest opinion, better than the mechanism you were considering. On the other hand if you just need data with a slow update, you can always use messaging between them.

I don't need lightening speed however, I need the most reliable. These PLC's will be driving a robot using DI's from station to station. The more I read here on the forum the more it appears the most reliable means with RS is produced/consumed tags. When I created the Fanuc Robot Ethernet connection in the one PLC, defined my I/O image table, it created tags for me. I just assumed using this AB PLC it would have done the same, if not more.

 

[cardosocea]

No it doesn't do it for you... but that isn't quite common in other PLCs either as you'd expose all of the memory??



This manual seems pretty good to get you started.



https://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm011_-en-p.pdf

 

[ceilingwalker]

No it doesn't do it for you... but that isn't quite common in other PLCs either as you'd expose all of the memory??



This manual seems pretty good to get you started.



https://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm011_-en-p.pdf

Thanks much!

 

[JeremyM]

Messaging and Produce/Consume are as reliable as the network they’re used on.

 

[PreLC]

Messaging

Beware of scan based messaging over complex networks. Always determine the rate of messaging via timers/counters, don't leave that to the scantime.

 

[OkiePC]

Another option that might be worth consideration is a Listen Only connection to the robot I/O data in both controllers.

Output modules can only have one "Owner" but other PLCs can establish a listen only connection to them. If the data that is needed among the multiple PLCs exclusively resides in the Robot I/O image, then this method can allow all the PLCs to see the data at a very fast RPI even if one of the PLCs goes offline.

Ignore this suggestion if your application needs the PLCs to exchange other data outside of the robot I/O image.

 

[JeremyM]

Beware of scan based messaging over complex networks. Always determine the rate of messaging via timers/counters, don't leave that to the scantime.

In that case, periodic tasking. If the deadline is softer, timers are workable, agreed.

 

[ceilingwalker]

Thank you everyone for your input!