PDA

View Full Version : MSG Blocks and Asynchronous Execution (Allen Bradleys)


kdcui
November 3rd, 2008, 10:41 AM
I was wondering if someone could clarify / correct my understanding of MSG block on PLC5 / SLCs / ControlLogix platforms.

MSG blocks are asynchronous to scan time. I guess I am wondering how exactly this works. Are they messaging at set intervals (not unlike RPIs), or only when certain criteria are met?

If I have a read block in a ladder somewhere, is it continuously updating asynchronously or only updating when the scan happens to coincide with whenever the MSG block is polling the source?

What is a good method to handle a program that will require lots of messaging (heartbeats?)?

Thanks

Ken Moore
November 3rd, 2008, 12:33 PM
In very simplistic terms, there is a message queue. This queue is processed on a first come first served bases.


You asked:
What is a good method to handle a program that will require lots of messaging (heartbeats?)?

Which platform? If it's CLX, I recommend produced/consumed instead.

kdcui
November 3rd, 2008, 12:54 PM
Yes, but aren't you limited to the number of produced / consumed tags? In such cases, we've been throwing everything into an array and messaging it.

Let's stick to PLC5 at the moment:

We have a lot of messaging going on between a primary and secondary PLC, since we ran out of memory on the Primary. IO is read in on the Pri, sent to Secondary, then passed back in some other form to use.

I am just wondering what goes on behind the scenes of the MSG block in this case. Sometimes certain messages aren't getting across and certain pieces of equipment fail to update their status.

Someone mentioned it might have to do with how MSG blocks are asynchronous, and how the program "ends" before the data can be sent over.

So I guess back to one of my other questions: how are the message blocks working when outside of a scan, and what happens to that data?

Ken Moore
November 3rd, 2008, 01:39 PM
The PLC-5 has a co-processor for the message traffic. The main processor executes the ladder and when a message instruction is encountered, the message is added to the co-processor's queue. The queue is processed FIFO.
How are your PLC-5's connected? How many nodes?
DH+ has smaller packets than ethernet and is slower also.

So...
It's possible that your plc is scanning many times between message updates. It all depends on network traffic, message size and number of messages.

kdcui
November 3rd, 2008, 03:27 PM
Everything is on a DH+ network including distributed IO. Not too familiar with the topology but I am pretty sure we have at least 30 nodes, and on the ones with Primary/Secondary configs are messaging a lot of data...

Ken Moore
November 3rd, 2008, 04:30 PM
From the PLC-5 Instruction set:
The MSG instruction transfers data in packets. Each DH+ data packet can contain up to 120 words. If message transfer contains more words, the the transfer requires more than one packet. The more packets the more time needed.

Estimating transfer time in milliseconds (for enhanced processors, classics are slower):

Message time = TP + TT + OH + 8 (number of messages)

TP= token pass = (1.5)(1+ DH+ nodes)
TT= transmission time= (.28 * number of words)
OH= overhead = 20



So in a 30 node system with a message of 100 words and 25 messages, the message would take around: 300 miliseconds

If your plc scan time was say 50 milliseconds, then your "remote" data would be updated every sixth or seventh scan.


There's a lot of good information in the instruction set reference, I recommend you download a copy. I believe it's document number 1785-6.1





Ken

kdcui
November 3rd, 2008, 06:19 PM
Thanks Ken.

Yeah, I actually downloaded some documentation after my last post. It will probably be good to get acquainted with it.

daba
November 5th, 2008, 05:09 PM
Sometimes certain messages aren't getting across and certain pieces of equipment fail to update their status.


I have had similar "failures" in systems with multiple messages.

As Ken already said the messages are handled by a second processor, and ladder requests for message execution are placed in a queue, or stack.

It is possible (likely?) that this queue can become full, and subsequent message requests are held "pending" waiting for a slot in the queue to become available.

When this happens, the slot is filled by the request from the MSG instruction that is scanned next, which is most likely going to be at or near the beginning of the block of message instructions in your ladder code. This means of course the following instructions rarely get into the queue, and time-out.

Imagine this scenario, where the message queue is 10 long:-

First ladder scan - all 20 messages get triggered (eg. by -|/|- .DN)

10 messages get "enabled", the other 10 are "enabled waiting" (for a queue position to be available).

Several ladder scans later, one of the first 10 messages completes, leaving a space in the queue, so message 11 takes it.

On subsequent scans, as messages complete, their queue positions get filled by the "done" messages near the top of the list, since they will have been re-triggered.

Net result is that messages near the bottom of the list don't get into the queue, so time-out.


There are several ways to sort this out. My favourite was to use timers to introduce a delay between being "done" and being re-triggered, allowing queue positions to be filled by messages that were "waiting".

If you use this method, you have to match up the timer values with the relative importance of the message. Analyse what the data is being sent, and decide if you want the message to be fast (small delay), or can suffer a slower update - in my case I was able to set some messages with 5 second delays, simply because the data was display info and not used in "real-time" control.

Hope this helps..

kdcui
November 5th, 2008, 06:06 PM
Hi Daba,

Thanks for the info. We had briefly talked about using timers if we can fit them in. Haven't had to chance to implement anything yet, everything is validated so to change anything requires mounds of paperwork.

Will see about trying this on the next project.