meta data for this page
lamaPLC Communication: Modbus
Not to be confused with M-Bus!
Modbus is a data communications protocol originally published by Modicon (now Schneider Electric) in 1979 for use with its programmable logic controllers (PLCs). Modbus has become a de facto standard communication protocol and is now a commonly available means of connecting industrial electronic devices.
Modbus is popular in industrial environments because it is openly published and royalty-free. It was developed for industrial applications, is relatively easy to deploy and maintain compared to other standards, and places few restrictions on the format of the data to be transmitted.
The Modbus protocol uses character serial communication lines, Ethernet, or the Internet protocol suite as a transport layer. Modbus supports communication to and from multiple devices connected to the same cable or Ethernet network. For example, there can be a device that measures temperature and another device to measure humidity connected to the same cable, both communicating measurements to the same computer, via Modbus.
Modbus is often used to connect a plant/system supervisory computer with a remote terminal unit (RTU) in supervisory control and data acquisition (SCADA) systems. Many of the data types are named from industrial control of factory devices, such as ladder logic because of its use in driving relays: a single-bit physical output is called a coil, and a single-bit physical input is called a discrete input or a contact.
The development and update of Modbus protocols have been managed by the Modbus Organization since April 2004, when Schneider Electric transferred rights to that organization. The Modbus Organization is an association of users and suppliers of Modbus-compliant devices that advocates for the continued use of the technology. Modbus Organization, Inc. is a trade association for the promotion and development of the Modbus protocol.
Modbus TCP
Modbus TCP/IP or Modbus TCP – a Modbus variant used for communications over TCP/IP networks, connecting over port 502. It does not require a checksum calculation, as lower layers already provide checksum protection.
Important: Modbus over TCP/IP, Modbus over TCP, or Modbus RTU/IP – a variant that differs from Modbus TCP in that a checksum is included in the payload, as with Modbus RTU.
Modbus RTU
Modbus RTU (Remote Terminal Unit) – used in serial (typically RS485 2W-cabling or RS-232) communication, and is the most common implementation available for Modbus. Modbus RTU makes use of a compact, binary representation of the data for protocol communication.
The RTU format follows the commands/data with a cyclic redundancy check checksum as an error check mechanism to ensure the reliability of data. A Modbus RTU message must be transmitted continuously without inter-character hesitations. Modbus messages are framed (separated) by idle (silent) periods.
Limitations
- Since Modbus was designed in the late 1970s to communicate to programmable logic controllers, the number of data types is limited to those understood by PLCs at the time. Large binary objects are not supported.
- No standard way exists for a node to find the description of a data object, for example, to learn that a register value represents a temperature between 30 and 175 degrees.
- Since Modbus is a client/server (formerly master/slave) protocol, there is no way for a field device to get data by the event handler mechanism (except over Ethernet TCP/IP, called open-mbus) as the client node must routinely poll each field device and look for changes in the data. This consumes bandwidth and network time in applications where bandwidth may be expensive, such as over a low-bit-rate radio link.
- Modbus is restricted to addressing 247 devices on one data link, which limits the number of field devices that may be connected to a parent station (again, Ethernet TCP/IP is an exception).
- Modbus protocol itself provides no security against unauthorized commands or interception of data
- [Addressing] Valid address ranges as originally defined for Modbus were 0 to 9999 for each of the above register types. Valid ranges allowed in the current specification are 0 to 65,535.
- When using the extended register referencing, it is mandatory that all register references be exactly six digits.
- [Data Endianness] Multiregister data, like single-precision floating point value, can be easily transferred in Modbus by splitting the data across two registers. Because this is not defined by the standard, the endianness (or byte order) of this split is not defined. Although each unsigned word must be sent in network (big-endian) byte order to satisfy the standard, many devices reverse the byte order for multibyte data.
- [Strings] Strings can be easily stored in Modbus registers. For simplicity, some implementations require that string lengths be multiples of two, with any additional space filled with null values. Byte order is also a variable in string interactions. String format may or may not include a NULL as the final value.
- [Monomaster] The original Modbus assumes a monomaster network or point-to-point connection. In both cases, a master and at least one slave are required for communication.
- [Multimaster] Several masters can be present on the Modbus network at the same time, but in this case so-called we must include a multimaster gateway in the communication network, and the masters can only be connected over Modbus TCP.
Modbus object types and adresses
Object type | Access | Size | Original address space | Extended addressing* |
---|---|---|---|---|
Coil | Read-write | 1 bit | 00001 – 09999 | 000001-065535 |
Discrete input | Read-only | 1 bit | 10001 – 19999 | 100001-165535 |
Input register | Read-only | word (16 bits) | 30001 – 39999 | 300001-365535 |
Holding register | Read-write | word (16 bits) | 40001 – 49999 | 400001-465535 |
*: for example with Simatic
Modbus Function Codes
Modbus protocol defines several function codes for accessing Modbus registers. There are four different data blocks defined by Modbus, and the addresses or register numbers in each of those overlap. Therefore, a complete definition of where to find a piece of data requires both the address (or register number) and function code (or register type).
Most manufacturers only implement the “common” function codes, so you must always make sure which codes can be used for the given equipment.
Function Code | Register Type | frequency |
---|---|---|
1 | Read Coil | common |
2 | Read Discrete Input | common |
3 | Read Holding Registers | common |
4 | Read Input Registers | common |
5 | Write Single Coil | common |
6 | Write Single Holding Register | common |
15 | Write Multiple Coils | common |
16 | Write Multiple Holding Registers | rare |
21 | Write File record | rare |
22 | Mask Write Register | rare |
23 | Read/Write Multiple Registers | rare |
24 | Read FIFO queue | rare |
8 | Diagnostic | rare |
11 | Get Com event counter | rare |
12 | Get Com Event Log | rare |
17 | Report Slave ID | rare |
43 | Read device Identification | rare |
43 | CANopen General Reference | rare |
Exception codes
The exception codes as explained in the Modbus specification are:
Exception Code | Name | Meaning |
---|---|---|
01 (01 hex) | Illegal Function | The function code received in the query is not an allowable action for the slave. This may be because the function code is only applicable to newer devices, and was not implemented in the unit selected. It could also indicate that the slave is in the wrong state to process a request of this type, for example because it is unconfigured and is being asked to return register values. If a Poll Program Complete command was issued, this code indicates that no program function preceded it. |
02 (02 hex) | Illegal Data Address | The data address received in the query is not an allowable address for the slave. More specifically, the combination of reference number and transfer length is invalid. For a controller with 100 registers, a request with offset 96 and length 4 would succeed, a request with offset 96 and length 5 will generate exception 02. |
03 (03 hex) | Illegal Data Value | A value contained in the query data field is not an allowable value for the slave. This indicates a fault in the structure of remainder of a complex request, such as that the implied length is incorrect. It specifically does NOT mean that a data item submitted for storage in a register has a value outside the expectation of the application program, since the MODBUS protocol is unaware of the significance of any particular value of any particular register. |
04 (04 hex) | Slave Device Failure | An unrecoverable error occurred while the slave was attempting to perform the requested action. |
05 (05 hex) | Acknowledge | Specialized use in conjunction with programming commands. The slave has accepted the request and is processing it, but a long duration of time will be required to do so. This response is returned to prevent a timeout error from occurring in the master. The master can next issue a Poll Program Complete message to determine if processing is completed. |
06 (06 hex) | Slave Device Busy | Specialized use in conjunction with programming commands. The slave is engaged in processing a long-duration program command. The master should retransmit the message later when the slave is free.. |
07 (07 hex) | Negative Acknowledge | The slave cannot perform the program function received in the query. This code is returned for an unsuccessful programming request using function code 13 or 14 decimal. The master should request diagnostic or error information from the slave. |
08 (08 hex) | Memory Parity Error | Specialized use in conjunction with function codes 20 and 21 and reference type 6, to indicate that the extended file area failed to pass a consistency check. The slave attempted to read extended memory or record file, but detected a parity error in memory. The master can retry the request, but service may be required on the slave device. |
10 (0A hex) | Gateway Path Unavailable | Specialized use in conjunction with gateways, indicates that the gateway was unable to allocate an internal communication path from the input port to the output port for processing the request. Usually means the gateway is misconfigured or overloaded. |
11 (0B hex) | Gateway Target Device Failed to Respond | Specialized use in conjunction with gateways, indicates that no response was obtained from the target device. Usually means that the device is not present on the network. |
Sources
Modbus topics on lamaPLC
This page has been accessed for: Today: 1, Until now: 197