Modbus Protocol User Guide: Part Number 900-271 Revision M December 2017
Modbus Protocol User Guide: Part Number 900-271 Revision M December 2017
Modbus Protocol User Guide: Part Number 900-271 Revision M December 2017
User Guide
Lantronix, WiBox, XPort, and WiPort are registered trademarks of Lantronix, Inc. XPress, xPico,
and xDirect are trademarks of Lantronix, Inc.
Wi-Fi is a registered trademark of the Wi-Fi Alliance Corporation. All other trademarks and trade
names are the property of their respective holders.
Contacts
Lantronix, Inc.
7535 Irvine Center Drive
Suite 100
Irvine, CA 92618, USA
Toll Free: 800-526-8766
Phone: 949-453-3990
Fax: 949-450-3995
Sales Offices
For a current list of our domestic and international sales offices, go to the Lantronix web site at
www.lantronix.com/about/contact
Disclaimer
All information contained herein is provided “AS IS.” Lantronix undertakes no obligation to
update the information in this publication. Lantronix does not make, and specifically disclaims,
all warranties of any kind (express, implied or otherwise) regarding title, non-infringement, fitness,
quality, accuracy, completeness, usefulness, suitability or performance of the information
provided herein. Lantronix shall have no liability whatsoever to any user for any damages, losses
and causes of action (whether in contract or in tort or otherwise) in connection with the user’s
access or usage of any of the information or content contained herein. The information and
specifications contained in this document are subject to change without notice.
Revision History
Date Rev. Comments
June 2001 B Preliminary Release 6/01
September 2002 C Reformat. Added notes, PN.
August 2004 D Reformat. Added two advanced settings.
July 2005 E Added content for WiPort and WiBox.
September 2005 F Added content for XPort.
April 2012 G Updated network protocol and platform information.
April 2013 H Added content for xDirect and xPico. Updated security settings available on IAP.
June 2013 I Added content for Micro125.
February 2016 J Minor corrections, address / contact updates
April 2016 K Added content for the XPress DR+.
November 2016 L Added information for xPico 110 module.
December 2017 M Updated enhanced password information.
1: Introduction 6
2: Modbus 7
Extended Modbus System Example ____________________________________________ 7
3: Configuring Modbus 9
Network Protocols __________________________________________________________ 9
Packing Algorithm __________________________________________________________ 9
IP Address ________________________________________________________________ 9
Configuration Methods ______________________________________________________ 9
IAP Device Server IP Addresses ______________________________________________ 10
Using the Setup Mode Screen________________________________________________ 10
Basic Commands (D/S/Q) ___________________________________________________ 11
Network/IP Settings ________________________________________________________ 12
Serial and Mode Settings ___________________________________________________ 12
Modem Control Settings ____________________________________________________ 13
Advanced Modbus Protocol Settings __________________________________________ 14
Unit ID to IP Address Lookup Table ___________________________________________ 16
Security Settings __________________________________________________________ 18
Default Security Settings ____________________________________________________ 19
6: XPort Implementation 24
7: xPico Implementation 25
8: Micro125 Implementation 27
A: Troubleshooting 29
How fast can I poll? ________________________________________________________ 29
I cannot get a slave response ________________________________________________ 30
Only Slave ID #1 can be polled _______________________________________________ 31
nd
Every 2 poll seems to fail __________________________________________________ 31
Figures
Tables
This user guide provides Modbus protocol-specific information for the embedded and external
products listed above.
The IAP device server allows users to integrate new and existing Modbus/RTU and
Modbus/ASCII serial devices with newer TCP/IP network-based devices. The next chapter
describes a system that integrates four Modbus/RTU devices with four Modbus/TCP devices.
Figure 2-1. Extended Modbus System Example shows four specific styles of Modbus operations.
Modbus/RTU devices are traditionally split into two groups. (CoBox Modbus refers to an IAP
device server.)
Modbus slave devices generally are the workhorse devices. They perform their tasks 24 hours a
day, 365 days a year, for example, tasks such as flow metering, temperature control, batch
loading, or even running entire automated assembly lines. The slave devices are not called
“slaves” because they work all the time; they are called slaves because as far as the data
communications is concerned, they function as passive servers. Modbus slave devices passively
sit and wait for a remote Modbus master device to ask them to report existing data values (Read)
or accept new data values (Write).
Modbus master devices generally are higher-level computers, devices in which data and
software are very important. The most common examples of Modbus master devices are the
“Human-Machine-Interface” (HMI) computers, which allow human operators to monitor, adjust,
and maintain the operations of the field devices. Modbus master devices are clients that actively
go out and “read” from and/or “write” to remote Modbus slave devices to monitor or adjust slave
behavior.
It is revolutionary for such a simple and flexible protocol as Modbus to offer such functionality.
Therefore, Modbus/TCP offers exciting new design options for industrial users, which the
Lantronix IAP device servers extend to traditional Modbus/RTU serial devices.
Devices G and H are different from device D. They share a single RS485 “multi-drop” line that
strictly limits them to act as slaves to a single Modbus/RTU master. However, a little of the new
Modbus/TCP and IAP device server magic still appliesall Modbus/TCP enabled devices A, B,
E, and F can actively share access to both slave devices G and H. IAP device server manages
and coordinates the shared access. In fact, the IAP device server allows up to eight concurrent
Modbus masters to share access to the slaves.
The IP protocol defines addressing, routing, and data block handling over the network. The TCP
(transmission control protocol) assures that no data is lost or duplicated, and that everything sent
into the connection on one side arrives at the target exactly as it was sent.
For typical datagram applications in which devices interact with others without maintaining a
point-to-point connection, UDP datagram is used.
Packing Algorithm
Traditional Modbus/RTU requires a “character timeout” to signal the end of a Modbus/RTU
packet. This stretches out the overall response cycle. Fortunately, the IAP device server uses an
intelligent length-predictive algorithm to detect the end of standard Modbus messages. This
allows better performance and the IAP device server falls back to using a user definable
“character time-out” to manage non-standard or user-defined Modbus functions.
IP Address
Every device connected to the TCP/IP network including the IAP device server must have a
unique IP address. When multiple Modbus devices share a single IP, then Modbus/TCP includes
an additional address called the Unit ID. See the product user guide for your specific IAP device
server for a complete description of IP Addressing.
When the IAP device server is receiving Modbus/TCP messages from remote masters, the Unit
ID is converted to use in the Modbus/RTU message as the slave address.
When the IAP device server is receiving Modbus/RTU messages from local serial masters, a
user-defined lookup table is used to match the 8-bit Modbus slave address to a remote IP
address. The Modbus slave address received is used as the Unit ID.
Configuration Methods
The IAP device server can be configured using remote or local methods. Either use an ASCII
terminal or a terminal emulation program to locally access the serial port or use a Telnet
connection to port 9999 to configure the unit over the network. See the product user guide for
your IAP device server.
The IAP device server configuration is stored in nonvolatile memory and is retained without
power. The configuration can be changed any time. The IAP device server performs a reset after
the configuration has been changed and stored.
With a DHCP-enabled IAP device server, if there is a DHCP server to respond to IAP device
server’s request when it is booting up, the IAP device server will then get an IP address, a
gateway address, and a subnet mask from the DHCP server. These addresses will not be shown
in the IAP device server’s Setup (configuration) screens (you will still see 0.0.0.0); however if you
enter the Monitor Mode and from 0> prompt, type NC (upper case), the IP configuration of the
IAP device server will display. . See 4: Monitor Mode and Firmware for more information.
2. Within 5 seconds, press Enter to display the Setup (configuration) Mode screen. Here you
can change the parameters that define how the IAP device server does its job.
Note: When you set up a new unit, and especially if you just reflashed the unit with a
new firmware type, we recommend that you reset all of the parameters to the factory
defaults.
3. To reset the parameters to the factory defaults, type D on the command line and press Enter.
The default parameters display.
4. Select an option on the menu (1-7) by typing the number of the option.
5. To enter a value for a parameter, type the value and press Enter, or to confirm a default
value, press Enter.
To save the configuration and exit, type S on the command line and press Enter. This saves
the parameters to EEPROM.
Caution: DO NOT POWER CYCLE the unit too fast after doing this. Allow the unit to
reboot naturally one time first.
To quit without saving, type Q on the command line and press Enter. The unit reboots.
To restore the default values, type D on the command line and press Enter.
1) Network/IP Settings:
IP Address . . . . . . . . . - 0.0.0.0/DHCP/BOOTP/AutoIP
Default Gateway . . . . . . . --- not set ---
Netmask . . . . . . . . . . . --- not set ---
2) Serial & Mode Settings:
Protocol . . . . . . . . . . . Modbus/RTU,Slave(s) attached
Serial Interface . . . . . . . 9600,8,N,1,RS232, CH1
3) Modem Control Settings:
DTR Output . . . . . . . . . . Fixed High/Active
RTS Output . . . . . . . . . . Fixed High/Active
4) Advanced Modbus Protocol settings:
Slave Addr/Unit Id Soutce . . Modbus/TCP header
Modbus Serial Broadcasts . . . Disabled (Id=0 auto-mapped to 1)
MB/TCP Exception Codes . . . . Yes (return 00AH and 00BH)
Char, Message Timeout . . . . 00050msec, 05000msec
7) Security Settings:
SNMP . . . . . . . . . . . . . Enabled
SNMP Community Name . . . . . public
Telnet Setup . . . . . . . . . Enabled
TFTP Download . . . . . . . . Enabled
Port 77FEh . . . . . . . . . . Enabled
Web Server . . . . . . . . . . Enabled
Web Setup . . . . . . . . . . Enabled
Enhanced Password. . . . . . . Disabled
Save (S)
Entering S saves the currently displayed parameter settings into non-volatile memory and exits
configuration mode. This option triggers a reset.
Network/IP Settings
Select 1 to configure the device server’s network parameters.
The following values can be set or changed. To understand and select the appropriate values,
consult one of the many TCP/IP books available today and your network administrator.
IP Address
The IP address must be set to a unique value on your network. If you are not familiar with IP
addressing on your network, please consult your network administrator. Please refer to the IAP
user guide for your device server for more details about IP addresses.
If the IAP device server is set to an address already in use, it displays an error code with the
LEDs and will not operate properly. If you plan to use DHCP, set the IP to 0.0.0.0 to activate
DHCP.
Enable the enhanced password setting and create a strong 16-character password. For details,
see Security Settings on page 18.
Note: We do not recommend that you only use the 4-character basic password as it does
not offer sufficient security. Using no password is very dangerous.
With the XPress DR-IAP, you still must set the external red RS232/RS485 switch appropriately.
With the UDS-10-IAP or CoBox-FL-IAP, you must still select the correct pins for RS232 or the
shared RS422/485 pins.
The UDS-10-IAP supports only 1 stop bit. If you try to set an unsupported combination of settings,
a warning displays.
Note: Regardless of these settings, IAP device server configuration is always done on
CH1 with RS232 and a setting of 9600,8,N, 1.
The XPress DR-IAP has a DTE-style RS232 port, so RTS is an output and CTS is an input. The
UDS-10-IAP and CoBox-FL-IAP have a DCE-style RS232 port, so RTS is an input and CTS is an
output.
Setting this value to 0 causes the IAP device server to use the Modbus/TCP Unit ID as received.
Setting it to any other address causes the IAP device server to always use the set value as a
fixed address.
Note: In the current software version for IAP device server, a true Modbus broadcast is
only supported when a serial slave device is attached. A Modbus broadcast from a serial
master device is discarded regardless of this parameter setting.
Setting this parameter to 1/No causes the IAP device server to behave like a traditional Modbus
serial slave – it answers timeouts, unconfigured slave addresses, and CRC errors with silence.
Setting this to 2/Yes causes the IAP device server to return 1 of 2 new exception codes defined in
Modbus/TCP.
Consider exception hex 0A (PATH UNAVAILABLE) a “hard” error where a retry is not likely to
succeed. It is returned:
If slave-attached – currently never. However, future firmware may allow the user to define the
range of valid slave addresses.
If master-attached – if a Modbus request has a slave address that is not configured in the
Unit ID to IP mapping table.
If master-attached – if the TCP socket failed to open. This is really a soft-hard error, as the
reason the TCP socket failed to open may be transient or a hard configuration error.
Consider exception hex 0B (TARGET DEVICE FAILED TO RESPOND) a “soft” error where a
retry may succeed. It is returned:
If slave-attached – if the slave didn’t answer or the answer contained a CRC error
If master-attached – if a TCP socket is open, but no response was received in the defined
message timeout.
If master-attached – if a TCP socket is open, but the remote Modbus/TCP slave/server
returned exception 0x0B.
Setting this to 1/No causes the IAP device server to allow this queuing or pipeline behavior. This
is the safest default setting – only change this to disable if you are having problems.
Setting this to 2/Yes causes the IAP device server to always fetch the newest request from the
TCP buffer – all older requests are discarded. This allows a Modbus/TCP master/client to retry
old requests without risking building up a stale queue of waiting requests.
Note: Setting this value lower than 50 msec will not improve performance and may even
make performance worse. The IAP device server uses an intelligent length-predicting
algorithm to detect end-of-message in Modbus/RTU. This “character timeout” is only
used with user-defined or non-standard Modbus functions.
These parameters only apply when Modbus Master is selected for the Serial
Protocol. The new menu appears like this:
Network/IP Settings:
IP Address . . . . . . . . . . 192.168.100.77
Default Gateway . . . . . . . --- not set ---
Netmask . . . . . . . . . . . --- not set ---
2) Serial & Mode Settings:
Protocol . . . . . . . . . . . Modbus/RTU,Master(s) attached
Serial Interface . . . . . . . 9600,8,N,1,RS232
3) Modem Control Settings:
RTS Output . . . . . . . . . . Fixed High/Active
4) Advanced Modbus Protocol settings:
MB/TCP Exception Codes . . . . Yes (return 0x0A and 0x0B)
Char, Message Timeout . . . . 00050msec, 05000msec
5) Unit ID -> IP Address Table
Close Idle Sockets . . . . . . 10sec
Redundant Entry Retry . . . . Feature Disabled
7) Security Settings:
SNMP . . . . . . . . . . . . . Enabled
SNMP Community Name . . . . .. public
Telnet Setup . . . . . . . . . Enabled
TFTP Download . . . . . . . . Enabled
Port 77FEh . . . . . . . . . . Enabled
Web Server . . . . . . . . . . Enabled
Web Setup . . . . . . . . . . Enabled
Enhanced Password. . . . . . . Disabled
Port 77F0h . . . . . . . . . . Enabled
Since serial Modbus uses 8-bit slave addresses and a TCP/IP network requires 32-bit IP
addresses, the IAP device server uses this table to map an 8-bit address into an IP/Unit ID
combination. The 8-bit address is used to select the desired IP and as the Unit ID sent. The table
holds 8 entries, and any Modbus slave address not found in the table returns an exception
response to the master (if enabled).
Close Idle TCP sockets after (1-60 sec, 0=leave open) (00010)
Redundant entry retries after (15-60 sec. 0=disable feature) (00000)
(Set 4th octet to 0 to use Slave Address as part of IP)
Otherwise enter values 3 to 60 to automatically close the last socket after 3 to 60 seconds (sec)
of idle time.
Slave IP Address
This is the IP address of the remote Modbus/TCP slave. Note the two different ways these IP are
interpreted. In the configuration example above, you see the following results:
Setting the last/4th IP octet to zero is interpreted as a signal to use the Slave ID as part of the IP.
This allows a Modbus/RTU master to access up to 255 remote Modbus/TCP slaves. Setting the
last/4th octet of the IP to 1-254 causes all slave polls in this group to be sent to the same IP. 255
is not accepted as the last/4th IP octet.
Security Settings
Select 7 to configure the device server’s security setting parameters.
7.Security Settings:
SNMP ....................... Enabled
SNMP Community Name ........ public
Telnet Setup ............... Enabled
TFTP Download .............. Enabled
Port 77FEh ................. Enabled
Web Server ................. Enabled
Web Setup .................. Enabled
Enhanced Password .......... Disabled
Port 77F0h ................. Enabled
CAUTION: Disabling both Telnet Setup and Port 77FE will prevent users from
accessing the setup menu from the network.
SNMP
You can enable or disable SNMP. By default it is enabled.
SNMP Community
The SNMP Community Name is a required field for NMS to read or write to a device. Enter a
string of 1 to 13 characters.
Telnet Setup
This setting defaults to the N (No) option. The Y (Yes) option disables access to Setup Mode by
Telnet (port 9999). It only allows access locally using the web pages and the serial port of the
unit.
Note: If you choose to disable this option, keep in mind that disabling Telnet Setup will
prevent users from accessing the setup menu from the network.
TFTP Download
This setting defaults to the N (No) option. The Y (Yes) option disables the use of TFTP to perform
network firmware upgrades. With this option, you can download firmware upgrades over the serial
port using the DeviceInstaller application recover firmware procedure.
Port 77FEh
Port 77FE is a setting that allows DeviceInstaller custom program to locate and configure the unit
remotely. You may wish to disable this capability for security purposes.
Note: If you choose to disable this option, keep in mind that disabling both Telnet Setup
and Port 77FE will prevent users from accessing the setup menu from the network.
Web Server
This setting defaults to the N (option). The Y (Yes) option disables the web server.
Avoid using either the 4 character basic password setting or no password at all as they are not
secure options.
Note: The XPress DR, XPress DR+, xDirect, UDS1100 and the Micro125 will not
support this security feature.
The user guide for the device server explains two other ways to reflash. You can do it serially with
HyperTerminal or directly by Ethernet with a Trivial-File-Transfer-Protocol (or TFTP) Client. The
TFTP method takes just a few seconds – much faster than the 5-plus minutes required serially.
With all protocol firmware, use the TFTP destination filename of .ROM (in caps).
There are important differences between the industrial protocol firmware files and the standard
Lantronix firmware files. Although the hardware may be the same, you will not be able to
download a standard Lantronix firmware (such as the standard “3Q” or the older Modbus versions
1.0, 1.1, or 1.2). These firmware files are rejected with the error “Sorry, that firmware not
supported.” And although you can download any industrial firmware to non-IAP Lantronix device
servers, they will not function. When started, an industrial firmware on the wrong hardware will
blink the red LED, and you will see the error message “Sorry, this firmware is not supported” from
the serial port. The industrial firmware also has blocked the “SF” command within the Monitor.
The WiPort and WiBox have 2 serial ports. Choose the serial port the firmware uses for sending
and receiving Modbus/RTU or Modbus/ASCII serial data under the Serial & Mode Settings
menu option.
Note: Channel 1 on WiBox only supports RS-232 while Channel 2 supports RS-232 and
RS-422/RS-485 2/4-wire modes.
The menu option for Modem Control Settings is replaced with Modem/Configurable Pin
Settings on the WiPort. The options are:
The assignment for each configurable pin is set by cycling through the menu options by entering
a space or any key other than Enter.
GPIO assigns the pin as a general purpose input or output. The GPIOs can be written and
read via Modbus/TCP when in slave attached mode.
DTR is the Modem Control Output (MCO) signal for Data Terminal Ready.
Diag LED, Status LED-G and Status LED-Y are the outputs for diagnostic LED (red), green
status LED, and the yellow status LED.
RS485 Select is an output made active when configuring the serial channel for RS422/485
operation.
RS485 2-Wire and 4-Wire are outputs made active when configuring RS422/485 2-Wire or 4-
Wire operation respectively.
Defaults is an input read at startup that tells the firmware to reset configuration to factory
defaults.
After assigning the applicable function by pressing Enter, you are then asked if the pin is inverted
(active low).
CP0 Function (hit space to toggle) GPIO (In) Invert (active low) (Y) ?
A function should be assigned to each configurable pin. GPIO (Input) should be the default for all
unused or unassigned pins.
CP0 Function (hit space to toggle) RS485 Select Invert (active low) (Y) ?
CP1 Function (hit space to toggle) RS485 2-Wire Invert (active low) (Y) ?
CP2 Function (hit space to toggle) GPIO (In) Invert (active low) (N) ?
CP3 Function (hit space to toggle) GPIO (In) Invert (active low) (N) ?
CP4 Function (hit space to toggle) GPIO (In) Invert (active low) (N) ?
CP5 Function (hit space to toggle) Diag LED Invert (active low) (N) ?
CP6 Function (hit space to toggle) Status LED-G Invert (active low) (N) ?
CP7 Function (hit space to toggle) Status LED-Y Invert (active low) (N) ?
CP8 Function (hit space to toggle) GPIO (In) Invert (active low) (N) ?
CP9 Function (hit space to toggle) GPIO (In) Invert (active low) (N) ?
CP10 Function (hit space to toggle) GPIO (Out) Invert (active low) (N) ?
After all the configurable pins have been assigned, the standard modem control settings can be
entered if applicable.
The setting for each configurable pin is displayed in the setup menu.
The menu option for WLAN Settings has been added to configure the Wi-Fi parameters of the
WiPort/WiBox.
Two new parameters were added under the menu option Advanced Modbus Protocol Settings
on WiPort. The Modbus slave address and starting offset parameters are used to direct Read Coil
Status, Read Input Status, Force Single Coil and Force Multiple Coils Modbus commands to the
WiPort device server’s GPIO. Other commands or unmatched addressing are directed to the
serial port.
CP1 Function (1=Unused, 2=Status LED Output, 3=RTS Output, 4=RS485 Output
Enable)
The Status LED Output function for CP1 is an active low output for controlling the device
server’s Status LED (LED1 in the XPort Integration Guide). Selecting RTS Output for CP1
prompts for additional options related to controlling a Request to Send (RTS) signal and
performing flow control (see Modem Control Settings on page 13). Select Wait for CTS from
these options to auto-configure CP3 for CTS Input. Use the RS485 Output Enable function to
control an external RS485 line driver when in RS485 2-wire mode. This output is configurable for
active high (default) or active low.
Select DTR Output for CP2 prompts for additional options for controlling a Data Terminal Ready
(DTR) signal (see Modem Control Settings on page 13). RS485 Output Enable function controls
an external RS485 line driver when in RS485 2-wire mode. This output is configurable for active
high (default) or active low.
The Diagnostic LED Output function for CP3 is an active low output for controlling the device
server’s Diagnostic LED (LED3 in the XPort Integration Guide). Select (Y)es on the Wait for CTS
option under the CP1 function menu for RTS Output to automatically select the CTS Input
function for CP3.
The xPico has 2 serial ports. Choose the serial port the firmware uses for sending and receiving
Modbus/RTU or Modbus/ASCII serial data, under the Serial & Mode Settings menu option.
Note: Channel 1 on xPico supports RS-232 and RS-422/RS-485 2/4-wire modes while
Channel 2 only supports RS-232.
The menu option for Modem Control Settings has been replaced with Modem/Configurable
Pin Settings on the xPico.
The assignment for each configurable pin is set by cycling through the menu options by entering
a space or any key other than Enter.
GPIO assigns the pin as a general purpose input or output. The GPIOs can be written and
read via Modbus/TCP when in slave attached mode.
DTR is the Modem Control Output (MCO) signal for Data Terminal Ready.
DCD is the Modem Control input (MCI) signal for Data set Ready.
Channel 1 and Channel 2 status LED show the activity of Modbus packet transactions
happening in the device server.
RS485 Select is an output made active when configuring the serial channel for RS422/485
operation.
RTS is the out pin for channel 2 for hardware flow control.
CTS is the input for channel 2 for hardware flow control.
After assigning the applicable function by pressing Enter, you are then asked if the pin is inverted
(active low).
CP1 Function (hit space to toggle) GPIO (In) Invert (active low) (Y) ?
A function should be assigned to each configurable pin. GPIO (Input) should be the default for all
unused or unassigned pins.
CP1 Function (hit space to toggle) GPIO (In) Invert (active low)
(Y) ?
CP2 Function (hit space to toggle) GPIO (Out) Invert (active low)
(N) ?
CP3 Function (hit space to toggle) DCD (IN) Channel-1 Invert (active low)
(N) ?
CP4 Function (hit space to toggle) DTR (Out) Channel-1 Invert (active low)
(Y) ?
CP5 Function (hit space to toggle) Channel-1 Status LED Invert (active low)
(Y) ?
CP6 Function (hit space to toggle) Channel-2 Status LED Invert (active low)
(Y) ?
CP7 Function (hit space to toggle) RS485 Select Invert (active low)
(Y) ?
CP8 Function (hit space to toggle) RS485 2 Wire Select Invert (active low)
(Y) ?
After all the configurable pins have been assigned, the standard modem control settings can be
entered if applicable.
The setting for each configurable pin is displayed in the setup menu.
The Micro125 has 1 serial port. Select this serial port, which the firmware uses for sending and
receiving Modbus/RTU or Modbus/ASCII serial data, under the Serial & Mode Settings menu
option.
The setting for each configuration option is displayed in the setup menu.
If the user presses the reset button for 0-2 seconds then the unit simply reboots.
Note: With factory default configuration, IP address, Gateway and Netmask are set to
0.0.0.0.
Above all, remember that the serial speed (or baud rate) consumes the largest amount of time
(see the table below). Suppose you issue a Modbus poll for 125 registers. This requires a 255-
byte response, which at 19.2kbps requires over 133 msec just to physically shift across the wire,
while at 300 baud it takes nearly 10 seconds!
Baud Rate Byte/Sec Bit Time Byte Time 256 Byte (in sec)
(msec) (msec) Time (msec)
300 30 3.333333 33.333333 8533.333333 8.53
600 60 1.666667 16.666667 4266.666667 4.27
1200 120 0.833333 8.333333 2133.333333 2.13
2400 240 0.416667 4.166667 1066.666667 1.07
4800 480 0.208333 2.083333 533.333333 0.53
9600 960 0.104167 1.041667 266.666667 0.27
19200 1920 0.052083 0.520833 133.333333 0.13
38400 3840 0.026042 0.260417 66.666667 0.07
57600 5760 0.017361 0.173611 44.444444 0.04
115200 11520 0.008681 0.086806 22.222222 0.02
The overall time it takes to poll is the combined sum of these delays:
c. Delay for the poll to cross Ethernet and arrive error-free at the IAP device server device
(may include retries and contention).
d. Delay for IAP device server to process and queue Modbus/RTU poll.
e. Delay for the serial link to be free (remember other master/clients may be actively
polling).
i. Delay for IAP device server to process and queue Modbus/TCP response.
j. Delay for the response to cross Ethernet and arrive error-free at the master/client (may
include retries and contention).
Delays a and k are defined by your OPC or DDE driver. For example, a driver that runs
only once each 55 msec (using the old DOS timer slice) can have a variable delay here
of between 0 to 110 msec.
Delays c and i are defined by the complexity and load of your TCP/IP network. For
example, if you are going through radio or satellite links, these delays routinely amount to
1000 msec (1 sec) or more per poll and another 1000 msec for a response.
Delays f and h are defined by the baud rate. Assuming an 8 bytes poll and 255-byte
response, at 9600 baud this is at least 275 msec, while at 1200 baud, this is at least 2200
msec (2.2 sec).
Delay g is defined by the device. Oddly enough, the simpler the device, the faster it tends
to reply. Some controllers only allocate fixed time slices to process a response from
shared memory – for example once each 100 msec.
Delays d, e, and i are defined by the load on the IAP device server. If other master/client
are polling, the queuing delay for e can be large (the sum of delays f, g, and h) for each
earlier poll waiting.
Is your cable set up correctly for RS232 or RS485? On the XPress DR-IAP, is the external
red switch set correctly?
For RS485, you need to short the TX+ to the RX+ and TX- to the RX- externally.
The XPress DR-IAP has a floating ground that is fully isolated from the power supply. An
external Signal Ground connection is often required between the IAP and your device.
The IAP device server firmware only expects Modbus/TCP from the network. Some
applications just pack Modbus/RTU raw in TCP – this is not supported.
Your slave is set for 2 stop bits and your UDS-10-IAP does not support
2 stop bits.
My IAP device server runs fine - for about 10 minutes and then my applications start reporting
slaves going off-line.
My IAP device server runs fine – until a slave goes off-line; then I tend to lose all the slaves
or they all poll only intermittently.
Sometimes my IAP device server returns the wrong data from the wrong slave.
After a while, the IAP device server seems to take longer and longer to answer – after a few
hours, it takes 10 minutes or more for systems changes to propagate up to the master/client.
All these relate to the same issue – a mismatch in queuing behavior and expectation by the
master/client to the new realities of Ethernet. (It is not the IAP device server behaving poorly.)
Resetting the IAP device server fixes the problem (flushes the bloated TCP queues full of stale
requests).
The core problem is that the master/client is using the old RS485 serial assumption that no
answer means poll was lost. However, in the IAP device server case, it could also mean the IAP
device server has not had time to answer (is being overworked). Also remember that TCP is
reliable – the IAP device server receives all polls sent without error. The result is that the
master/client retries, which makes it harder for the IAP device server to catch up.
2. IAP device server receives the poll, but the serial link is busy so it waits - possibly another
MB/TCP master is being serviced or timeouts waiting on off-line stations are creating a
backlog of new requests.
3. After approximately 850 msec, the serial link is now free and the IAP device server forwards
the MB/RTU request.
4. The IAP device server receives the response, and since the timeout on the IAP device server
and master are not inherently synchronized, the IAP device server sends the MB/TCP
response into the TCP socket.
5. In the best of times, it may take 5-10 msec for this response to actually go down the IAP
device server's TCP stack, across the wire, and up the master's TCP stack. If a WAN or
satellite is involved, it could take 750 msec or longer.
6. Meanwhile, before the master receives the Response #A, it gives up and makes the
Modbus/RTU assumption that the request must have been lost. The master sends out a new
MB/TCP Poll #B.
7. A few msec later, there is a response that looks like a good Response #B, but really is
Response #A. If the master does not use a sequence number (which many do not) and has
forgotten about pending poll #A, it wrongly assumes this is response #B (possibly with
catastrophic results if Poll #B was the same size but different register range). Here is the
source of the problem “IAP Device Server returns the wrong data for wrong slave.”
8. The master is idle and has no outstanding polls. Yet the IAP device server has received Poll
#B by TCP/IP. It sends this out to Modbus/RTU slave and gets an answer. The IAP device
server is doing its job!
9. The IAP device server returns Response #B to the master (if the socket is still open) and
there it sits in its TCP/IP buffer. The master is not expecting more responses, so it neither
receives nor purges the "extra" response.
10. Master sends Poll #C and magically finds "a response" waiting as soon as it looks in the
receive buffer - yet this is stale Response #B received before poll #C was even issued. If the
master does not implement Modbus/TCP sequence numbers, then it accepts the response
#B as satisfying poll #C. Imagine if the master is putting out 300 polls per minute (5 polls per
second), but the IAP device server can only process on average 290 of those per minute and
some carry over. After 10 minutes, you may have up to 100 “stale” responses waiting in your
master’s TCP buffer. This makes it appear as though there is now a 20-second “lag” in data
reaching the master. Here is the source of your “data taking longer and longer to
propagate to Master/Client” problem.
However, if the master does implement Modbus/TCP sequence numbers, then the stale
responses are rejected. If the master is smart enough to resynchronize itself (Response #B
does not kill poll #C, but master waits more), then this resynchronization will manifest itself as
the slaves going off-line and back on-line intermittently. If the master is not smart enough
to resynchronize, once this out-of-sync behavior occurs, your slaves go permanently off-
line.
As you can see, this Modbus/TCP master is out of sync and the only cure may be to either restart
the master or power cycle the IAP device server. Both actions close the socket and purge the
backlogged messages.
Our Network-to-Serial product brings out this shortcoming in master/client Modbus/TCP designs,
but even a pure MB/TCP-to-MB/TCP network would suffer from this problem if the poll cycle
approached the average response time. Any Modbus/TCP network going through WAN will
discover this.
Ideally all Modbus/TCP master applications must implement the sequence number and gracefully
handle receipt of stale responses with unexpected sequence numbers. Unfortunately, the
Modbus/TCP specification says that this sequence number is optional and can be used by a
master to match responses to requests; however it can usually be just left as zero. The
Modbus/TCP slave just echoes this back in the response. So most Modbus/TCP OPC servers
today do not implement the sequence number.
Slow down your poll rate. You have to consider the worst-case response time – assume all
polls timeout. If you have five slaves that normally answer in less than 100 msec each, but
you must use a 250-msec message timeout, then polling each of the five 1.25 sec is the only
promised safe rate.
If you are only polling a single slave (or poll one slave at a time), then you can try the
“Disable Pipeline” option in the IAP device server firmware. This will either help or make
things hopelessly worse. If your OPC server or host application relies on pipelining to send
more than one outstanding poll at once, then disabling the pipeline will essentially stop all
data communication. (In which case, you can just turn the pipeline back on!)
The ideal solution (the 2nd generation solution) is for your Modbus/TCP master/client to not
only support the Sequence Number, but also support the receipt of the 0x0A and 0x0B
extended Modbus/TCP exception response. Then the master/client never needs to do retries
– for each poll, it will receive either a value Modbus/TCP response or a Modbus/TCP
exception that the slave is unreachable or timed out. This prevents the master/client from
sending more polls than the IAP device server can process and building the TCP buffer
queue up in the first place.