SLC MSG Control Bits

We have a site where there are 2x SLC's that we recently configured to share information for Scada display purposes. I was informed this week that the remote values were not updating.

Upon investigation, the MSG instruction had an error. Also, the TO bit was set.
From the manual:

You can set this bit in your application to remove an active message instruction from processor control. You can use either your own timeout control routine or the internal timeout control. If you use your own timeout control routine the Timeout Value must be set to zero. If you use the internal timeout control, set the Timeout Value between 1-255 seconds.

Click to expand...

I cannot recall setting this bit when I configured the instruction, but as it has to be set, perhaps I did. And as I had not set Control Word 8 to any value, the instruction timed out straight away, if the remote node was unavailable.

When I un-set this bit, comms were re-established. What I wanted to ask, do you use the TO field, or roll you own? What is the best method for recovery of this type of error, just unlatching the error bit and keep re-trying?

I think having the timeout function is a good idea, as it is bit of code that is already done for you.

As this code was only for Scada display (due to the DH+ network already being present), I got lazy and did not add any timeout/error checking code I will be doing this today.

as i understand it from my area tech support, messages are not 100% effective. in other words, you might send 100 messages and get back a reply 95, 80, 76, 99, 100 of those times.
the same can be said for the receiving plc.

i'm not much help but just thinking out loud, here goes.

you might want to have a message feedback loop.
send a message, start a timer, if the timer times out, resend message.
if you get the same message back, stop the timer.
in other words, set up a heartbeat signal.
regards,
jasms

Hi

Did you have the MSG rung executed unconditionally?

I always have some logic (like a recycling timer bit) to toggle the MSG true to false continuously.

If you are worried about errors you can always count them, using the bit 12 (error bit) of the control word, or count the successful messages using bit 13 (done bit) of the control word.

James Mcquade said:

as i understand it from my area tech support, messages are not 100% effective. in other words, you might send 100 messages and get back a reply 95, 80, 76, 99, 100 of those times.
the same can be said for the receiving plc.

i'm not much help but just thinking out loud, here goes.

you might want to have a message feedback loop.
send a message, start a timer, if the timer times out, resend message.
if you get the same message back, stop the timer.
in other words, set up a heartbeat signal.
regards,
jasms

Click to expand...

Yeah, standard comms practice should of been implemented, but I did get lazy. I will add a rollong clock value next time. Saying that though, MSG failures via bit 12 should be enough, I know I do tend to add in a rolling clock as a sageguard, and can be a more robust method.

ianingram said:

Hi
Did you have the MSG rung executed unconditionally?

Click to expand...

No, on a 1-sec pulse.

ianingram said:

If you are worried about errors you can always count them, using the bit 12 (error bit) of the control word, or count the successful messages using bit 13 (done bit) of the control word.

Click to expand...

Yep, done that, this is more relevant for radio comms, IMHO anyway. It is good to have a success/fail rate, but over copper, the rate should be almost 100%, expecially between similar products. Different products is a different story!

ianingram said:

I always have some logic (like a recycling timer bit) to toggle the MSG true to false continuously.

Click to expand...

Even though this was happening, as the .TO block was set, the erro flag was not resetting. What I was wanting to know, is what is the best method, obviously using a rolling clock & not using the .TO bit, but what about recovery if the MSG instruction does not recover, as in this case?

lostcontrol said:

Even though this was happening, as the .TO block was set, the error flag was not resetting. What I was wanting to know, is what is the best method, obviously using a rolling clock & not using the .TO bit, but what about recovery if the MSG instruction does not recover, as in this case?

Click to expand...

Sorry, I thought that the error bit would be reset if the MSG instruction was toggled from true to false.

You can use an OTU to reset the .TO bit (or error bit) if an error occurs.

Hopefully then, the MSG instruction will recover.

The examples at the AB Knowledgebase show the Enable Bit also being reset using an OTU if the done bit or error bit go high..

The MSG instruction only executes when the pre-conditions of the rung go from false to true.

The only exception to this is when you have an unconditional rung and set the .EN bit false for 1 scan so that the unconditional rung re-executes. I don't recommend that method.

When the .DN bit or the .ER bit is set, they stay set until the MSG instruction is executed again. They do not reset when the pre-conditions on the MSG instruction rung are false.

The .TO bit can be used for two purposes: it can be examined to find out if the .ER bit is due to a Timeout, or it can be set in logic to force a timeout to occur. Resetting the .TO bit has no effect on the Message.

When I run a periodic Message instruction, I use the .DN bit from my periodic timer to trigger the MSG if the MSG is not already enabled. I use the built-in Timeout feature of the MSG instruction to timeout a failed attempt, and just let the periodic re-trigger execute the MSG instruction again.

Thank Ken,

I think what had happened, is that the .TO bit was enabled (by me I think ), but the timout period was not set. Then what happened, and possibly due to a power failure, the .ER bit was set.
After this, the MSG was executing on a 1-sec clock pulse, but did not recover. Resetting the .TO bit enabled the MSG instruction to execute again.
This is the confusing situation, that even though the trigger was going from False->True, the instruction kept failing.

Either way, I have added some better error recovery & monitoring, so will be alerted a lot earlier now!