Modbus

Modbus is a fieldbus, an industrial computer networking protocol. It was originally designed for use with programmable logic controllers (PLCs), but has become a de facto standard communication protocol for communication between industrial electronic devices in a wide range of buses and networks. 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 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.…

Modbus is a fieldbus, an industrial computer networking protocol. It was originally designed for use with programmable logic controllers (PLCs), but has become a de facto standard communication protocol for communication between industrial electronic devices in a wide range of buses and networks. 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 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. It was originally published in 1979¹ by Modicon (bought by Schneider Electric in 1997). In 2004, they transferred the rights to the Modbus Organization which is a trade association of users and suppliers of Modbus-compliant devices that advocates for the continued use of the technology. ==Protocol description== Modbus standards or buses include: TCP/IP over Ethernet Asynchronous serial communication in a wide range of standards, technologies: EIA/TIA-232-E, EIA-422, EIA/TIA-485-A, fiber, radio frequency,... MODBUS PLUS, a high speed token passing network. To support Modbus communication on a network, many modems and gateways incorporate proprietary designs (refer to the diagram: Architecture of a network for Modbus communication). Implementations may deploy either wireline or wireless communication, such as in the ISM radio band, and even Short Message Service (SMS) or General Packet Radio Service (GPRS). PDU = Function code + data ADU = Additional address + PDU + error check The ADU is officially called a Modbus frame by the Modbus Organization, although frame is used as the data unit in the data-link layer in the OSI and TCP/IP model (while Modbus is an application layer protocol). PDU max size is 253 bytes. ADU max size on RS232/RS485 network is 256 bytes, and with TCP is 260 bytes. For data encoding, Modbus uses a big-endian representation for addresses and data fields. Thus, for a 16-bit value, the most significant byte is sent first. For example, when a 16-bit register has value 0x1234, byte 0x12 is sent before byte 0x34. Function code is 1 byte which gives the code of the function to execute. Function codes are integer values, ranging from 1 to 255, and the range from 128 to 255 is for exception responses. The data field of the PDU has the address from 0 to 65535 (not to be confused with the address of the Additional address field of ADU). The data field of the PDU can be empty, and then has a size of 0. In this case, the server will not request any information and the function code defines the function to be executed. If there is no error during the execution process, the data field of the ADU response from server to client will include the data requested, i.e. the data the client previously received. If there is any error, the server will respond with an exception code. Step 1: Client initiates a request with PDU = Function code + data request Step 2: Server receives the request from client. Server will then read/parse the function code, get the address of the data field of the PDU, then get this data field value and finally perform the action based on the function code. If there is no error during those steps, the server will respond with PDU = Function code + data response. As long as there is no error during those steps, the server's responding function code will also be the function code sent from the client. If there is any error during those steps, the server will respond with PDU = Exception Function code + Exception code (Reference to PDU mb_excep_rsp_pdu defined below). Step 3: Client receives the response and ends the transaction. Based on that, Modbus defines 3 PDU types: MODBUS Request PDU, mb_req_pdu MODBUS Response PDU, mb_rsp_pdu MODBUS Exception Response PDU, mb_excep_rsp_pdu mb_req_pdu = Function code (1 byte) + request data (n bytes) request data field's size depends on the function code and usually includes values like variable values, data offset, and sub-function codes. mb_rsp_pdu = Function code (1 byte) + response data (n bytes) As in mb_req_pdu, response data field's size depends on the function code and usually includes values like variable values, data offset, and sub-function codes. mb_excep_rsp_pdu = Exception Function code (1 byte) + exception code (1 byte) Exception Function code = Function code (1 byte) + 0x80. Exception Function code is equal to the Function code, except that its MSB is set to 1. Exception code (1 byte) of mb_excep_rsp_pdu is defined in the MODBUS Exception Codes table. Byte count: 1 byte (n=quantity of coils/8, rounded up) Coil Status: n bytes For instance, mb_req_pdu and mb_rsp_pdu to read coils status from 20-38 will be: mb_req_pdu: Function code: 0x01 Starting Address High byte: 0x00 Starting Address Low byte: 0x13 Quantity of Outputs High byte: 0x00 Quantity of Outputs Low byte: 0x13 Starting Address (2 bytes) is 0x0013, (or 19 in decimal) which is the 20th coil. Quantity of Outputs (2 bytes) is 0x0013, (or 19 in decimal) which corresponds to 19 values of status of coils 20th to 38th. mb_rsp_pdu: Function code: 0x01 Byte Count: 0x03 Outputs status 27-20: 0xCD Outputs status 35-28: 0x6B Outputs status 38-36: 0x05 As 19 coils (20-38) are required, 3 bytes is used to indicate the coil's state. So that Byte Count is 0x03. States of coil from 20 to 27 is 0xCD, which is 1100 1101 in binary. So coil 27 is MSb, and coil 20 is LSb. Same for coil 28 to 35. With coil from 36 to 38, the state will be 0x05, which is 0000 0101. Coil 38 state is the 3rd bit (count from the right), i.e 1, coil 37 is 0, and coil 36 state is LSb bit, i.e. 1. 5 left bits are all 0. ==Exception responses== When a client sends a request to a server, there can be four possible events for that request: If server receives the request and execute successfully, server will return a normal response. If server cannot receive the request as having communication channel error, server will not respond anything to the client. Client will then have the timeout request error. If server receives the request and detect an error on the communication channel (e.g parity, LRC, CRC), server will not response anything to the client. Client will then have the timeout request error. If server receives the request and is unable to execute it (e.g client requests to read a non-existent register), server will return an exception response to client to indicate the nature of the error. Exception response message includes two other fields when compared to a normal response message: Function Code: Function code's MSB bit of Exception is 1. This will make this function code 0x80 higher than then request message function code. Data: Server returns the exception code inside the Data field. This field defines the nature of the error. All Modbus exception code: Modbus Serial Line PDU = Address + PDU + CRC (or LRC) With PDU = Function code + data Address is slave address PDU is defined identically to the PDU of Modbus Application protocol The Error check field with CRC/LRC: The error check methods depend on the protocol versions of the MODBUS over Serial Line, whether it is Modbus RTU or Modbus ASCII. On the physical layer, MODBUS over Serial Line performs its communication on bit by RS485 or RS232, with TIA/EIA-485 Two-Wire interface as the most popular way. RS485 Four-Wire interface is also used. TIA/EIA-232-E (RS232) can also be used but is limited to point-to-point short-range communication. MODBUS over Serial Line has two transmission modes RTU and ASCII which are corresponded to two versions of the protocol, known as Modbus RTU and Modbus ASCII. t3.5 = 3.5 \cdot \left( \frac{11 \cdot 1000}{19200} \right)= 2.005 \, \mathrm{ms} t1.5 = 1.5 \cdot \left( \frac{11 \cdot 10^6}{19200} \right)= 859.375 \, \mathrm{\mu s} For higher data rates, Modbus RTU recommends to use the fixed values 750 μs for t1.5 and 1.750 ms for t3.5. LRC is calculated as the sum of 8-bit values (excluding the start and end characters), negated (two's complement) and encoded as an 8-bit value. For example, if Address, Function, and Data are 247, 3, 19, 137, 0, and 10, the two's complement of their sum (416) is −416; this trimmed to 8 bits is 96 (256 × 2 − 416 = 60 16 ), giving the following 17 ASCII character frame: :F7031389000A60␍␊ . LRC is specified for use only as a checksum: because it is calculated on the encoded data rather than the transmitted characters, its 'longitudinal' characteristic is not available for use with parity bits to locate single-bit errors. MODBUS TCP/IP ADU = MODBUS Application Protocol Header + Function code + Data MODBUS Application Protocol header - is the dedicated header used on TCP/IP to identify the MODBUS Application Data Unit. The MODBUS Application Protocol Header contains the following fields: Unit identifier is used with Modbus TCP devices that are composites of several Modbus devices, e.g. Modbus TCP to Modbus RTU gateways. In such a case, the unit identifier is the Server Address of the device behind the gateway. A MODBUS TCP/IP ADU/Modbus TCP frame format then will be: ====Example of a Modbus TCP/IP ADU/Modbus TCP frame in hexadecimal==== 12 34 00 00 00 06 01 03 00 01 00 01 0x12 and 0x34 : With transaction ID = 0x1234 (2 bytes) as a "unique number" to be identified between the Modbus TCP client/server, the transaction ID High byte is 0x12 and transaction ID Low byte is 0x34 0x00 and 0x00 : Protocol identifier high byte and low byte 0x00 and 0x06 : Length high byte and low byte. The length is 6 bytes which includes: unit identifier (slave address) (1 byte), function code (1 byte), high byte of the register address to read (1 byte), low byte of the register address to read (1 byte) and data (2 bytes = high byte and low byte of the number of registers to read) 0x01 : Unit identifier (slave address) 0x03 : Function code (Read Multiple Holding Registers) 0x00 and 0x01 : high byte and low byte of the register address to read. The register address to read in this case is 0x0001 . 0x00 and 0x01 : high byte and low byte of the number of registers to read. The number of registers to read in this case is 0x0001 . (i.e 1 register) ==Other Modbus protocol versions== Besides the widely used Modbus RTU, Modbus ASCII and Modbus TCP, there are many variants of Modbus protocols: Modbus Plus (Modbus+, MB+, or MBP) – Modbus Plus is proprietary to Schneider Electric, though it is unpublished rather than patented, and unlike the other variants, it supports peer-to-peer communications between multiple clients. Despite the name, Modbus Plus is not a variant of Modbus. It is a different protocol, involving token passing. It requires a dedicated co-processor to handle fast HDLC-like token rotation. It uses twisted pair at 1 Mbit/s and includes transformer isolation at each node, which makes it transition/edge-triggered instead of voltage/level-triggered. Special hardware is required to connect Modbus Plus to a computer, typically a card made for the ISA, PCI, or PCMCIA bus. Modbus Plus is normally implemented using a custom chipset available only to partners of Schneider. Pemex Modbus – an extension of standard Modbus with support for historical and flow data. It was designed for the Pemex oil and gas company for use in process control and never gained widespread adoption. Enron Modbus – another extension of standard Modbus developed by Enron with support for 32-bit integer and floating-point variables, and historical and flow data. Data types are mapped using standard addresses. The historical data serves to meet an American Petroleum Institute (API) industry standard for how data should be stored. Data models and function calls are identical for the first four variants listed above; only the encapsulation is different. However the variants are not interoperable, nor are the frame formats. ===JBUS mapping=== Another de facto protocol closely related to Modbus appeared later, and was defined by PLC maker April Automates, the result of a collaborative effort between French companies Renault Automation and Merlin Gerin et Cie in 1985: JBUS. Differences between Modbus and JBUS at that time (number of entities, server stations) are now irrelevant as this protocol almost disappeared with the April PLC series, which AEG Schneider Automation bought in 1994 and then made obsolete. However, the name JBUS has survived to some extent. JBUS supports function codes 1, 2, 3, 4, 5, 6, 15, and 16 and thus all the entities described above, although numbering is different: Number and address coincide: entity #x has address x in the data frame. Consequently, entity number does not include the entity type. For example, holding register #40010 in Modbus will be holding register #9, at address 9 in JBUS. Number 0 (and thus address 0) is not supported. The server should not implement any real data at this number and address, and it can return a null value or throw an error when requested. ==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. ==See also== BACnet CAN bus LonWorks Industrial ethernet ==References== ==External links== ===Official=== Modbus organization ===Other=== Modbus for Field Technicians at modbusbacnet.com Modbus tutorial at RF Wireless World

Text derived from https://en.wikipedia.org/w/index.php?oldid=1352474681 under CC BY-SA 4.0; modifications have been made.