Studio 5000 messaging

I have a MSG block poling an encoder for a velocity value. Previously I had a timer setup with a one shot followed by the MSG block to get attribute single every 500ms.

Question: Is there any downside to just having a MSG block on an otherwise empty rung, wouldn't this just pole continuously (desired effect).

It looks like the .ER bit is only cleared if rung condition goes false so that may be a potential issue?

I am using connected and cashed connection type.

Any assistance would be greatly appreciated. Thank you,

~E

General Instruction Reference Manual Documents MSG Instruction:

http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm003_-en-p.pdf

pg154

"We recommend that you always include an XIO of the MSG.EN bit as an in-series MSG rung precondition.
This helps to reduce other ring preconditions from triggering the rung until the MSG completes or errors."

If the MSG instruction is placed alone on the rung, it will execute just once when the controller goes into RUN mode.

If you want the MSG to execute as fast as possible, you put an XIO with the /EN bit in series with the MSG on the rung. Whenever the MSG is not Enabled, it will be executed again.

That includes on the first scan, and every time it completes or errors.

I very strongly recommend against that method alone, since it consumes as many processor resources and network resources as it can, executing as fast as possible.

This is how I prefer to do simple repeating MSG instructions:

Ken Roach said:

This is how I prefer to do simple repeating MSG instructions:

Click to expand...

Thanks Ken. That is similar to what I had been doing (although used a oneshot off the timer). I just didn't know if all that was necessary. If it is going to tax the processor then I suppose it is.

Is the same process still applicable when using 'connected' 'cached' connections? AB TechConnect recommended cached connections for cyclical messages.

Thanks.

Connected and cached refer more to how the connection between the message originator and target is handled, more so than how the message instruction is actually executed at the originator.

Ken's example is the correct way to execute a repeating or cyclical message instruction while also monitoring for instruction errors or timeout i.e. using a periodic execution timer and an execution timeout timer.

As I'm sure you've read somewhere in your research...

Connected Message...

1. When a connected message is executed the originator will send an unconnected message to the target to establish a connection.
2. Once connected, the originator sends the data to the target.
3. Once the target has acknowledged receipt of the data the originator sends another unconnected message to close the connection.

If the connection is uncached the above sequence is repeated each time the message instruction is executed.

Connected and Cached Message...

1. When a connected message is executed the originator will send an unconnected message to the target to establish a connection.
2. Once connected, the originator sends the data to the target.
3. Once the target has acknowledged receipt of the data the originator will move the connection to the cached table.
4. A cache timer is started. If the message is not executed again after this time, then the cache will automatically resend the data. This keeps the connection to the target open.
5. The connection will not drop off unless the controller goes to Program Mode, the target drops off the network, or another message requests the cache buffer. If so, the originator will send an unconnected message to close the connection.
6. The next execution of the message instruction will reestablish the cached connection.

Using an unconnected message, or an uncached connected message, will add some time to the overall transmission of the data, beyond the cyclical logic used to execute the message instruction. While it is usually negligible, using a connected and cached message is the most efficient way to handle the connection for cyclical messaging.

So you are just fine with those settings and if you use Ken's advice.

Regards,
George

Thanks again.