CompactLogix - Read MSG to see the status of a integer in SLC 5/05 Processor

[Cydog]

Good Evening ,


I'm finally understanding a MSG instruction a little better.
My question is , I'm using a MSG read in a CompactLogix to see the status of a Integer in a SLC 5/05 . Should you use a MSG read,in a CompactLogix, just sit there on the rung , or should you use a timer to pulse the Message/ Read on and off ?


I took notice of several MSG instructions that there is timers that seem like they are updating the Message instructions .


If this is the case , why would this be done ? It seems to me , if you have a quick True / False transition on the SLC 500 that you could possibly miss capturing this on your Compactlogix MSG / Read.


Any thoughts and / or advice ?


Thanks so much for your help.

 

[daba]

If you are only using the one MSG Read of the SLC Integer, and there is no other messaging going on, then it will do no harm to use the MSG.DN bit to re-enable the message immediately. Note that having an unconditional rung enabling the MSG will result in it being executed just once only.

However, if there are other message instructions in the code, then you will need to let the comms processor handle them sequentially and prevent the message request stack from being full.

But you also have to consider the SLC itself, does that have multiple MSG instructions? If it does, then it will also have to be prevented from being overloaded on its comms processing.

In the SLC, message handling is performed once per scan cycle, in the "housekeeping" period, so can only service message requests at the same frequency as the scan cycle dictates.

Using a timer to enable the MSG instruction is the wisest thing to do, but you have to dertermine how "fast" your SLC Integer will be changing bits, and program your messages accordingly.

So, in this particular case, I would suggest that you program a MSG WRITE in the SLC, triggered by the integer value changing. That way you will overcome a potential problem that the integer changes again while an existing MSG is queued and/or being processed. Think of the data-change as an "event" to be acted upon, in this case, send the new value to the CompactLogix.

I don't usually advocate MSG WRITEs, as you lose traceability to where the data is coming from, so it is recommended to document the receiving tag to say where the source data is.

And since the SLC does not understand the "tag" data of CompactLogix, it will be necessary to use "Map PLC/SLC Messages" in the CompactLogix to "capture" the data address (e.g. N7:20), and convert to the CompactLogix tag.

 

[Cydog]

Thanks Daba ,

So you think it would be problematic if I just use the Read MSG , in the CompactLogix to capture the integer in the SLC 500 ?

Thanks so much ,

 

[Vlad Romanov]

Hi Cydog,

I would definitely recommend using a timer. If you're not sending critical data, I'm not sure why you'd use a write over a read from the CompactLogix; I would recommend using a read.

A message is inherently a non-deterministic way of sending data. It's definitely possible to "lose/miss" data using messages.

If there is a need to get data from this SLC rack, I would recommend converting it using a 1747-AENTR module. You can easily import your code and run it in the CompactLogix (Studio 5000). - Obviously check the firmware / hardware if you go this route.

Cheers,
Vlad