Issue/Rev. 0.1 (9/13) ║ MNFL003 • Page 5
1 – Introduction
The Modbus protocol was developed by Modicon, Inc. to be a concise method of
transferring data to/from programmable logic controllers (PLCs). It has become a
de-facto standard in many areas of industrial automation where supervisry control
or remote data collection is required. In a Modbus system, a host (master) commu-
nicates with one or multiple field devices (slaves). The microFlow.net Liquid acts as
a slave device only; an external host must act as the master to query or control the
microFlow.net Liquid. Each microFlow.net Liquid must have a unique communication
address in the range of 1 to 99. It is recommended that communications ports 2 or 3
on the microFlow.net Liquid be used for Modbus communications. Host messages
to address 0 (the Modbus broadcast address) are not currently supported (are
ignored) by the mcroFlow.net Liquid. For more information regarding Modbus commu-
nications specifics, refer to the Modbus Communications primer inthe Appendix.
1.1 Modbus/TCP
Modbus/TCP is a standard that defines a TCP/IP based version of the Modbus protocol
for use over communications links such as Ethernet, etc.
All requests are sent via TCP on registered
port 502
.
Requests are normally sent in half-duplex fashion on a given connection. That is, there is
no benefit in sending additional requests ona single connection while a response is
outstanding. Devices which wish to obtain high peak transfer rates are instead
encouraged to establish multiple TCP connections to the same target, however some
existing client devices are known to attempt to ‘pipeline’ requests. Design techniques
which allow a server to accommodate this behavior are described in Appendix A.
The Modbus ‘slave address’ field is replaced by a single byte ‘Unit Identifier’ which may
be used to communicate via devices such as bridges and gateways which use a single
IP address to support multiple independent end units.
The original Modbus protocol request and response are prefixed by six bytes in Modbus/
TCP as follows:
byte 0:
transaction identifier - copied by server - usually 0
byte 1:
transaction identifier - copied by server - usually 0
byte 2:
protocol identifier = 0
byte 3:
protocol identifier = 0
byte 4:
length field (upper byte) = 0 (since all messages are smaller than 256)
byte 5:
length field (lower byte) = number of bytes following
byte 6:
unit identifier (previously ‘slave address’)
byte 7:
Modbus function code
byte 8 and up: data as needed
So an example transaction ‘read 1 register at offset 4 from UI 9’ returning a value of 5
would be:
request: 00 00 00 00 00 06 09 03 00 04 00 01
response: 00 00 00 00 00 05 09 03 02 00 05
Designers familiar with Modbus should note that the ‘CRC-16’ or ‘LRC’ check fields are
NOT needed in Modbus/TCP. The TCP/IP and link layer (eg. Ethernet) checksum
mechanisms instead are used to verify accurate delivery of the packet.
For detailed specifications on the Modbus protocol refer to the following website:
.
microFlow.net Liquid Modbus Communications Manual
Introduction
