- Frame format
- Modbus RTU
- Modbus ASCII
- Modbus TCP
- Devices / Masters
- Devices / Slaves
- PBX systems
- Port assignments
- Upload Arduino code
Ozeki brings you outstanding
SMS Gateway technology. Use our SMS Server products on Windows,Linux, or Android
C# SMS API
Developers can use our C# SMS API to send SMS from C#.Net. The C# SMS API comes with full source code
PHP SMS API
The ozeki PHP SMS gateway software can be used to send SMS from PHP and to receive SMS usig PHP on your website
SMPP SMS Gateway
SMS service providers use our SMPP gateway solution, that offers a high performance SMPP server and SMPP client gateway with amazing routing capabilities
When controllers are setup to communicate on a Modbus network using RTU mode, each 8 bit 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 mode for the same baud rate. Each message must be transmitted in a continuous stream.
MODBUS frame description
The MODBUS application protocol defines a simple Protocol Data Unit (PDU) independent of the underlying communication layers.
The mapping of MODBUS protocol on a specific bus or network introduces some additional fields on the Protocol Data Unit. The client that initiates a MODBUS transaction builds the MODBUS PDU, and then adds fields in order to build the appropriate communication PDU.
The valid slave nodes addresses are in the range of 0 – 247 decimal. The individual slave devices are assigned addresses in the range of 1 – 247. A master addresses a slave by placing the slave address in the address field of the message. When the slave returns its response, it places its own address in the response address field to let the master know which slave is responding. On MODBUS Serial Line, the Address field only contains the slave address.
The function code indicates to the server what kind of action to perform. The function code can be followed by a data field that contains request and response parameters.
Error checking field is the result of a Redundancy Checking calculation that is performed on the message contents. Two kinds of calculation methods are used depending on the transmission mode that is being used (RTU or ASCII).
The format (11 bits) for each byte in RTU mode
|Coding System:||8–bit binary, hexadecimal 0–9, A–FTwo 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 stop bit if parity is used, 2 bits if no parity|
Even parity is required, other modes (odd parity, no parity) may also be used. In order to ensure a maximum compatibility with other products, it is recommended to support also No parity mode. The default parity mode must be even parity.
How characters are transmitted serially
When messages are transmitted on standard Modbus serial networks, each character or byte is sent in this order (left to right): Least Significant Bit (LSB) . . . Most Significant Bit (MSB)
Devices may accept by configuration either Even, Odd, or No Parity checking. If No Parity is implemented, an additional stop bit is transmitted to fill out the character frame to a full 11-bit asynchronous character.
Frame RTU description
The maximum size of a MODBUS RTU frame is 256 bytes.
MODBUS message RTU framing
A MODBUS message is placed by the transmitting device into a frame that has a known beginning and ending point. This allows devices that receive a new frame to begin at the start of the message, and to know when the message is completed. Partial messages must be detected and errors must be set as a result. In RTU mode, message frames are separated by a silent interval of at least 3.5 character times. In the following sections, this time interval is called t3,5.
The entire message frame must be transmitted as a continuous stream of characters. If a silent interval of more than 1.5 character times occurs between two characters, the message frame is declared incomplete and should be discarded by the receiver.
Modbus states that a baud rate higher than 19200 must use a fixed 750 us for inter character time out and 1.75 ms for a frame delay. For baud rates below 19200 the timeing is more critical and has to be calculated. For example 9600 baud in a 10 bit packet is 960 characters per second In milliseconds this will be 960characters per 1000ms. So for 1 character 1000ms/960characters is 1.04167ms per character and finaly modbus states an intercharacter must be 1.5T or 1.5 times longer than a normal character and thus 1.5T = 1.04167ms * 1.5 = 1.5625ms. A frame delay is 3.5T.
The following drawing provides a description of the RTU transmission mode state diagram. Both "master" and "slave" points of view are expressed in the same drawing.
Some explanations about the above state diagram:
- Transition from 'Initial State' to 'Idle' state needs t3.5 time-out expiration: that insures inter-frame delay
- 'Idle' state is the normal state when neither emission nor reception is active.
- In RTU mode, the communication link is declared in 'idle' state when there is no transmission activity after a time interval equal to at least 3,5 characters.
- When the link is in idle state, each transmitted character detected on the link is identified as the start of a frame. The link goes to the 'active' state. Then, the end of frame is identified when no more character is transmitted on the link after the time interval t3,5.
- After detection of the end of frame, the CRC-16 calculation and checking is completed. Afterwards the address field is analysed to determine if the frame is for the device. If not the frame is discarded. In order to reduce the reception processing time the address field can be analysed as soon as it is received without waiting the end of frame. In this case the CRC will be calculated and checked only if the frame is addressed to the slave (broadcast frame included).
Users may configure devices for Even (required) or Odd Parity checking, or for No Parity checking (recommended). This will determine how the parity bit will be set in each character. If either Even or Odd Parity is specified, the quantity of 1 bits will be counted in the data portion of each character (7 data bits for ASCII mode, or 8 for RTU). The parity bit will then be set to a 0 or 1 to result in an Even or Odd total of 1 bits. For example, these 8 data bits are contained in an RTU character frame: 1010 1001 The total quantity of 1 bits in the frame is four. If Even Parity is used, the frame’s parity bit will be a 0, making the total quantity of 1 bits still an even number (four).If Odd Parity is used, the parity bit will be a 1, making an odd quantity (five). When the message is transmitted, the parity bit is calculated and applied to the frame of each character. The device that receives counts the quantity of 1 bits and sets an error if they are not the same as configured for that device (all devices on the MODBUS Serial Line must be configured to use the same parity checking method). Note that parity checking can only detect an error if an odd number of bits are picked up or dropped in a character frame during transmission. For example, if Odd Parity checking is employed, and two 1 bits are dropped from a character containing three 1 bits, the result is still an odd count of 1 bits. If No Parity checking is specified, no parity bit is transmitted and no parity checking can be made. An additional stop bit is transmitted to fill out the character frame.
Frame checking field: 16 bit Cyclical Redundancy Checking (CRC-16)
RTU mode includes an error–checking field which is based on a Cyclical Redundancy Checking (CRC-16) method performed on the message contents. The CRC field checks the contents of the entire message. It is applied regardless of any parity checking method used for the individual characters of the message. The CRC field contains a 16–bit value implemented as two 8–bit bytes. The CRC field is appended to the message as the last field in the message. When this is done, the low–order byte of the field is appended first, followed by the high–order byte. The CRC high–order byte is the last byte to be sent in the message. The CRC value is calculated by the sending device, which appends the CRC to the message. The receiving device recalculates a CRC during receipt of the message, and compares the calculated value to the actual value it received in the CRC field. If the two values are not equal, an error results. The CRC calculation is started by first pre-loading a 16–bit register to all 1’s. Then a process begins of applying successive 8–bit bytes of the message to the current contents of the register. Only the eight bits of data in each character are used for generating the CRC. Start and stop bits and the parity bit, do not apply to the CRC. During generation of the CRC, each 8–bit character is exclusive ORed with the register contents. Then the result is shifted in the direction of the least significant bit (LSB), with a zero filled into the most significant bit (MSB) position. The LSB is extracted and examined. If the LSB was a 1, the register is then exclusive ORed with a preset, fixed value. If the LSB was a 0, no exclusive OR takes place. This process is repeated until eight shifts have been performed. After the last (eight) shift, the next 8–bit byte is exclusive ORed with the register’s current value, and the process repeats for eight more shifts as described above. The final content of the register, after all the bytes of the message have been applied, is the CRC value. When the CRC is appended to the message, the low-order byte is appended first, followed by the high-order byte.
Error checking methods
The security of standard MODBUS serial line is based on two kinds of error checking:
- Parity checking (even or odd) should be applied to each character.
- Frame checking (LRC for ASCII frames or CRC for RTU frames) must be applied to the entire message.
Both the character checking and message frame checking are generated in the device (master or slave) that emits and applied to the message contents before transmission. The device (slave or master) checks each character and the entire message frame during receipt.
The master is configured by the user to wait for a predetermined timeout interval ( Response time-out) before aborting the transaction. This interval is set to be long enough for any slave to respond normally ( unicast request). If the slave detects a transmission error, the message will not be acted upon. The slave will not construct a response to the master. Thus the timeout will expire and allow the master’s program to handle the error. Note that a message addressed to a nonexistent slave device will also cause a timeout.
Example Modbus RTU frame
Here is an example of a Modbus RTU request for the content of analog output holding registers #40108 to #40110 from the slave device with address 21. 15 03 00 6B 00 03 77 03 15: The SlaveID address (21 = 0x15) 03: The function code (read analog output holding registers) 006B: The data address of the first register requested (40108 - 40001 offset = 107 = 0x6B). 0003: The total number of registers requested. (read 3 registers 40108 to 40110) 7703: The CRC (cyclic redundancy check) for error checking.
Contents retrieved from