MBLogic for an open world in automation
Modbus is the leading industrial open control protocol. This help page will discuss some of the basic concepts and correct some common misconceptions, but does not provide a detailed description of the protocol itself.
Modbus comes in several different types, depending upon the media over which it is transported.
MBLogic uses Modbus/TCP.
Like most communications protocols, Modbus uses a client/server type protocol. This is also sometimes referred to as master/slave. A "master" is the same thing as a "client", while a "slave" is the same thing as a "server". Typically, the client is the PLC or controller, while the server is a field device such as a valve bank or sensor block.
A Modbus message includes what is called the unit ID. A unit ID is a number between 0 and 255 which is used to identify the server (or slave) address in RS-232 or RS-485 networks. Each server (slave) is assigned a "slave ID" number and listens for messages which contain this number in the unit ID field.
Modbus/TCP also has the unit ID in its messages, but the Ethernet TCP/IP address is used to decide where to actually delivery the message. Many or most server devices will ignore the unit ID. However, some will use the unit ID to decide whether to forward the message out a built-in serial port. This message forwarding allows older RS-485 devices to be used on newer Ethernet networks. However, support for this feature is only found in a few devices.
When a Modbus message sends a request, it includes a message ID number. This is a number from 0 to 65,535. This number is normally incremented by the client for each request (and allowed to roll over to 0 again when it overflows). This message ID is echoed back by the server. The client can use this message ID number to determine if any messages are being lost or delayed in transmission.
When used over RS-232 or RS-585 networks, the usual serial communications parameters such as baud rate, parity, stop bits, etc. must be set correctly for all devices. Setting of these parameters is not dicussed here. Consult your vendor documentation for details.
Modbus/TCP uses TCP/IP communicate over Ethernet. The "standard" port number for Modbus/TCP is port 502. However, it is possible to run Modbus/TCP on alternate port numbers provided that all devices that are participating in the communications can be configured to use the alternate port.
Modbus uses the concept of a data table to refer to data. Data tables should be familiar to anyone who has used a PLC. A data table is an array or block of memory used to store data. Data is referenced using data table addresses. Modbus data table addresses come in four types.
In addition to the native data types of boolean and integer, it is possible to store large integers, floating point numbers, and strings in a Modbus data table by splitting the data over several registers. However, Modbus does not offer any direct support for this, so the user is responsible for splitting the values up and storing them in separate locations.
Modbus data table addresses are simply integer numbers. Each address type (discrete input, coil, input register, holding register) has its own numbered set of addresses. For example, discrete input 42 and coil 42 are two separate addresses.
Modbus distinguishes between the protocol address and the data model address. The addresses that are used in the protocol are numbered from 0 to 65,535. However, vendor documentation may number from 1 to 65,536. This documentation will refer to the protocol addresses (that is the first address is 0).
Although it is possible to have 65,536 addresses of each type the number of addresses actually implemented in a particular device (sensor block, valve bank, PLC, etc.) is usually much less that this. Each device designer is responsible for deciding what makes sense for their application. They will then normally supply a "memory map" or list of addresses for their device listing what addresses were implemented, and what each one does.
It is also possible to "overlay" address types. That is, it is possible to design a device such that several different address types all refer to the same physical memory location. For example, it is possible to have holding register 10 and input register 10 both be the same memory location. In this case if you were to write to holding register 10, the value would also appear in input register 10. The same applies to coils and discrete inputs.
In the same way, it is possible to pack coils and discrete inputs in registers. For example, coils 0 to 15 could be packed in holding register 0, coils 16 to 31 in holding register 1, etc. This would allow multiple coils to be read (or written to) as words.
Although overlay of data types and packing of coils into registers is possible, it is not often found in practice.
According to the Modbus standard, addresses are simply integers from 0 to 65,535 with the different address ranges being referred to as coils, holding registers, etc. However, some vendors will document their hardware using numerical prefixes which are not actually part of the Modbus address. This originated from some models of PLCs which used the Modbus communications protocol, and which also used numerical prefixes in their internal data table. This is similar to using "I", "Q", "V", etc. as address prefixes in IEC type PLCs.
However, it is important to remember that these numerical prefixes are documentation methods and are not part of what the Modbus protocol itself sends as part of the messages. A difference in documentation methods does not affect the compatibility of the protocol itself.
These prefixes are they mentioned anywhere in the Modbus standard, but the following shows how they are typically used in documentation based on this older convention:
Note that there is no 2xxxx address prefix.
In addition to numerical prefixes, some documentation will refer to protocol addresses (addresses start at 0), while other documentation will refer to data model addresses (addresses start at 1). That is, the first holding register may be 0 or 1 (or 40000 versus 40001 using prefixes). However, this has no bearing on what gets sent over the wire as a Modbus message. For a Modbus protocol message, the lowest address is always "0", not "1".
This document uses standard Modbus terms and addresses throughout using Modbus protocol addressing without prefixes or offsets. However, if you are reading the documentation for sensor blocks, valves, and other devices, you must keep in mind that some vendors may document their hardware in different ways.
Modbus commands are known as functions. A function is simply a command to read or write a data table address. Functions are numbers such as 1, 2, 3, 4, etc. For example, function "1" will read one or more coils. Function "15" will write to one or more coils. All function codes are defined as part of the Modbus standard, but which functions were actually implemented in any particular device is up to the device designer. For example, a valve bank may only implement functions for writing coils because that is all that was necessary for that device.
The most common functions are listed below. There are many other functions defined in the Modbus standard, but these are the ones most commonly encountered.
Modbus functions which read or write multiple addresses will also require a quantity parameter. The "quantity" parameter specifies the number of consecutive addresses to read or write.
The modbus protocol specifies the maximum number of addresses which can be read or written at one time. This limits the amount of data which must be transferred in a single command to no more than 255 bytes. For a read command, the limit is 2000 coils or discrete inputs or 125 registers. For a write command, the limit is 1968 coils or 123 registers.
When a Modbus message is received by a server it is analysed to see of all the parameters are correct. If everything is OK, the server will send a response. This response may consist of data, or it may just be an acknowledgement that the message was received.
If there are any error however, the server may do one of two things. If the message could not be decoded at all (e.g. there was a bad check sum), the message is simply discarded. If the message could be decoded but one or more parameters was incorrect (e.g. an attempt was made to read a non-existent address), then the server will send a response containing a fault code. The fault code is simply the function code from the request with 128 added to it.
For example, if the client sends a request with function 3 (read holding registers) that contains an error, the server will respond with a fault code of 131 (3 + 128 = 131).
In addition to the fault code, the server will return an exception code which provides more detail about what was wrong. Exception codes are defined individually for each function, but for most common functions the following will apply: