AB MSG Instruction


Thread Starter

Dave Ferguson

I am having a communications issue which I am arguing with a vendor in how he programmed it and we have come upon some questions as to how the MSG
instruction works.

We have a dedicated DH+ between to PLC's that runs at 115K. We have a number of events that fire a message instruction to communicate with the other PLC and then close the loop with feedback to the message.

I put diagnostic counters on the events on and off and on the message enable, start, eneable waiting, done and error bits.

The trigger firing the message counter is always higher than the enable,start,eneable waiting, done bits and periodically we freeze up. Also
there are no error counts.

My arguement is that 2 events are coming on at the same time and or are coming on so fast that the message is already busy and misses the "event".

He argues saying that the instruction ques these events.

My understanding of this instruction is this. When a message instruction is triggered the enable bit goes high the data enters a queue so that you capture it at this moment. and then when the processor gets teh token, it pulls the
data out of the queue and sends it and completes the comms. If while enables the rung makes 5 false to true trips, it does not matter as teh instruction is already (asynchromousl) attempting to finish the transfer. It is queued because the processor cannot just push out the message until it gets a token and depending on message size, how long it gets the token.

If you have a busy network full of devices and a lot of data being passed, more time waiting in the queue. I may be wrong but this is a queue not a buffer in the traditional sense of the word.

We have since done a work around to this to my satisfaction by making the message send until a reply is heard which is the way it should have been all along ( in my humble opinion which could be swayed). But I am curious as to why this is....

I still think that is the input condition changes over and over, it is only effective when the message is compete and if it goes on 100 times
(exageration) while the message is active, they will all be ignored IE dropped.

Have never had trouble with this so never have really thought about it this deeply.............

I am in my 15th year od PLC5 education and although I do ok, I admit I am not an expert as there is no such thing even at AB.

Dave Ferguson
DAVCO Automation
If the PLC queued messages, there would be a limit as to the size and number of active messages that can be active at a given time.

If you look in the manual, you will see that you can send a file longer than one DH+ message, this takes multiple scans through the ladder logic process. The message processing has been generalized to handle sending any sized file and can deal with having multiple messages outstanding.

The message instruction is the control block for processing the message. While it is busy, it can't process another message. Also the data isn't frozen and can be changed until the data is actually sent. The problem is that the program can't determine the state a message is in beyond whether or not it has completed so it is good practice to leave the data alone until the message gets sent.

As far as I know, the PLC-5 only processes messages at the end of each scan (or beginning depending on how you want to look at it). The DH+ processor runs while the ladder logic program is scanned but the results aren't updated in the processor until the end of the next scan after the message has completed. Also, Data Highway Plus is a token passing network and depending on the network load it may take several scans to be able to send one message.

What I have done in the past is to create an event queue to hold events. If it isn't empty, I copy the events into a message buffer and fire off the message instruction. When the message instruction completes I check the queue again to see if I need to send more (this is done every program scan).

I hope this has been helpful

Tom Bray

Nate Hoffman

The diagnostic counters for the triggers for the message instruction will count more than the .en, .st, .ew, .dn, and .er counters. This is because when a rung containing a message instruction transitions from false to true, the .en bit is set. If the rung transitions back to false, the .en bit remains set until the message is completed. If the rung transitions back to true because of another trigger before the MSG instruction completes, the MSG is not triggered again.

If you want to have multiple events triggering messages, if a common message instruction is used, events may be missed. For example, if two XIC instructions with the addresses B3/0 and B3/1 are in parallel branches triggering the same message instruction and B3/0 triggers the message and then B3/1 attempts to trigger the message before it is done, the trigger attempt by B3/1 would be ignored. If B3/0 and B3/1 control their own MSG instructions (with their own unique control blocks), then the messages would both get triggered under this condition, the draw back of this is that you may fill the MSG que and then there may be poor response.

As far as the lockup problem, check to see if there is a timeout value set for the message instruction so it can time out if no response is sent from the other processor.