Modbus is one of the very commonly used protocols in the industrial communicating devices where a gateway sends a command to the Modbus device to fetch the values of the device.
Out of all the devices on Modbus network there usually is only one master which sends different commands to other slave devices. The Modbus master broadcasts a message to all the devices on the network but only the device whose Modbus address is assigned to take the command will accept the command and remaining devices will the reject it. The basic Modbus commands can instruct an RTU to change a value in one of its registers, control or read an I/O port, as well as commanding the device to send back one or more values contained in its registers.

The main reasons for the use of Modbus in the industrial environment are:

•  It has been developed with industrial applications in mind
•  It is openly published and royalty-free
•  It is easy to deploy and maintain
•  It moves raw bits or words without placing many restrictions on vendors
•  Ease of availability of SCADA systems on the Modbus protocols

There are different flavours of Modbus Protocol:

•  Modbus TCP
•  Modbus RTU
•  Modbus ASCII
•  Modbus Plus
•  Modbus Daniels
•  Modbus Tek-Air
•  Modbus Omniflow

The most popular of these are Modbus RTU and Modbus TCP/IP.

ModbusRTU is a serial communication protocol that connects different devices on the same network and would make the communication between them possible.

ModbusTCP covers the use of Modbus communication via an 'Intranet' or 'Internet' environment using the TCP/IP protocols. The most common use of the protocols at this time is for Ethernet attachment of PLC's, I/O modules, and Gateways to other simple field buses or I/O networks. 
There will always be this question why the connection-oriented TCP/IP protocol is used rather than the datagram-oriented UDP. The Primary reason is to keep control of an individual ‘communication’ by isolating it in a connection which can be identified, cancelled , and supervised without the need of specific action on the client and server applications. This gives the mechanism a tolerance to network performance changes, and also gives a scope to add security features such as firewalls and proxies. 
MODBUS/TCP/IP handles two different situations. A connection can be recognized too easily at the protocol level. A single connection can be used to carry out multiple independent communications. To add to it, TCP/IP allows a huge number of concurrent connections, so the user decides to re-use an old connection or reconnect to a frequently used connection.

MODBUS has a unique addressing pattern. A Modbus device will store every value in it at a particular address. For example an EATON power meter will store a value of Volt A-N only at Modbus address 40001.  

There four Modbus DATA Type:

Types  of Modbus Data Type	Data format and common name	Address where they begin
Modbus Coils	Bits, Binary values	00001	This type of data can be provided by an I/O system.
Digital Inputs	Binary values	10001	This type data can be changed by an application layer.
Analog Inputs	Binary values	30001	This type of data can be provided by an I/O system.
Modbus Registers/ Holding registers	Analog values	40001	This type data can be changed by an application layer.

• Modbus is transmitted over serial lines between devices. The simplest setup would be a single serial cable connecting the serial ports on two devices, a Master and a Slave.
• The data is sent as series of ones and zeroes called bits. Each bit is sent as a voltage. Zeroes are sent as positive voltages and ones as negative. The bits are sent very quickly. A typical transmission speed is 9600 baud (bits per second).

The Modbus device can be connected using an Ethernet port on the gateway. We can make a query using any standard Modbus Scanner to extract the value from a Modbus device. All requests are sent via TCP/IP on registered port 502.

Modbus protocol defines a Protocol Data Unit (PDU) that is independent of the underlying communication layers. Modbus RTU is the most commonly used, and is a binary representation of the PDU with addressing before the PDU, a CRC appended to the end.  Modbus ASCII is a representation of the same PDU using all printable characters (and generally twice as many bytes). Modbus TCP is essentially the exact same PDU as Modbus RTU, except the CRC is left off of the application layer byte string and left up to the TCP layer to deal with automatically. There are also some additional addressing bytes in the TCP encapsulation of the RTU packet.

The function codes, register numbering and addressing are identical regardless of protocol variant. Register types are the same, i.e., the same data blocks are defined for the Modbus device.

•   Information in the slave device is stored in four different tables.
•   Each table has 9999 data points which can store different values.   

Each coil has 1 bit and given a data address between x0000 and x9999.
Each register is 1 word = 16 bits = 2 bytes and also has data address between x0000and x9999.

The numbers 40001, 10000, etc should be taken as the address of the location. These numbers are never displayed in actual messages. The actual address would be the offset at which the number is stored. So if the device has ADU (Application Defined Units) addressing for Modbus the address 0001 would be at offset 40001 and for PDU (Protocol Defined Units) it would at offset 40002.

