Operation of the MSG Command SLC 500s

[GlenGineer]

I have two PLCs both SLC5/4 that communicate with each other every once in a while. They share status information and part location information. 95% of the time this occurs without a hitch. The final 5% of the time one PLC or the other "forgets" to communicate. I suspect I know what is happening but the answer requires knowledge of how the MSG command functionally works. Googling MSG and SLC 500 (and similar searches) reveals very little about how to use the command. In a publication for the SLC 5/5 they state that to activate the command the rung needs to transition between true and false. In that example the MSG instruction does not have any arguments. The false true shift is done on the next line by unlatching the enable bit.

My question is once you have the false - true transition and the instruction is enabled does the communication continue if the arguments turn false?

My suspicion is that the second you loose the true argument you also loose the enable bit no matter what step the message command is on. The original programmer initiated the MSG instruction with a bit powered by a OSR. I suspect that if more then one message is incoming or outgoing at the same time it might take multiple scans to successfully communicate (and by that time the arguments are already false)

 

[Ken Roach]

While there have been plenty of examples published over the years using an unconditional rung for the MSG and an output unlatch (OTU) to set the Enable bit low, I still don't like the method. It makes more sense to me to explicitly set the rung true when I want to initiate a Message.

When the conditions preceding the MSG instruction go from false to true, the MSG is put into a buffer to be executed by the SLC operating system.

Once that happens, the MSG is either going to complete successfully (.DN) or complete unsuccessfully (.ER). The rung conditions that precede the MSG instruction do not need to be "held high" for the message to be completed.

The most common programming mistake is to write code that executes a MSG instruction based on a repeating timer, regardless of whether or not the previously executed instruction has completed. If there's a retry or no answer from the remote device, the timer just pops another MSG into the buffer, then another, then another. Eventually the buffer fills up, and that's very hard to program around in the SLC platform.

Have you defined a Channel Diagnostics data file for your DH+ channel so you can learn about the physical and logical conditions of the network via its error counters ?

 

[OkiePC]

My question is once you have the false - true transition and the instruction is enabled does the communication continue if the arguments turn false?

Yes, but it is possible to fill up the internal message queue if you trigger too many messages out of a single channel.

You can usually monitor the EN, DN and the ER bit to identify what is going on. Note that, depending on the type of channel, the default channel timeout when a node does not respond can be an awfully long time. With ethernet messaging, if there are multiple messages to multiple targets, I usually start a timer for each message with my own timeout value so that if the message does not complete in a normal manner I can programmatically set the TO bit to force the message out of the queue.

Having a diagnostic file for the channel is always a good idea too.

Tell us more about the PLC type and channel type and how many other devices are "talking" on that network or link.

 

[Firejo]

Once in enable a message instruction it will finish with either a done or error bit even if you take the rung back to false and unlatch the enable bit. I’ve tested it in both my MicroLogix 1100 and one of my SLC5/05’s.

 

[Firejo]

See what happens when you publish an answer before checking if someone else (much smarter than you are) has already answered.

 

[OkiePC]

See what happens when you publish an answer before checking if someone else (much smarter than you are) has already answered.

If I had not rewritten mine for twenty minutes before clicking "submit'...

 

[Geospark]

I posted this some time back. While it is in relation to an SLC 5/03, the operation of the MSG instruction is still relevant to the SLC 5/04...

There are 2 communication channels, or ports, on the SLC5/03(CH0 & CH1). Each port has 4 "channel dependant" buffers available to queue the MSG instructions for that port. So that makes 8 buffers between the 2 comm ports.

If 1 MSG is enabled, say a write MSG, it enters the first available buffer of four for that port, including the data to be sent. It awaits transmission at the next communication service interval, usually at the end of the scan. While the MSG is in the buffer waiting, it's Enabled(EN) and Enabled-Waiting(EW) bits are set in word 0 of the Control Block.

If 4 MSG instructions are enabled before the communication service interval, the buffer for that port is now full. If a fifth MSG instruction is now enabled while the buffer is still full, it goes into a FIFO overflow queue for that port. If subsequent MSG instructions are enabled at the same time before the communication service interval, a max of 10 MSG instructions can be queued(MSG 5-14) in the overflow FIFO. Only the header blocks of the MSG data are placed in this queue. While in the queue, only the EN bit is set.

