Unit 3 Modbus PDF
Unit 3 Modbus PDF
ModBus
5.1 Introduction
Many protocols have been designed for the needs of industrial automation and
metering. These protocols generally use simple query/response models and allow
for extremely simple implementations. Many protocols derived from the frame
formats defined by IEC 870-5 such as:
T101 (IEC 870-5-101) that was generated by the IEC TC57 for electric
utility communication between master stations and remote terminal
units, it is also based on the IEC-870-5-x link layer, using frame format
FT 1.2.
DNP 3.0, a protocol originally designed by Westronic, Inc. that was
released into the public domain in 1993, based on the IEC-870-5-x link
layer with a few modifications (e.g., use of FT3 frames for
asynchronous, rather than synchronous, communication, inclusion of
both source and destination addresses).
M-Bus (see Section 9.3)
Profibus, a fieldbus initially designed by Siemens and later
standardized as IEC 61 158 (“Digital Data Communication for
Measurement and control, Fieldbus for use in industrial control
systems” for versions DP-V0, DP-V1 and DP-V2) and IEC 61 784
(Communication Profile Family DPF3). The protocols user's
association website is http://www.profibus.com/.
Other protocols developed independently into de-facto standards, such as
ModBus, a very common protocol that is used in many industrial and HVAC
installations.
5.4 ModBus/TCP
The ModBus/TCP specification can be found at http://www.eecs.umich.edu/
∼modbus/documents/Open_ModbusTCP_Standard.doc
ModBus/TCP provides TCP/IP access to the ModBus functionality. Each
ModBus Request/response is sent over a TCP connection established between
the master and the slave, using well-known port 502. The TCP connection may
be reused for several query/response exchanges.
The byte content of the ModBus request and response frames (i.e. without
framing start-stop-parity bits specific to the serial physical layer) is simply
transported over the TCP connection, in big indian order. The only addition of
ModBusTCP is to add a seven-byte message prefix:
ref ref 00 00 00 len unit
The ref bytes are simply copied by the slave from the request, and may be used
as a handle by the master. The length information in the message prefix allows
proper reassembly of the ModBus message when it has been segmented in
several IP packets. The slave address has been renamed “unit identifier” and is
contained in unit. The rest of the message conforms to the regular ModBus
structure, but the error check fields may be omitted for obvious reasons.