History of the Modbus protocol
Some communication standards just emerge. Not because they are pushed by a large group of vendors or a special standards
organisation. These standards—like the Modbus interface—emerge because they are good, simple to implement and are
therefore adapted by many manufacturers. Because of this, Modbus became the first widely accepted fieldbus standard.
Modbus has its roots in the late seventies of the previous century. It is 1979 when PLC manufacturer Modicon—now a brand of
Schneider Electric's Telemecanique—published the Modbus communication interface for a multidrop network based on a
master/client architecture. Communication between the Modbus nodes was achieved with messages. It was an open standard
that described the messaging structure. The physical layer of the Modbus interface was free to choose. The original Modbus
interface ran on RS-232, but most later Modbus implementations used RS-485 because it allowed longer distances, higher
speeds and the possibility of a true multi-drop network. In a short time hundreds of vendors implemented the Modbus
messaging system in their devices and Modbus became the de facto standard for industrial communication networks.
The nice thing of the Modbus standard is the flexibility, but at the same time the easy implementation of it. Not only intelligent
devices like microcontrollers, PLCs etc. are able to communicate with Modbus, also many intelligent sensors are equipped with a
Modbus interface to send their data to host systems. While Modbus was previously mainly used on wired serial communication
lines, there are also extensions to the standard for wireless communications and TCP/IP networks.
General
Modbus is one of the oldest fieldbuses on the market. It was developed in 1978 by the engineers at Modicon... originators of
the first PLC. It's primary purpose was, of course, to exchange data between PLCs and other devices on the production floor.
Since it is one of the oldest communication protocols it uses a more traditional approach to connecting devices. That approach
is typically based upon a master/slave system over a serial line.(RS-232/485). Depending upon which Modbus protocol is used,
the communication can be either simple or peer-to-peer. The protocols available include ASCII/RTU or Modbus Plus.
(Modbus/TCP is also available to talk on an ethernet line).
Modbus RTU messages, although simple, contain a 16-bit CRC (Cyclic-Redundant Checksum) to ensure reliability.
The simplicity of Modbus RTU messages is a mixed blessing; on the one hand, the simple message structure ensures
widespread, rapid and accurate implementation, but on the other hand, various companies have corrupted the basic 16-bit
Modbus RTU register structure to pack in floating point, queues, ASCII text, tables and other types of non-Modbus data.
Modbus RTU is an open, serial (RS-232 or RS-485) protocol based on master/slave or client/server architecture. It is popular,
well established, relatively easy to implement and reliable. Since it is so easy to implement, Modbus RTU has gained wide
market acceptance wherever Industrial Automation Systems (IAS) or Building Management Systems (BMS) need to
communicate with other devices. In fact, Modbus RTU is probably the most implemented automation protocol of all.
Modbus controllers use a master/slave communication method. This means that only one device (ie. the master) can initiate
communication. The other devices (ie. slaves) respond to the masters communication messages. They either send back the
requested data or perform the requested operation. The master can talk with individual slave units or all slave units at one time
(ie. broadcast messages). Regardless of the transmission 'mode' (ie. ASCII or RTU) the communication cycle and contents
remains the same. The frame of the message looks like this:
Device Address
Function Code
8-bit Data Bytes
Error Checking
The master sends the above, the slave receives it and replies back in the same format. It's important to note that the messages
all have a known starting and ending point. This allows the receiving devices to know that a message has arrived, figure out if
it's for them or not, and know that the message has been completely received.
ASCII and RTU Modes
In ASCII/RTU modes (traditional Modbus) the user chooses either mode along with the serial port parameters (ie. baud rate,
parity, etc). These parameters must be the same for all devices on the Modbus network. Five wires is used for communication
(#18AWG twisted pairs in a shielded jacket is generally recommended). Maximum transmission distance is 350m (1137ft).
ASCII mode: (American Standard Code for Information Interchange). This mode has an advantage of allowing up to 1 second
time intervals to occur between character transmissions without generating an error. It's most useful when communication is
slow. Two ASCII characters are sent as 8-bit data. A start and stop bit are also sent with each message creating a total of 10
bits. 7 data bits comprise the message and 1 bit is added for either even or odd parity. If no parity is used then the extra stop
bit is added to maintain a total transmission of 10 bits. It also uses LRC (Longitudinal Redundancy Check) to make sure what
we sent is what we received.
RTU mode (Remote Terminal Unit). This mode has an advantage of sending more data in the same amount of time as in ASCII
mode. Each message must be transmitted as a continuous stream of data, however. Each 8-bit message will contain two 4 bit
hex characters, thus sending the same amount of information in less space. Since we use an extra data-bit (8 vs 7) we send 11
bits in total. 8 data bits are used and 1 bit is used for either even or odd parity. If no parity is used, then an additional stop bit
is added. This brings our total then to 11 bits (1 start + 8 data + 1 parity + 1 stop = 11 bits). This message uses CRC (Cyclical
Redundancy Check) for error checking.
It is important to note that both ASCII and RTU modes use a master/slave configuration. This means that only a single device
(ie. the master) can issue commands. The other devices (ie slaves) can only respond. The master can send messages to
individual slaves or broadcast to all devices. If peer-to-peer communication is required, an 'upgrade' to the later Modbus Plus is
required. On this type of network, any device can initiate communication with any other device on the network. This adds
many advantages in flexibility of communication. However, even though it is peer-to-peer, on the message level it is
master/slave. In other words, if a device asks another a question, it acts as a master and expects a reply from the other device
which is acting as a slave. Modbus Plus also allows us to interface with up to 32 devices at a total distance of 1500m
(~4875ft). 3 repeaters may be used to get a total distance of 6000m (19,500ft) and 64 devices. Modbus generally needs its
own 12v supply to communicate and each device needs its own supply. In other words, the devices cannot be powered by the
communications line.
ASCII message format:
start(1 character) + address(2 characters) + function(2 characters) + data(x characters) + error check(2 characters) +
ending(2 characters). In ASCII mode the start character is always a ':' (ie. a colon, no quotes included).
The address field contains 2 characters. The valid slave device addresses are 0-247. The master addresses the proper slave
device by putting the slave devices address in this field. When the slave replies back it places its own address in this field so
that the master knows which device has replied. Address 0 is used as a broadcast address. In other words, all slaves will react
to a message with an address of 0.
The function code also contains 2 characters. Valid function codes are 1-255. Some codes are product specific(to Modicon),
others are universal, and still others are reserved for future use. The function code tells the slave device what to do. Some
examples of function codes include reading coil status, reading input status, reading memory locations, forcing coils on, writing
to memory, etc.
The data field comes next and contains information that the slave devices will need to process the request from the master. For
example, which coil statuses should be read, which coils should be forced on, etc.
The data field the slave sends back to the master will contain the data requested or an error code if there was an error. The
error check field in ASCII mode contains the result of the LRC (Longitudinal Redundancy Check) calculation. This calculation is
simply done by adding together all the bytes in the message(excluding the start colon) eliminating any carries, and then 2's
complementing the result.
Lastly, the CR (carriage return) and LF (line feed) characters are added to the message. This tells the receiving device that the
message has ended.
The RTU frames contain the same items except in a more compact form. Here is the message format:
Start(4 character delay time) + address(8 bits) + function code(8 bits) + data(n x 8 bits) + error check(16 bits) + end (4
character delay time)
It is important to note that in ASCII mode there can be up to a 1 second delay between each character transmission but RTU
mode can have a maximum of 1.5 character delay times between each character.
The only differences between ASCII and RTU message formats are the forming of the message, the start/ends, and the error
checking. The start/ends are simply 4 character time pauses. The error checking is CRC (Cyclical Redundancy Check) calculation.
Modbus message structure
The Modbus communication interface is built around messages. The format of these Modbus messages is independent of the
type of physical interface used. On plain old RS232 are the same messages used as on Modbus/TCP over ethernet. This gives
the Modbus interface definition a very long lifetime. The same protocol can be used regardless of the connection type. Because
of this, Modbus gives the possibility to easily upgrade the hardware structure of an industrial network, without the need for
large changes in the software. A device can also communicate with several Modbus nodes at once, even if they are connected
with different interface types, without the need to use a different protocol for every connection.
On simple interfaces like RS485 or RS232, the Modbus messages are sent in plain form over the network. In this case the
network is dedicated to Modbus. When using more versatile network systems like TCP/IP over ethernet, the Modbus messages
are embedded in packets with the format necessary for the physical interface. In that case Modbus and other types of
connections can co-exist at the same physical interface at the same time. Although the main Modbus message structure is
peer-to-peer, Modbus is able to function on both point-to-point and multidrop networks.
Each Modbus message has the same structure. Four basic elements are present in each message. The sequence of these
elements is the same for all messages, to make it easy to parse the content of the Modbus message. A conversation is always
started by a master in the Modbus network. A Modbus master sends a message and—depending of the contents of the
message—a slave takes action and responds to it. There can be more masters in a Modbus network. Addressing in the message
header is used to define which device should respond to a message. All other nodes on the Modbus network ignore the message
if the address field doesn't match their own address.
Modbus serial transmission modes: Modbus/ASCII and Modbus/RTU
Serial Modbus connections can use two basic transmission modes, ASCII or RTU, remote terminal unit. The transmission mode
in serial communications defines the way the Modbus messages are coded. With Modbus/ASCII, the messages are in a readable
ASCII format. The Modbus/RTU format uses binary coding which makes the message unreadable when monitoring, but reduces
the size of each message which allows for more data exchange in the same time span. All nodes on one Modbus network
segment must use the same serial transmission mode. A device configured to use Modbus/ASCII cannot understand messages
in Modbus/RTU and vice versa.
When using Modbus/ASCII, all messages are coded in hexadecimal values, represented with readable ASCII characters. Only
the characters 0...9 and A...F are used for coding. For every byte of information, two communication-bytes are needed,
because every communication-byte can only define 4 bits in the hexadecimal system. With Modbus/RTU the data is exchanged
in a binary format, where each byte of information is coded in one communication-byte.
Modbus messages on serial connections are not sent in a plain format. They are framed to give receivers an easy way to detect
the beginning and end of a message. When using Modbus/ASCII, characters are used to start and end a frame. The colon ':' is
used to flag the start of a message and each message is ended with a CR/LF combination. Modbus/RTU on the other hand uses
time gaps of silence on the communication line for the framing. Each message must be preceded by a time gap with a minimum
length of 3.5 characters. If a receiver detects a gap of at least 1.5 characters, it assumes that a new message is comming and
the receive buffer is cleared. The main advantage of Modbus/ASCII is, that it allowes gaps between the bytes of a message with
a maximum length of 1 second. With Modbus/RTU it is necessary to send each message as a continuous stream.
Modbus addressing
The first information in each Modbus message is the address of the receiver. This parameter contains one byte of information.
In Modbus/ASCII it is coded with two hexadecimal characters, in Modbus/RTU one byte is used. Valid addresses are in the
range 0..247. The values 1..247 are assigned to individual Modbus devices and 0 is used as a broadcast address. Messages
sent to the latter address will be accepted by all slaves. A slave always responds to a Modbus message. When responding it
uses the same address as the master in the request. In this way the master can see that the device is actually responding to
the request.
Within a Modbus device, the holding registers, inputs and outputs are assigned a number between 1 and 10000. One would
expect, that the same addresses are used in the Modbus messages to read or set values. Unfortunately this is not the case. In
the Modbus messages addresses are used with a value between 0 and 9999. If you want to read the value of output (coil) 18
for example, you have to specify the value 17 in the Modbus query message. More confusing is even, that for input and holding
registers an offset must be substracted from the device address to get the proper address to put in the Modbus message
structure. This leads to common mistakes and should be taken care of when designing applications with Modbus. The following
table shows the address ranges for coils, inputs and holding registers and the way the address in the Modbus message is
calculated given the actual address of the item in the slave device.
Modbus function codes
The second parameter in each Modbus message is the function code. This defines the message type and the type of action
required by the slave. The parameter contains one byte of information. In Modbus/ASCII this is coded with two hexadecimal
characters, in Modbus/RTU one byte is used. Valid function codes are in the range 1..255. Not all Modbus devices recognize the
same set of function codes. The most common codes are discussed here.
Normally, when a Modbus slave answers a response, it uses the same function code as in the request. However, when an error
is detected, the highest bit of the function code is turned on. In that way the master can see the difference between success
and failure responses.
Function 01: Read coil status
In Modbus language, a coil is a discrete output value. Modbus function 01 can be used to read the status of such an output. It
is only possible to query one device at a time. Broadcast addressing is not supported with this Modbus function. The function
can be used to request the status of various coils at once. This is done by defining an output range in the data field of the
message.
When receiving a Modbus query message with function 01, the slave collects the necessary output values and constructs an
answer message. The length of this message is dependent on the number of values that have to be returned. In general,
when N values are requested, a number of ((N+7) mod 8) bytes are necessary to store these values. The actual number of
databytes in the datablock is put in the first byte of the data field. Therefore the general structure of an answer to a Modbus
function 01 query is:
After receiving a query message with Modbus function 02, the slave puts the requested input values in a message structure
and sends this message back to the Modbus master. The length of the message depends on the number of input values
returned. This causes the length of the output message to vary. The number of databytes in the data field that contain the
input values is passed as the first byte in the data field. Each Modbus answering message has the following general structure.
Function 03: Read holding registers
Internal values in a Modbus device are stored in holding registers. These registers are two bytes wide and can be used for
various purposes. Some registers contain configuration parameters where others are used to return measured values
(temperatures etc.) to a host. Registers in a Modbus compatible device start counting at 40001. They are addressed in the
Modbus message structure with addresses starting at 0. Modbus function 03 is used to request one or more holding register
values from a device. Only one slave device can be addressed in a single query. Broadcast queries with function 03 are not
supported.
After processing the query, the Modbus slave returns the 16 bit values of the requested holding registers. Because of the size of
the holding registers, every register is coded with two bytes in the answering message. The first data byte contains the high
byte, and the second the low byte of the register. The Modbus answer message starts with the slave device address and the
function code 03. The next byte is the number of data bytes that follow. This value is two times the number of registers
returned. An error check is appended for the host to check if a communication error occured.
Details of ASCII and RTU mode message formats:
ASCII message format:
start(1 character) + address(2 characters) + function(2 characters) + data(x characters) + error check(2 characters) +
ending(2 characters)
In ASCII mode the start character is always a ':' (ie. a colon, no quotes included).
The address field contains 2 characters. The valid slave device addresses are 0-247. The master addresses the proper slave
device by putting the slave devices address in this field. When the slave replies back it places its own address in this field so
that the master knows which device has replied. Address 0 is used as a broadcast address. In
other words, all slaves will react to a message with an address of 0.
The function code also contains 2 characters. Valid function codes are 1-255. Some codes are product specific to Modicon,
others are universal, and still others are reserved for future use. The function code tells the slave device what to do. Some
examples of function codes include reading coil status, reading input status, reading memory locations, forcing coils on, writing
to memory, etc.
The data field comes next and contains information that the slave devices will need to process the request from the master. For
example, which coil statuses should be read, which coils should be forced on, etc. The data field the slave sends back to the
master will contain the data requested or an error code if there was an error.
The error check field in ASCII mode contains the result of the LRC (Longitudinal Redundancy Check) calculation. This calculation
is simply done by adding together all the bytes in the message (excluding the start colon) eliminating any carries, and then 2's
complementing the result.
Lastly, the CR (carriage return) and LF (line feed) characters are added to the message. This tells the receiving device that the
message has ended.
The RTU frames contain the same items except in a more compact form.
Here is the message format:
Start(4 character delay time) + address(8 bits) + function code(8 bits) + data(n x 8 bits) + error check(16 bits) + end (4
character delay time)
It is important to note that in ASCII mode there can be up to a 1 second delay between each character transmission but RTU
mode can have a maximum of 1.5 character delay times between each character. The only differences between ASCII and RTU
message formats are the forming of the message, the start/ends, and the error checking. The start/ends are simply 4 character
time pauses. The error checking is CRC (Cyclical Redundancy Check) calculation.
Literature
- The Modbus technical resources on the Modbus-IDA site are a good starting point for those who need the latest information
about implementing and using the Modbus interface. Modbus-IDA is the current driving force behind the promotion and
implementation of the Modbus protocol.
Introduction to RS485
RS232, RS422, RS423 and RS485 are serial communication methods for computers and devices. RS232 is without doubt the
best known interface, because this serial interface is implemented on almost all computers available today. But some of the
other interfaces are certainly interesting because they can be used in situations where RS232 is not appropriate. We will
concentrate on the RS485 interface here.
RS232 is an interface to connect one DTE, data terminal equipment to one DCE, data communication equipment at a
maximum speed of 20 kbps with a maximum cable length of 50 feet. This was sufficient in the old days where almost all
computer equipment were connected using modems, but soon after people started to look for interfaces capable of one or more
of the following:

Connect DTE's directly without the need of modems

Connect several DTE's in a network structure

Ability to communicate over longer distances

Ability to communicate at faster communication rates
RS485 is the most versatile communication standard in the standard series defined by the EIA, as it performs well on all four
points. That is why RS485 is currently a widely used communication interface in data acquisition and control applications where
multiple nodes communicate with each other.
Differential signals with RS485:
Longer distances and higher bit rates
One of the main problems with RS232 is the lack of immunity for noise on the signal lines. The transmitter and receiver
compare the voltages of the data- and handshake lines with one common zero line. Shifts in the ground level can have
disastrous effects. Therefore the trigger level of the RS232 interface is set relatively high at ±3 Volt. Noise is easily picked up
and limits both the maximum distance and communication speed. With RS485 on the contrary there is no such thing as a
common zero as a signal reference. Several volts difference in the ground level of the RS485 transmitter and receiver does not
cause any problems. The RS485 signals are floating and each signal is transmitted over a Sig+ line and a Sig- line. The
RS485 receiver compares the voltage difference between both lines, instead of the absolute voltage level on a signal line. This
works well and prevents the existence of ground loops, a common source of communication problems. The best results are
achieved if the Sig+ and Sig- lines are twisted. The image below explains why.
In the picture above, noise is generated by magnetic fields from the environment. The picture shows the magnetic field lines
and the noise current in the RS485 data lines that is the result of that magnetic field. In the straight cable, all noise current is
flowing in the same direction, practically generating a looping current just like in an ordinary transformer. When the cable is
twisted, we see that in some parts of the signal lines the direction of the noise current is the oposite from the current in other
parts of the cable. Because of this, the resulting noise current is many factors lower than with an ordinary straight cable.
Shielding—which is a common method to prevent noise in RS232 lines—tries to keep hostile magnetic fields away from the
signal lines. Twisted pairs in RS485 communication however adds immunity which is a much better way to fight noise. The
magnetic fields are allowed to pass, but do no harm. If high noise immunity is needed, often a combination of twisting and
shielding is used as for example in STP, shielded twisted pair and FTP, foiled twisted pair networking cables. Differential signals
and twisting allows RS485 to communicate over much longer communication distances than achievable with RS232. With
RS485 communication distances of 1200 m are possible.
Differential signal lines also allow higher bit rates than possible with non-differential connections. Therefore RS485 can
overcome the practical communication speed limit of RS232. Currently RS485 drivers are produced that can achieve a bit rate
of 35 mbps.
What does all the information in this table tell us? First of all we see that the speed of the differential interfaces RS422 and
RS485 is far superior to the single ended versions RS232 and RS423. We also see that there is a maximum slew rate defined
for both RS232 and RS423. This has been done to avoid reflections of signals. The maximum slew rate also limits the
maximum communication speed on the line. For both other interfaces—RS422 and RS485—the slew rate is indefinite. To avoid
reflections on longer cables it is necessary to use appropriate termination resitors.
We also see that the maximum allowed voltage levels for all interfaces are in the same range, but that the signal level is lower
for the faster interfaces. Because of this RS485 and the others can be used in situations with a severe ground level shift of
several volts, where at the same time high bit rates are possible because the transition between logical 0 and logical 1 is only a
few hundred millivolts.
Interesting is, that RS232 is the only interface capable of full duplex communication. This is, because on the other interfaces
the communication channel is shared by multiple receivers and—in the case of RS485—by multiple senders. RS232 has a
separate communication line for transmitting and receiving which—with a well written protocol—allows higher effective data
rates at the same bit rate than the other interfaces. The request and acknowledge data needed in most protocols does not
consume bandwidth on the primary data channel of RS232.
Network topology with RS485
Network topology is probably the reason why RS485 is now the favorite of the four mentioned interfaces in data acquisition
and control applications. RS485 is the only of the interfaces capable of internetworking multiple transmitters and receivers in
the same network. When using the default RS485 receivers with an input resistance of 12 kΩ it is possible to connect 32
devices to the network. Currently available high-resistance RS485 inputs allow this number to be expanded to 256. RS485
repeaters are also available which make it possible to increase the number of nodes to several thousands, spanning multiple
kilometers. And that with an interface which does not require intelligent network hardware: the implementation on the software
side is not much more difficult than with RS232. It is the reason why RS485 is so popular with computers, PLCs, micro
controllers and intelligent sensors in scientific and technical applications.
In the picture above, the general network topology of RS485 is shown. N nodes are connected in a multipoint RS485 network.
For higher speeds and longer lines, the termination resistances are necessary on both ends of the line to eliminate reflections.
Use 100 Ω resistors on both ends. The RS485 network must be designed as one line with multiple drops, not as a star.
Although total cable length maybe shorter in a star configuration, adequate termination is not possible anymore and signal
quality may degrade significantly.
RS485 functionality
And now the most important question, how does RS485 function in practice? Default, all the senders on the RS485 bus are in
tri-state with high impedance. In most higher level protocols, one of the nodes is defined as a master which sends queries or
commands over the RS485 bus. All other nodes receive these data. Depending of the information in the sent data, zero or
more nodes on the line respond to the master. In this situation, bandwidth can be used for almost 100%. There are other
implementations of RS485 networks where every node can start a data session on its own. This is comparable with the way
ethernet networks function. Because there is a chance of data collosion with this implementation, theory tells us that in this
case only 37% of the bandwidth will be effectively used. With such an implementation of a RS485 network it is necessary that
there is error detection implemented in the higher level protocol to detect the data corruption and resend the information at a
later time.
There is no need for the senders to explicity turn the RS485 driver on or off. RS485 drivers automatically return to their high
impedance tri-state within a few microseconds after the data has been sent. Therefore it is not needed to have delays between
the data packets on the RS485 bus.
RS485 is used as the electrical layer for many well known interface standards, including Profibus and Modbus. Therefore
RS485 will be in use for many years in the future.
ASCII, the history
The most used computer standard is without doubt ASCII, the American Standard Code for Information Interchange. When
people started to develop computers, they had to define a way to represent certain types of information in a digital format. For
numbers this was relatively easy, but text representation was far more difficult. Morse code was developed in the 19th century,
but could not be easily adapted to the binary system in computers because the codes used for characters have different lengths
and there is no obvious sorting method.
IBM came in the sixties of the previous century with it's own solution EBCDIC, Extended Binary Coded Decimal Interchange
Code used on their mainframes and AS/400 systems. But this system had some drawbacks. The letters of the alphabet were
placed in blocks which is not very useful for sorting. At the same time that IBM was developing her EBCDIC solution, others
computer developers were creating their own.
It became evident that exchanging data between various computer systems would be a huge problem if this diversity would not
stop. It was therefore that Bob Bemer—now often called the Father of ASCII—compiled all different coding methods in a huge
list. It was this list that made computer manufacturers realize that something had to be done about this situation quiclky. Bob
Bemer started standardization committees, and the first implementation of ASCII was introduced in 1963. Extensions for
foreign languages were adopted to ASCII in 1967, and in 1968 it finally became an official government standard.
Nowadays 100% of all computers use the ASCII coding as their primary coding system. Extensions for foreign languages are all
coded as a superset of ASCII. Therefore we can say without doubt that ASCII is the most used computer standard in the world.
ASCII character set table
The ASCII character set has been adopted as the standard in information exchange. The first 32 characters and the last one are
control codes, the others are printable characters. The control codes DC1 (XON) and DC3 (XOFF) are used in software flow
control applications. The following table shows the ASCII character set.
ASCII control codes in detail
0 – NUL – Null character
The NUL character in the ASCII character set was originally ment to be treated as a NOP, a character to be ignored. This
would be useful on paper tapes where additional information had to be added in between existing information. However,
some printing devices had the NUL implemented as a wite space instead. Later on, the importance of the null character
increased significantly when it was defined as the string terminator in the C programming language. It made it possible
to define strings of infinite length in programming languages. Until then most languages like Pascal defined a string as a
length indicator, followed by an array that contained the characters.
1 – SOH – Start of heading
If the communication primarily exists of commands and messages, the SOH can be used to mark the beginning of each
message header. In the original 1963 definition of the ASCII standard the name start of message was used, which has
been renamed to start of heading in the final release. Nowadays we often see the SOH used in serial RS232
communications where there is a master-slave configuration. Each command from the master starts with the SOH. This
makes it possible for the slave or slaves to resynchronize on the next command when data errors occured. Without a
clear marking of the start of each command a resync might be problematic to implement.
2 – STX – Start of text
3 – ETX – End of text
A message based communication protocol will probably use messages with a header containing addressing information,
followed by the actual content. The ASCII STX indicates the start of the content part in such a message. This control
code automatically ends a previous header, i.e. there is no control code to close a header started by SOH. The end of
the message content is signalled with control character ETX. The actual contents of a message are not defined by the
ASCII standard and are protocol dependent. Interesting to note is, that in the 1963 draft of the standard, naming
conventions differed. STX was in this draft called EOA, end of address and ETX started its life as EOM, end of message.
This is because in the original draft a message always contained a start and stop control character. The new definition
allowed to use only the SOH to send a fixed length command, without the need to end the command with a trailing
control code. In fact, in current serial protocols we see this commonly used where fixed length messages are sent
without a distinction between the header and content.
4 – EOT – End of transmission
5 – ENQ – Enquiry
6 – ACK – Acknowledgment
7 – BEL – Audible bell
The BEL code is an interesting one in the ASCII set as it is not primarily used for data coding or device control. Instead
it is used to attract human attention with an audible sound. It was intended to be used on both computers and devices
like printers. In the programming language C the control code \a is used the bell signal.
8 – BS – Backspace
The functionality of the backspace has changed over time. In the beginning it was primarily ment to move the cursor
one character backwards on printers and teletypes to make accents on characters possible. For example to generate the
character â one could send the sequence aBS^ to the printer. This method was a practical copy of the way how
characters with accents were handled on mechanical typewriters, but when CRT's were introduced it was no longer
supported in that way. Therefore now the backspace is most often used to not only reposition the cursor, but also delete
the actual contents on that position. You can use this control character as \b in the C programming language.
9 – HT – Horizontal tab
The HT control character in the ASCII character set is defined for layout purposes. It instructs the output device to
proceed to the next table column. Table column width is flexible, but on many devices the distance between table
columns defaults to 8. The use of the horizontal tab not only reduced the work for data typists, but also introduced a
method to reduce the amount of storage space necessary for formatted texts. We will now laugh about it, but keep in
mind that the ASCII standard was developed 40 years ago when every byte of storage was valuable, and compression
methods like ZIP, didn't exist. The control character HT is available as \t in the C programming language.
10 – LF – Line feed
The line feed character is one of the characters in the ASCII character set that has been misused. Originaly, the LF
character was ment to move the head of a printer one line down. A second control character CR would then be used to
move the printing head to the left margin. This is the way it was implemented in many serial protocols and in operating
systems like MS-DOS and Windows. On the other hand the C programming language and Unix operating system
redefined this character as newline which ment a combination of line feed and carriage return. You can argue about
which use is wrong. The way C and Unix handle it is certainly more natural from a programming point of view. On the
other hand is the MS-DOS implementation closer to the original definition. It would have been better if both line feed
and newline were part of the original ASCII definition because the first defines a typical device control functionality
where the latter is a logical text separator. But this separation is not the case. Nowadays people tend to use the LF
character mainly as newline function and most software that handles plain ASCII text files is capable of handling both
single LF and CR/LF combinations. The control character is in the programming language C available as \n.
11 – VT – Vertical tab
The vertical tab is like the horizontal tab defined to reduce the amount of work for creating layouts, and also reduce the
amount of storage space for formatted text pages. The VT control code is used to jump to the next marked line. To be
honest, I have never seen a situation or application where this functionality was implemented. In most situations a
sequence of LF codes is used instead.
12 – FF – Form feed
The form feed code FF was designed to control the behaviour of printers. When receiving this code the printer moves to
the next sheet of paper. The behaviour of the control code on terminals depends on the implementation. Some clear the
screen, whereas others only display the ^L characters or perform a line feed instead. The shell environments Bash and
Tcsh have implemented the ASCII form feed as a clear screen command. The form feed is implemented as \f in the
C programming language.
13 – CR – Carriage return
The carriage return in the ASCII character set in its original form is ment to move the printing head back to the left
margin without moving to the next line. Over time this code has also been assigned to the enter key on keyboards to
signal that the input of text is finished. With screen oriented representation of data, people wanted that entering data
would also imply that the cursor positioned to the next line. Therefore, in the C programming language and the unix
operating system, a redefinition of the LF control code has taken place to newline. Often software now silently translates
an entered CR to the LF ASCII code when the data is stored.
14 – SO – Shift out
15 – SI – Shift in
Even as early as in the sixties, the people who defined the ASCII character set understood that it would be valuable to
make the character set not only available for the English alphabet, but also for foreign ones. The shift in and shift out
were defined for this purpose. Originaly it was ment to switch between the cyrillic alphabet and latin. The cyrillic ASCII
definition which uses the shift characters is KOI-7. Later on these control codes were also used to change the typeface
on printers. In this use SO produced double wide characters where condensed printing was selected with SI.
16 – DLE – Data link escape
It is sometimes necessary in an ongoing data communication to send control characters. There are situations where
those control characters might be understood as part of the normal data stream. The DLE has been defined in the ASCII
standard for these situations. If this character is detected in a datastream, the receiving party knows, that one or more
of the following characters must be interpreted in a different way than the other characters in the stream. The exact
interpretation of the following characters is not part of the ASCII definition, just the availability to break out of a
communication stream with the data link escape. In the Hayes communication protocol for modems, the data link
escape has been defined as silence+++silence. In my opinion it would have been a better idea if the Hayes protocol had
used the DLE instead, as it does not need to embedded by communication silence, and it would fit within an existing
standard. However, the developers of Hayes decided otherwise and now the +++ sequence is used far more often then
the original DLE.
17 – DC1 – Device control 1 / XON – Transmission on
Although originally defined as DC1, this ASCII control code is now better known as the XON code used for software flow
control in serial communications. The main use is restarting the transmission after the communication has been stopped
by the XOFF control code. People who used to work with serial terminals probably remember that sometimes when data
errors occured, it helped to hit the Ctrl-Q key. This is because this key-sequence in fact generates the XON control code,
which unlocks a blocked communication when terminal or host computer accidentaly interpreted an errornous character
as XOFF.
18 – DC2 – Device control 2
19 – DC3 – Device control 3 / XOFF – Transmission off
20 – DC4 – Device control 4
21 – NAK – Negative acknowledgment
22 – SYN – Synchronous idle
23 – ETB – End of transmission block
24 – CAN – Cancel
25 – EM – End of medium
The EM is used at the end of a serial storage medium like paper tape or magnetic reels. It indicates the logical end of
the data. It is not necessary that this is also the physical end of the data carrier.
26 – SUB – Substitute character
27 – ESC – Escape
The escape character is one of the inventions in the ASCII standard that was proposed by Bob Bemer. It is used to start
an extended sequence of control codes. In this way it was not necessary to put all thinkable control codes in the ASCII
standard. As new technologies would need new control commands, the ESC would be present to be the starting
character of these multi-character commands. Escape codes are widely used in printers and terminals to control device
settings like fonts, text positioning and colors. If ESC had been absent in the original ASCII definition, the standard
would likely have been superseeded by some other standard in the past. The escape possibility allowed developers to
literaly escape from the standard where necessary, but use it whenever possible.
28 – FS – File separator
The file separator FS is an interesting control code, as it gives us insight in the way that computer technology was
organized in the sixties. We are now used to random access media like RAM and magnetic disks, but when the ASCII
standard was defined, most data was serial. I am not only talking about serial communications, but also about serial
storage like punch cards, paper tape and magnetic tapes. In such a situation it is clearly efficient to have a single control
code to signal the separation of two files. The FS was defined for this purpose.
29 – GS – Group separator
Data storage was one of the main reasons for some control codes to get in the ASCII definition. Databases are most of
the time setup with tables, containing records. All records in one table have the same type, but records of different
tables can be different. The group separator GS is defined to separate tables in a serial data storage system. Note that
the word table wasn't used at that moment and the ASCII people called it a group.
30 – RS – Record separator
Within a group (or table) the records are separated with RS or record separator.
31 – US – Unit separator
The smallest data items to be stored in a database are called units in the ASCII definition. We would call them field now.
The unit separator separates these fields in a serial data storage environment. Most current database implementations
require that fields of most types have a fixed length. Enough space in the record is allocated to store the largest possible
member of each field, even if this is not necessary in most cases. This costs a large amount of space in many situations.
The US control code allows all fields to have a variable length. If data storage space is limited—as in the sixties—this is a
good way to preserve valuable space. On the other hand is serial storage far less efficient than the table driven RAM and
disk implementations of modern times. I can't imagine a situation where modern SQL databases are run with the data
stored on paper tape or magnetic reels...
32 – SP – White space
You can argue if the space character is a real control character as it is so widely used in normal texts. But, as the
horizontal tab and backspace are also called control characters in the ASCII set, I think it is most natural to call the
white space or forward space also a control character. Afterall it doesn't represent a character by itself, but merely a
command to the output device to proceed one position forward, clearing the information in the current field. In many
applications like wordprocessors the white space is also a character that can cause lines to wrap, and web browsers
combine multiple spaces to just one output character. This stengthens my belief that it is not just representing a unique
character, but an information carrier for devices and applications.
127 – DEL – Delete
One might question why all control codes in the ASCII character set have low values, but the DEL control code has value
127. This is, because this specific character was defined for deleting data on paper tapes. Most paper tapes in that time
used 7 holes to code the data. The value 127 represents a binary pattern were all seven bits are high, so when using the
DEL character on an existing paper tape, all holes are punched and existing data is erased.
PLC programming cables for several brands
Most PLC's can be programmed from a PC via a serial cable. Unfortunately, many of these cables have a non standard layout.
De cables shown here can be bought from the regular sales channels, but it is often much cheaper to solder them yourself.
Siemens PLC's
Most programming of Siemens S5 PLC's is done using a special RS232 to TTY converter. The S7 series are programmed using a
RS232 to MPI bus converter. The easiest thing to do is buy these special cables from your local Siemens supplier. The operator
terminals however can be programmed using a normal serial cable. The following cable can be used to program the OP series of
operator displays.
Parallel cables
Standard parallel cables are easy to obtain, but the link cable and test connectors which are shown here can often be better
soldered by yourself.
Parallel connector pinout
The parallel port socket on your computer uses 25 pins. On most peripherals like printers, the 36 pins Centronics version is
used. Both connector pinouts are shown here. The centronics socket is named after the company that introduced the first dot
matrix printer in 1970, but after IBM and Epson took over the dot matrix printer market (later followed by Hewlett Packard in
the laser and deskjet printer segment) most people only associate the word centronics with the port interface itself, not with a
manufacturer.
Parallel printer cable
Most printers are connected to a computer using a cable with a 25 pins DB male connector at one side and a 36 pins centronics
connector on the other. The normal way to make such a cable is shown here.
Shortcomings of Modbus RTU
Report by Exception
As mentioned, Modbus RTU is a client/server or master/slave architecture. This means that in order for data to reach the client,
the client node needs to poll the server node. Modbus RTU can also be multi-dropped, or in other words, multiple slave devices
can exist on one Modbus RTU network, assuming that the physical layer allows this, usually via the use of RS-485, modems or
radio. Often dozens or hundreds of nodes are multi-dropped in this fashion, and at relatively low baud rates. Because of the low
speed and number of Modbus nodes involved, changes in the field nodes can take tens of seconds, or minutes, to reach the
client.
There have been various attempts to create Modbus RTU “report by exception” or “unsolicited message” enhancements.
However, as soon as this is done, the protocol is no longer Modbus RTU! Although the methodology may work if the same
vendor provides both the client and the server nodes, this approach almost guarantees incompatibilities.
If an application requires very fast data transfer it would probably be best to investigate a protocol that supports “report by
exception”, such as EtherNet/IP or BACnet.
Data Object Properties, or naming of the data
Modbus RTU packets only transfer data. There is no provision for parameters such as point name, units, resolution etc. Modern
protocols such as BACnet, EtherNet/IP and LonWorks all provide for these sorts of properties. In addition, there are various
committees that also create profiles for various types of devices, for example, thermostats, generators, light switches etc. The
LonMark organization (www.lonmark.org) does this for LonWorks. Once again, this has nothing to do with Modbus RTU.
Complexity of protocols that compete with Modbus RTU
At first glance the enhanced feature set mentioned above may seem to eliminate Modbus RTU as a contender for new designs.
However, Modbus RTU has been around much longer than these other protocols and currently has a larger market share. More
importantly, these other protocols are much harder to implement and support. For example, the source code for BACnet can be
had for about $20,000.00 and uses 32-100K of program memory. Also, there is no way that BACnet or EtherNet/IP can be fully
supported on a small 8-bit CPU or PIC processor, whereas Modbus RTU will easily fit into a spare 2K or so.
Maximum number of Modbus Addresses
Legal Modbus RTU node addresses are 1-254. 0 is reserved for broadcast messages, and useable for writes only. This is very
seldom used since there is no confirmation that the message was successfully received at the server node. If the physical later
is RS-232 then only one node can be implemented anyway. The RS-485 specification limits the number of nodes to 32,
although some RS-485 drivers will allow this limit to be extended somewhat.
Modbus RTU Conformance Testing
In order to guarantee compatibility, a Modbus Conformance Test Laboratory has been established at the University of Michigan.
See their website for more details. It needs to be remembered that although testing at this conformance test lab will guarantee
that the raw data reaches the other node, the other node may not understand what all the numbers mean. The receiver of the
data still needs to know what the data points in the “Modbus Memory Map” mean. FieldServers and ProtoCessors provide user
configurable tables to allow users to “remap” the data. See the section on the “Modbus RTU Memory Map” later.
Modbus RTU Interoperability Testing
As mentioned in the above section, simply guaranteeing that the data reaches the other node is not enough to guarantee that
two dissimilar systems will work together. In addition to “Modbus RTU Conformance Testing”, devices need to go through a
process of “Modbus RTU Interoperability Testing”. To my knowledge, there is no such organizations that do this testing at this
time. Once again, ProtoCessors and FieldServers, through the configuration file, take the raw Modbus RTU data and provision it
with additional properties such as names, units, alarm limits etc. and make all these properties available to the more
sophisticated protocol.
Modbus RTU vs Modbus/TCP
Officially now known as “IEC Publicly Available Spec: IEC PAS 62030 (pre-standard)” Modbus TCP could almost be defined as
Modbus RTU inside a TCP/IP connection, with a 6 byte header to allow routing. For more information on Modbus/TCP see the
official Modbus website at www.modbus.org. Other names that have been used for Modbus/TCP are Modbus/IP, Modbus
Ethernet and Modbus TCP/IP.
The Modbus RTU Memory Map
As defined, this Modbus RTU standard provides data in four Modbus memory map groups or data types.
Modbus RTU Data Type
Common name
Starting address
Modbus Coils
Bits, binary values, flags
00001
Digital Inputs
Binary inputs
10001
Analog Inputs
Analog inputs
30001
Modbus Registers
Analog values, variables
40001
Troubleshooting Modbus Systems
Troubleshooting a Modbus system is not as difficult as it may seem to be at first glance. Since the technology was developed in
the "old days" (ie. 1978) things are easier compared to today's network systems. But, then again, whether or not something is
easy is always related to our understanding level of the system we are using. Things always appear to be "easier" when we
know enough about the problem. If we don't know enough about the theory and technology in use, it takes much longer than
ideal as we investigate the technology used. When we understand the technology and have a good overview of the "big
picture", we can progress rather quickly.
Between 80% and 90% of network problems are related to... cabling. So, let's start out by investigating our cable system that
we have installed.
How are the connections? Everything nice and tight? Don't be surprised if machine vibration has caused a loose connection
since this happens all the time.
Is it grounded properly? We should have used shielded twisted-pair cables and grounded one end of the cable only. The cable
used should be around AWG18.
Are the cables run properly? In other words, we want to make sure never to run communication cables next to power lines.
That, of course, will lead to electrical noise issues that tend to give us sporadic problems.
If the connection issues seem to be OK for you after verification, then we can proceed onto some further troubleshooting.
Modbus includes a very nice troubleshooting function useful for diagnostics. Generally, this is labeled as function 8. Basically,
function 8 provides a nice series of test (via software) for checking communications between the master/slave modules and
other internal problems that can appear within the actual slave units. The function uses a 2-byte subfunction field to determine
the type of test to carry out. The slave will echo both the function 8 code as well as the subfunction code. In general, this
testing does not interfere with normal operation but we can put the slave device into a "listen only" mode if necessary. In this
mode the slave doesn't reply to communication commands. So, if your system requires it then a problem may be caused and
your system should be shut down for troubleshooting.
Function 8 usually takes the form of the following:
slave address -- 2 characters
function -- 08
subfunction Hi -- 2 characters
subfunction Lo -- 2 characters
Data Hi -- 2 characters
Data Lo -- 2 characters
Error check -- LRC or CRC
Some of the subfunction codes that are available include (but are not limited to... ) Return Query Data (ie. echo), Force Listen
Mode, Return Diagnostic Registers, etc. This list will certainly vary by model and manufacturer.