Any further MSG instructions enabled, beyond the first 14, while the buffer and queue are full, will have their Waiting-for-Queue(WQ) bit set.

Once the communication service interval clears the 4 buffers for the port, the FIFO queue shifts the first 4 EN messages into the buffer which now also sets their EW bits and the first 4 WQ status messages will enter the queue in the order they are re-scanned. Their WQ bit is reset, and EN bit is set.

Note: For Modbus only 1 MSG can be buffered at a time and 10 queued (MSG 2-11).

There is no limit on the total ammount of messages that can be at WQ status at one time, but it's possible that some of these WQ messages may never get into the queue, depending on where they are in the scan.

That's why it's good practice to know how many messages can be enabled at one time between the buffer and queue and keep your program MSG excecutions inside this limit.

Either use an SVC instruction in the middle of the program, or after a block of 14 or less enabled messages.

I like to use the Timeout(TO) bit for each MSG. If left at the default 0, once the Start(ST) bit is set, the MSG waits indefinitely for a reply from the target. If you set a value of say 2 seconds, it will timeout the MSG and set the Error(ER) bit, which most of us use on a parallel branch to the Done(DN) bit to unlatch the Enable(EN) bit. The TO bit will reset the next time the rung goes from false-to-true.

You would need to give us more details on how many messages are involved here and how much data is being passed. Are the two SLC 5/04 messaging through the DH+ ports or some other protocol on the RS-232 Channel, such as DF1? If DH+, then as mentioned, how many other nodes are on the DH+ network?

It never hurts to throw an SVC instruction somewhere into the middle of the program to service communications more often and troubleshoot potential MSG timing issues, and also I would advocate the use of a diagnostics file.

Regards,
George

 

[GlenGineer]

Have you defined a Channel Diagnostics data file for your DH+ channel so you can learn about the physical and logical conditions of the network via its error counters ?

I'm not totally sure what you are suggesting. I've read that with RSLinks Professional allows for something similar. I've also read about other companies DH+ diagnosis software which you would run on a DH+ networked computer. Unfortunately both of these options would require spending money. My company would spend the money if it was causing major problems but an occasional annoyance will not get the investment.

Is there a diagnostic routine in RSLogix?

Thanks for the help.

Glen

 

[Doug-P]

The files Ken Roach refers to are internal to the PLC. This is set up in the 'channel configuration' area of the project tree.

See chapter 13, 'SLC communication channels', in the instruction set reference.

 

[GlenGineer]

See chapter 13, 'SLC communication channels', in the instruction set reference.

Doug you don't know how much of a help you have been!! Normally I RTFM before I ask a question but in this case I skipped straight to chapter 15 "Messaging Instruction." I read what was there and was utterly confused because it seemed like it was discussing step 2 when I wanted step 1. I thought Allen Bradley had really screwed up on the documentation. However while looking for chapter 13 I came across chapter 12. I will read them both shortly.

Thanks to everybody who tried to help me understand exactly how this command operates.

Glen

 

[Doug-P]

You're welcome. Now, let's see if it helps you solve your problem.

 

[JaxGTO]

I have also used the Global Status words before to pass 16 bits to/from any station. Basically its a 16 bit X 64 words that get passed around with the token from station to station. No MSG needed, but there is no verification unless you use one of the bits as a handshaking bit.

 

[GlenGineer]

I hate when I try to help somebody and I can never find out if the problem was solved. Therefore an update. Allen Bradley warns (in "the instruction set reference") not to re-enable the message command before you get a done or error message.

My errors began when I added another integer to the message command along with another activation signal. Sometimes these two signals will occur close together (times wise).

The change I made is that I am "holding high" the bits that initiate the message command until I get an error or done signal. Yes you all have said it is not needed but this was the easiest way I could find to make sure I got the done or error signal before reinitiating the message command. So far the error is gone.

 

[Doug-P]

Good job!