Introduction to modbus protocol

Introduction to MODBUSPROTOCOLSHIVAM SINGHPROJECT ENGINEER +91-8527199116 shivam.technisys@gmail.comOVERVIEW-ABBREVIATIONSADU: Application Data Unit IETF: Internet Engineering Task Force IP: Internet Protocol MAC: Medium Access Control MB: MODBUS MBAP: MODBUS Application Protocol PDU: Protocol Data Unit PLC: Programmable Logic Controller TCP: Transport Control Protocol BSD: Berkeley Software Distribution MSL: Maximum Segment Lifetime OVERVIEWMODBUS is an application layer messaging protocol, positioned at level 7 of the OSI model, which provides client/server communication between devices connected on different types of buses or networks.  The industry’s serial de facto standard since 1979, MODBUS continues to enable millions of automation devices to communicate. Today, support for the simple and elegant structure of MODBUS continues to grow. The Internet community can access MODBUS at a reserved system port 502 on the TCP/IP stack. MODBUS is a request/reply protocol and offers services specified by function codes. MODBUS function codes are elements of MODBUS request/reply PDUs. The objective of this document is to describe the function codes used within the framework of MODBUS transactions.MODBUS is an application layer messaging protocol for client/server communication between devices connected on different types of buses or networks. OVERVIEWIt is currently implemented using: TCP/IP over Ethernet. Asynchronous serial transmission over a variety of media (wire: EIA/TIA-232-E, EIA-422, EIA/TIA-485-A; fiber, radio, etc.) MODBUS PLUS, a high speed token passing network. Network Architecture of MODBUS-Every type of devices (PLC, HMI, Control Panel, Driver, Motion control, I/O Device) can use MODBUS protocol to initiate a remote operation.  The same communication can be done as well on serial line as on an Ethernet TCP/IP networks. Gateways allow a communication between several types of buses or network using the MODBUS protocol.Protocol Description-The MODBUS protocol defines a simple protocol data unit (PDU) independent of the underlying communication layers. The mapping of MODBUS protocol on specific buses or network can introduce some additional fields on the application data unit (ADU).Protocol DescriptionThe MODBUS application data unit is built by the client that initiates a MODBUS transaction. The function indicates to the server what kind of action to perform. The MODBUS application protocol establishes the format of a request initiated by a client.The function code field of a MODBUS data unit is coded in one byte. Valid codes are in the range of 1 ... 255 decimal (the range 128 – 255 is reserved and used for exception responses). When a message is sent from a Client to a Server device the function code field tells the server what kind of action to perform. Function code "0" is not valid. Sub-function codes are added to some function codes to define multiple actions. The data field of messages sent from a client to server devices contains additional information that the server uses to take the action defined by the function code. This can include items like discrete and register addresses, the quantity of items to be handled, and the count of actual data bytes in the field. Protocol DescriptionThe data field may be nonexistent (of zero length) in certain kinds of requests, in this case the server does not require any additional information. The function code alone specifies the action.If no error occurs related to the MODBUS function requested in a properly received MODBUS ADU the data field of a response from a server to a client contains the data requested. If an error related to the MODBUS function requested occurs, the field contains an exception code that the server application can use to determine the next action to be taken. For example a client can read the ON / OFF states of a group of discrete outputs or inputs or it can read/write the data contents of a group of registers. When the server responds to the client, it uses the function code field to indicate either a normal (error-free) response or that some kind of error occurred (called an exception response). For a normal response, the server simply echoes to the request the original function code.Protocol DescriptionFor an exception response, the server returns a code that is equivalent to the original function code from the request PDU with its most significant bit set to logic 1.Protocol DescriptionThe size of the MODBUS PDU is limited by the size constraint inherited from the first MODBUS implementation on Serial Line network (max. RS485 ADU = 256 bytes).  Therefore: MODBUS PDU for serial line communication = 256 - Server address (1 byte) - CRC (2 bytes) = 253 bytes. Consequently: RS232 / RS485 ADU = 253 bytes + Server address (1 byte) + CRC (2 bytes) = 256 bytes. TCP MODBUS ADU = 253 bytes + MBAP (7 bytes) = 260 bytes.MODBUS TCP/IP-A communicating system over MODBUS TCP/IP may include different types of device: A MODBUS TCP/IP Client and Server devices connected to a TCP/IP network The Interconnection devices like bridge, router or gateway for interconnection between the TCP/IP network and a serial line sub-network which permit connections of MODBUS Serial line Client and Server end devices. MODBUS Data Model-MODBUS bases its data model on a series of tables that have distinguishing characteristics. The four primary tables are:The distinctions between inputs and outputs, and between bit-addressable and word-addressable data items, do not imply any application behavior. It is perfectly acceptable, and very common, to regard all four tables as overlaying one another, if this is the most natural interpretation on the target machine in question. For each of the primary tables, the protocol allows individual selection of 65536 data items, and the operations of read or write of those items are designed to span multiple consecutive data items up to a data size limit which is dependent on the transaction function code.MODBUS Addressing Model-The MODBUS application protocol defines precisely PDU addressing rules. In a MODBUS PDU each data is addressed from 0 to 65535. It also defines clearly a MODBUS data model composed of 4 blocks that comprises several elements numbered from 1 to n. In the MODBUS data Model each element within a data block is numbered from 1 to n. Afterwards the MODBUS data model has to be bound to the device application (IEC-61131 object, or other application model). The pre-mapping between the MODBUS data model and the device application is totally vendor device specific.Modbus Component Architecture Model-Communication Application Layer - A MODBUS device may provide a client and/or a server MODBUS interface. A MODBUS backend interface can be provided allowing indirectly the access to user application objects. Four areas can compose this interface: input discrete, output discrete (coils), input registers and output registers. A pre-mapping between this interface and the user application data has to be done (local issue).MODBUS Client - The MODBUS Client allows the user application to explicitly control information exchange with a remote device. The MODBUS Client builds a MODBUS request from parameter contained in a demand sent by the user application to the MODBUS Client Interface. The MODBUS Client uses a MODBUS transaction whose management includes waiting for and processing of a MODBUS confirmation. MODBUS Client Interface - The MODBUS Client Interface provides an interface enabling the user application to build the requests for various MODBUS services including access to MODBUS application objects. The MODBUS Client interface (API) is not part of this Specification, although an example is described in the implementation model. Modbus Component Architecture Model.MODBUS Server - On reception of a MODBUS request this module activates a local action to read, to write or to achieve some other actions. The processing of these actions is done totally transparently for the application programmer. The main MODBUS server functions are to wait for a MODBUS request on 502 TCP port, to treat this request and then to build a MODBUS response depending on device context. Modbus Component Architecture Model.MODBUS Backend Interface - The MODBUS Backend Interface is an interface from the MODBUS Server to the user application in which the application objects are defined.Modbus Component Architecture Model.TCP Management Layer – Establishment, ending and to manage the data flow on established TCP connections. Connection Management - A communication between a client and server MODBUS Module requires the use of a TCP connection management module. It is in charge to manage globally messaging TCP connections. The listening TCP port 502 is reserved for MODBUS communications. Two possibilities are proposed for the connection management. Either the user application itself manages TCP connections or the connection management is totally done by this module and therefore it is transparent for the user application. The last solution implies less flexibility. It is mandatory to listen by default on that port. However, some markets or applications might require that another port is dedicated to MODBUS over TCP. For that reason, it is highly recommended that the clients and the servers give the possibility to the user to parameterize the MODBUS over TCP port number. It is important to note that even if another TCP server port is configured for MODBUS service in certain applications, TCP server port 502 must still be available in addition to any application specific ports.Modbus Component Architecture Model.Access Control Module - In certain critical contexts, accessibility to internal data of devices must be forbidden for undesirable hosts. That’s why a security mode is needed and security process may be implemented if required. TCP/IP Stack Layer - The TCP/IP stack can be parameterized in order to adapt the data flow control, the address management and the connection management to different constraints specific to a product or to a system. Generally the BSD socket interface is used to manage the TCP connections. Resource Management and Data Flow Control - In order to equilibrate inbound and outbound messaging data flow between the MODBUS client and the server, data flow control mechanism is provided in all layers of MODBUS messaging stack. The resource management and flow control module is first based on TCP internal flow control added with some data flow control in the data link layer and also in the user application level The Two Serial Transmission Modes-Controllers can be setup to communicate on standard Modbus networks using either of two transmission modes: ASCII or RTU. Users select the desired mode, along with the serial port communication parameters (baud rate, parity mode, etc.), during configuration of each controller. The mode and serial parameters must be the same for all devices on a Modbus network. The selection of ASCII or RTU mode pertains only to standard Modbus networks.It defines the bit contents of message fields transmitted serially on those networks. It determines how information will be packed into the message fields and decoded. On other networks like MAP and Modbus Plus, Modbus messages are placed into frames that are not related to serial transmission. For example, a request to read holding registers can be handled between two controllers on Modbus.The Two Serial Transmission Modes..ASCII Mode-When controllers are setup to communicate on a Modbus network using ASCII (American Standard Code for Information Interchange) mode, each 8–bit byte in a message is sent as two ASCII characters. The main advantage of this mode is that it allows time intervals of up to one second to occur between characters without causing an error.The format for each byte in ASCII mode is:Coding System: Hexadecimal, ASCII characters 0–9, A–F. One hexadecimal character contained in each ASCII character of the message.Bits per Byte: 1 start bit 7 data bits, least significant bit sent first 1 bit for even/odd parity; no bit for no parity 1 stops bit if parity is used; 2 bits if no parityError Check Field: Longitudinal Redundancy Check (LRC)The Two Serial Transmission Modes..RTU Mode-When controllers are setup to communicate on a Modbus network using RTU (Remote Terminal Unit) mode, each 8–bit byte in a message contains two 4–bit hexadecimal characters. The main advantage of this mode is that its greater character density allows better data throughput than ASCII for the same baud rate. Each message must be transmitted in a continuous stream. The format for each byte in RTU mode is:Coding System: 8–bit binary, hexadecimal 0–9, A–F. Two hexadecimal characters contained in each 8–bit field of the message.Bits per Byte: 1 start bit 8 data bits, least significant bit sent first 1 bit for even/odd parity; no bit for no parity 1 stops bit if parity is used; 2 bits if no parityError Check Field: Cyclical Redundancy Check (CRC)