MSG vs Produced/Consumed Tags (Controllogix PLCs)

I've been asked to look into an application that involves plc communication. All of the processors involved are controllogix.

I spoke with Rockwell tech support and was told that there really aren't any differences between the MSG instruction and Produced/Consumed tags (that's it's personal choice); however, another programmer told me that the produced/consumed tags are a more efficient way to communicate; they use less bandwidth, no queue headaches, and are a lot faster.



These seem to be conflicting responses, and have left me puzzled.

My vote is for produced/consumed tags.

Produced/consumed is a lot simpler to manage. One thing to consider is that I don't believe that you can make changes to produced/consumed tags while online (it's been a while since I've worked with them) so make sure to set everything up in advance, with extra empty tags (for example, if you are currently using an array like DINT[10], configure the produced/consumed to use a DINT[20] so you can easily add in the things your forgot later).

+1 for the Produced/Consumed. Another thing to mention is connection error checking. you can monitor the status of the connection and if you loose connection to the other processor you can set a fault in your PLC to bring everything to a stop. Of course that is for mission critical type stuff but it is easier than doing a heart beat type of routine.

With the Implicit Messaging (Produced/Consumed tags), both connected devices must support implicit messaging.
The connection is continuously cyclic.
For the connection, everything must be predefined before the connection is started, namely:
- The connection size and period (RPI).
- The function of each connected device (scanner or adapter, that is connection originator or slave). Multicast or unicast adapter.
- The data source and/or destination on both sides.
Neither of these may be changed from within the program.

With the Explicit Messaging (MSG instruction), the connection is done on demand and under the user program control.
Each of the connected devices can initiate data exchange in any direction, determine the data size to exchange, and map the data source and destination.

Since the Explicit Messaging is limited to only necessary data and is not continuous, it actually uses less bandwidth than Implicit Messaging (unless both are executed with the same period and exchange the same amount of data).

You've received some good advice in the previous posts to consider. One thing I'd like to add is that keshik is correct; Produced/Consumed tag additions/edits require a download. It is nearly impossible to take a couple of PLCs offline at our facility, so I opted for MSG instructions.

If you do go with Produced/Consumed tags, I'd suggest starting out with an array containing a few more elements than you need to avoid downloading every time you need to use a few more tags. If you use MSG, consider the message manager logic that Rockwell has in their technotes. The message manager is key if hitting multiple PLCs. There may even be a link if you do a search of this site.

Click here to see a thread that refers to setting up a message manager. The first post includes a link to the Logix5000 controllers message programming manual.

Justin OtherPLC said:

I spoke with Rockwell tech support and was told that there really aren't any differences between the MSG instruction and Produced/Consumed tags (that's it's personal choice);

Click to expand...

That's not good advice coming from RA - There are lots of differences, and knowing those differences will sway your choice as to what you use for each circumstance. Many projects use both P/C and Nessaging side by side....

It's a case of "horses for courses"....

Produced/Consumed tags can only go up to 500 bytes of data - that's 125 DINTs or REALs, 250 INTs, or 500 SINTs (although if it's ControlLogix to ControlLogix you'll be using DINTs for efficient usage at either end). If your data size is smaller, then it's an advantage to use UDTs to compact data into single larger tags. That will reduce the number of "connections" you consume.
Produced/Consumed tags will be transferred continuously, irrespective if the data has changed or not.
Produced/Consumed tags continue to work if either, or both, controllers are in program mode. You can add a "Connection_Status" tag to detect the other party is running, and the connection is valid.
Data change can trigger an Event Task in the consumer.

Messaged tags can be any size, although transported in 500 byte packets, they report .DN when the whole message has been transferred.
Messages can use a "temporary" connection, which is released after the message is completed, allowing the connection to be re-used.
You can trigger the message at any time you like, there's no justification in sending the same data values repeatedly, and you can elect to send the data at much less frequent intervals, or at specific times, or when a particular event occurs, for example...
You would have to set up some form of "handshaking" to detect that the controller you are reading from and writing to is in Run Mode.
Data change in a messaged tag can't trigger an event task, you would have to write code to detect changes in data.

Justin OtherPLC said:

.... another programmer told me that the produced/consumed tags are a more efficient way to communicate; they use less bandwidth, no queue headaches, and are a lot faster.

Click to expand...

Produced/Consumed tags will use more bandwidth than a slower running message instruction.
Message instructions that are not continuously re-triggered generally don't cause queue headaches.
"Faster" needs qualifying, sure, P/C is deterministic, and goes at the RPI rate specified.

In summary, you use whichever method is best for your application.