Each device in a network has to be assigned a unique unit address which can be between 1 and 255. When the master requests for data, the first byte it sends is the Device/Slave address. So only after the first byte is sent the slave decides to response or ignore.

A Modbus map is a simple list of points for any particular   device which supports Modbus as a communication protocol.

The Modbus map should have the following information:

1.   What kind of Data the device reads and stores (e.g. Temperature or pressure))
2.   At what address the data is stored (e.g. Voltage A-N at 40001) 
3.   What is the format in which the data is stored (e.g. Bits, UINT16, SINT16, etc)
4.   Engineering units of the points if required.
5.   Information on the whether the device has ADU or PDU addressing.

 Most devices have pre-installed Modbus registers in them. Also in some cases the manufacturer allows the operator to configure the device as per their requirement.

MODBUS networks employ two methods of error checking:  parity checking 

1.   Parity checking of the data character frame (even, odd, or no parity)
2.   Frame checking within the message frame (Cyclical Redundancy Check in RTU Mode, or Longitudinal Redundancy Check in ASCII Mode).  

Parity Checking 

A MODBUS device can be configured for even or odd parity, or for no parity checking.  This determines how the parity bit of the character's data frame is set.  If even or odd parity checking is selected, the number of 1 bit in the data portion of each character frame is counted.  Each character in RTU mode contains 8 bits.  The parity bit will then be set to a 0 or a 1, to result in an even (even parity), or odd (odd parity) total number of 1 bits.  

Frame checking  

LRC Longitudinal Redundancy Check (ASCII Mode Only) In the ASCII transmission mode, the character frame includes an LRC field as the last field preceding the CRLF characters.  This field contains two ASCII characters that represent the result of a longitudinal redundancy calculation for all the fields except the starting colon character and ending CR LF pair of characters.  

CRC Error Checking (RTU Mode Only)  

RTU Mode message frames include an error checking method that is based on a Cyclical Redundancy Check (CRC).  The error-checking field of a message frame contains a 16-bit value (two 8-bit bytes) that contains the result of a Cyclical Redundancy Check (CRC) calculation performed on the message contents. 

Function codes Defined by Modbus:

The second byte sent by the Master is the Function code. This number tells the slave which table to access and whether to read from or write to the table.

 

Function Code	Action	Table Name
01 (01 hex)	Read	Discrete Output Coils
05 (05 hex)	Write single	Discrete Output Coil
15 (0F hex)	Write multiple	Discrete Output Coils
02 (02 hex)	Read	Discrete Input Contacts
04 (04 hex)	Read	Analog Input Registers
03 (03 hex)	Read	Analog Output Holding Registers
06 (06 hex)	Write single	Analog Output Holding Register
16 (10 hex)	Write multiple	Analog Output Holding Registers

 

Modbus Exception Codes

 

Code	Name	Meaning
01	ILLEGAL FUNCTION	The function code received in the query is not an allowable action                        for the server (or 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 server (or 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.
02	ILLEGAL DATA ADDRESS	The data address received in the query is not an allowable address for the server (or slave). More specifically, the combination of reference number and transfer length is invalid. For a controller with 100 registers, the PDU addresses the first register as 0, and the last one as 99. If a request is submitted with a starting register address of 96 and a quantity of registers of 4, then this request will successfully operate (address-wise at least) on registers 96, 97, 98, 99. If a request is submitted with a starting register address of 96 and a quantity of registers of 5, then this request will fail with Exception Code 0x02 “Illegal Data Address” since it attempts to operate on registers 96, 97, 98, 99 and 100, and there is no register with address 100.
03	ILLEGAL DATA VALUE	A value contained in the query data field is not an allowable value for server (or slave). This indicates a fault in the structure of the 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	SLAVE DEVICE FAILURE	An unrecoverable error occurred while the server (or slave) was attempting to perform the requested action.
05	ACKNOWLEDGE	Specialized use in conjunction with programming commands. The server (or 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 client (or master). The client (or master) can next issue a Poll Program Complete message to determine if processing is completed.
06	SLAVE DEVICE BUSY	Specialized use in conjunction with programming commands. The server (or slave) is engaged in processing a long–duration program command. The client (or master) should retransmit the message later when the server (or slave) is free.
08	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 server (or slave) attempted to read record file, but detected a parity error in the memory. The client (or master) can retry the request, but service may be required on the server (or slave) device.
0A	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 that the gateway is not configured correctly or overloaded.
0B	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.