Abstract
When setting up communications from the RTU to other devices like I/O modules, flow meters, etc… over serial and Ethernet one of the options that is selected is Message Sequence. This defines how the queries will be sent from the RTU to other devices. What is the difference and how are these configured? These questions will be answered.
Products
IPm Programmable RTUs: ST-IPm-8460\ST-IPm-6350\VT-mIPm-245-D\VT-mIPm-135-D\VT-IPm2m-113-D\VT-IPm2m-213-D\VT-uIPm-431-H
Use Case: Communicating to other devices
Required Software
Sixnet I/O Tool Kit 5.0.100 or above
ST-IPm-8460 firmware 7.0.100 or above
ST-IPm-6350 firmware 4.9.152 or above
VT-mIPm-xx5-D firmware 4.9.152 or above
VT-IPm2m-x13-D firmware 4.9.152 or above
VT-uIPm-431-H firmware 4.3.179 or above
The difference between “Wait for Reply” and “Rapid Fire”
- What is “Wait for Reply?” When a “Wait for Reply” is configured the RTU will send a query wait for a reply before it sends the next query. This is designed for half-duplex serial communications but can also be useful for communication with some IP devices.
- How does “Wait for Reply” handle timeouts? When a “Wait for Reply” transfer query does not receive a response the RTU will wait to send any other queries until the timeout and retry elapse. Failed query attempts could delay the I/O transfers especially on serial ports. By default the timeout is 3000ms. One try is done regardless of the message attempts(retry) setting, so if “3” is set four message attempts will occur.
- What is “Rapid Fire?” When the “Rapid Fire” setting is used the port will send all the queries (when multiple transfers are configured) right after the other and wait for the responses to come back. The sequence number in the IP packet is used to organize the responses.
- How does “Rapid Fire” handle timeouts? The RTU will wait for the message timeout before it sends another message attempt (retry). If other queries one the same IP port or the same device are receiving responses they will not be delayed by other timeouts. One try is done regardless of the message attempts(retry) setting, so if “3” is set four message attempts will occur.
Assigning message sequence to IO transfers
- Serial Transfers. Any transfer assigned to a serial port will be locked at “Wait for Reply”
-
IP I/O Transfers. Any IP transfer can be “Wait for Reply” or “Rapid Fire.” By default, this is a global setting for all IP devices. If you want each station to be customized as “Wait for Reply” or “Rapid Fire” the “per station” selection in the message sequence selection. The screen grabs below show a list of transfers and what message sequence was selected. Also below is a screen grab of the message sequence configuration window.
Station Status Module:
Here are some common questions asked about the station status module...
- Is the Station Status virtual module intended to be used only for indicating the health of communications with remote Sixnet stations, or can it be used for other remote Modbus devices?
- Yes it can be used with other modbus remote devices, both serial and ethernet based communications
- What communications condition are used by the Sixnet RTU to determine if a remote device is on-line vs off-line?
- this is controlled by the communications timeout setting
- When using Modbus TCP/IP vs. serial Modbus there are different settings when configuring the I/O Transfer. Are the conditions used to determine the on-line/off-line status different when communicating with a remote device using Modbus TCP/IP vs serial Modbus?
- Number of retries & retry timeouts
- If you have a single I/O transfer configured to read Modbus data from a Modbus slave device, and you are are using the Scan Enable Flag to enable/disable to I/O Transfer, how will this affect the Station Status bit?
- Again this falls back on the retries and timeouts. Same rules apply, but only when the scan enable flag is cut on...
Points about the Scan Enable bit and how to use it in your application:
If you ever have a large amount of devices on RS485 but need fast polls from some but not others, you can use the scan enable bits to control the process by using the bits as virtual outputs in logic to only poll the "fast poll" devices constantly and cut off the slow devices. That is exactly what this is for.
Disclaimer
It is the customer's responsibility to review the advice provided herein and its applicability to the system. Red Lion makes no representation about specific knowledge of the customer's system or the specific performance of the system. Red Lion is not responsible for any damage to equipment or connected systems. The use of this document is at your own risk. Red Lion standard product warranty applies.
Red Lion Technical Support
If you have any questions or trouble contact Red Lion Technical Support by clicking here or calling 1-877-432-9908.
For more information: http://www.redlion.net/support/policies-statements/warranty-statement