Can RSLogix5000 Message Tags be reused with different instructions?

I want to read several disparate values of different data types from a second PLC with the MSG instruction via CIP Data Table Read message type.


Do I need to create a separate Message tag for each of these MSG instructions, or can I reuse a MSG tag as long as only one instruction is executing at a time (i.e. if they execute sequentially based on a counter that is incremented after the DN bit of each one executes)?


Thanks!

The answer: depends.

It's usually better to lead off with the specifics of what you are trying to accomplish rather than a general question like this. You can manipulate the parameters of a MSG in a way where you could reuse the same MSG for multiple purposes, I'll give you an example of one I did not so long ago.

I had 6 machines that were more or less identical. Recipes can be entered on any of them, but rather than enter the recipe on all 6, each had the ability to send the recipe via MSG to any/all of the other 5 machines. The tags to receive the recipe data remotely were the same in all 6 machines, so I had an array of strings that contained the path to each of the machines. I used one message, but change the path each time data needed to be sent.

I look back on that and think, I could have had 5 MSG instructions in each machine, that would have been straightforward, which is usually the best way. In this case, I figured that I needed to debug one message, after that, I just need to get the path right for the rest. No issue with one MSG being mis-configured. Now this customer is adding 2 more machines, so now I just need to enter the path into array elements 7 and 8 for the new machines.

You really need to understand the consequences of sharing tags with other instructions. It's usually best practice not to share tags between instructions, though there are situations were it works, as long as you know what you are doing. Just be careful about adding mystery for the end user. Document it well and test it thoroughly. And when I say document it, write why you did what you did, not what you did. The "why" goes a long way.

Thanks for your fast reply. I'll try to clarify:


A vendor provided a pump station controller PLC. I am tasked with retrieving various properties (is pump running, runtime hours, flow rate, etc) from the PLC and transmit this data to a remote location, as well as modify various settings within it from the remote location (enable/disable pump, set desired speed, etc).



I can't access the vendor's PLC with RSLogix5000 because it's firmware is newer than our license. Also, I would prefer not to make any modifications to their program since it was provided as part of a "package". (i.e. adding Produced Tags to their PLC is not an option.)



They provided a detailed tag list.



I have my own dedicated L30ER PLC which is to be used for the telemetry task.


Their PLC uses a custom datatype tag to store the pump info for each of 4 pumps. Instead of trying to retrieve the entire custom tag (which includes strings, thus making it a large block), I would rather retrieve only the few basic bool, int, and real tags that we need. These values are not sequentially stored within the parent tag, so I can't retrieve all the properties in a block read. Instead, I have to read each property separately.


It's OK if the read process is slow (i.e. multiple seconds between polling).


Since there are possibly 20-40 tags to read, I was hoping to avoid creating a separate Message tag for each read instruction, and instead, recycle a single Message tag by activating a different MSG instruction upon the previous instruction's DN bit being asserted, in combination with a timer to pace the whole process.


Does this make sense?

I would not reuse MSG tag like you described.
Instead, you should manipulate with Message parameters (path and/or remote element) to get this data.
See publication 1756-PM012, Chapter 3

Contr_Conn said:

I would not reuse MSG tag like you described.
Instead, you should manipulate with Message parameters (path and/or remote element) to get this data.
See publication 1756-PM012, Chapter 3

Click to expand...

This does not appear to show any way to alter the local element(s) being used, only the remote ones. Unless I'm missing something this would mean you still need a separate MSG for each element type (bool, int, real, etc).

This is definitely the correct way to re-use a MSG tag though.

This does not appear to show any way to alter the local element(s) being used,

Click to expand...

Check page 30, it shows how to use message.LocalIndex tag
However, this will not work with different data types.

Have each message instruction use its own array, but after a successful Read MOV that array to Generic_Array for the rest of the program to use like you want.

Contr_Conn said:

Check page 30, it shows how to use message.LocalIndex tag
However, this will not work with different data types.

Click to expand...

The LocalIndex allows you to change what position inside the local [source/destination] array; I see no indication you can actually change what tag is being used though (which is one reason why you can't change element type).

This makes me curious as to how the local tag reference is actually being stored since it doesn't seem to be anywhere in the MESSAGE tag -- is it part of the MSG instruction instead? If so OPs idea of re-using the tag with multiple MSG might be theoretically viable (though I would definitely not recommend actually doing it in practice).

Thanks everyone, I will proceed as instructed based on the 1756-PM012 publication.

UPDATE: the more I look into this project, the less happy I am with transferring values one at a time. There are 4 pumps and 2 wetwells, and the vendor-supplied PLC contains basically four user-defined data structures representing these systems.


There are a total of about 300 tag values, including bool, real, and int.


Without access to the vendor-supplied PLC to determine the data structures' physical layouts and element order, how could I read these in blocks? I'm assuming is it impossible since I don't know the element order. I'm assuming my PLC must contain the same UDT with the same order of elements and data types in order to do a block read. Or are matching element **names** sufficient to perform a block read of a UDT regardless of element order?

ryangriggs said:

I'm assuming my PLC must contain the same UDT with the same order of elements and data types in order to do a block read. Or are matching element **names** sufficient to perform a block read of a UDT regardless of element order?

Click to expand...

A CIP Data Table Read (or Write) uses a CRC-16 check to verify the data type matches on both sides. The CRC is generated from a string which is constructed by concatenating the names and data types of the udt in order.

tl;dr your assumption is correct -- the udt must match exactly.

cf this thread

I think you need an activated version of RSLinx to do this. Not sure if "RSLinx Lite" does this. But it might.

If you right-click on the controller in the RSWho window of RSLinx you will see an option called "Data Monitor". That opens a sort of tag window that allows you to see the tags in the controller along with the current data and the data type. Using this, you should be able to identify the UDT structure of an existing tag.

OG