Modbus Help
ESERV-M12T Modbus Gateway
46
ESERV-M12T
(Rev. 1210)
MODBUS ASCII/RTU BASICS
The Modbus protocol emerged in the mid-1970s as an early protocol for linking terminals with Modicon PLCs using
a master/slave (sometimes called a master/client) relationship. A simple, open, message-based protocol, it caught
on quickly and became a de facto standard in the industry. It supports asynchronous point-to-point and multidrop
communications and can be used with a variety of serial interfaces (RS-232, RS-422, RS-485, modems, etc).
The original Modbus specification included two possible transmission modes: ASCII and RTU. Modbus RTU mode is
the most common implementation, using binary coding and CRC error-checking. Modbus ASCII messages, though
somewhat more readable because they use ASCII characters, is less efficient and uses less effective LRC error
checking. ASCII mode uses ASCII characters to begin and end messages whereas RTU uses time gaps (3.5 character
times) of silence for framing. The two modes are incompatible so a device configured for ASCII mode cannot
communicate with one using RTU.
All Modbus communications are initiated by Modbus masters using a polling query/response format. The master
can send broadcast messages (using a slave address of 0), which all slaves accept, but do not reply to. More
commonly the master polls individual slaves sequentially. In each poll it sends a message containing a
device
address
, followed by a
function code
, any
data
that maybe required, and an
error check
field. The addressed slave
responds with a similar message structure. Typically it repeats back its address and the function code, and then
sends a field indicating the number of bytes of data it is sending, followed by the data and the error check field.
Slave addresses can range from 1 to 247. Function codes include several common ones typically used in all
applications, and additional ones that may be implemented in specific cases. Common function codes include:
Read Coil Status (01), Read Input Status (02), Read Holding Registers (03) and Read Input Registers (04).
When a master sends a message to a slave it expects to receive a valid response within certain length of time. If
the slave does not receive the message, or if the slave receives the message but an error is detected, it does not
respond. If the slave cannot respond appropriately for some other reason (e.g. it does not recognize the function
code), it will return a message containing an exception response.
HINTS AND TIPS
A few simple suggestions that may assist you if your system is experiencing problems include:
Slowing down the polling rate may be helpful if power cycling doesn’t cure the
problem.
A common misperception is that every serial network must terminate with a
resistor. While this was true of early serial network configurations, it’s typically t
he
wrong answer
–
call our technical support and verify if you’re an exception, at
251-
342-2164.
A sometimes difficult problem is difference in grounding voltage between various network locations. Stray voltage
from lightning or other sources may also find its way onto the network. These conditions make isolation necessary
in many settings.
Summary of Contents for ESERV-M12T
Page 1: ...ESERV M12T Modbus Gateway User Manual...
Page 12: ...Hardware ESERV M12T Modbus Gateway 7 ESERV M12T Rev 1210 Figure 9 ESERV M12T DIN Clips...
Page 40: ...Modbus Help ESERV M12T Modbus Gateway 35 ESERV M12T Rev 1210 Figure 24 Modbus Priority...
Page 46: ...Modbus Help ESERV M12T Modbus Gateway 41 ESERV M12T Rev 1210 Figure 31 Port 1 Modbus...
Page 48: ...Modbus Help ESERV M12T Modbus Gateway 43 ESERV M12T Rev 1210 Figure 33 Modbus Slave ID Routing...