| Real Time Automation | 1-800-249-1612 |  |
Contact Us | |
Support |
 |
 |
 |
 |
 |
| 1. OVERVIEW Modbus is the most widely used protocol encompasses a series of open standard protocols. Modbus was first developed by Modicon back in 1979 as a way to communicate with their PLCs. Since that time it has become a leading standard in both Building and Industrial Automation markets. We will get into why it is so popular in just a minute but let’s first cover the different “flavors” of Modbus. Modbus comes in a number of “flavors” Modbus RTU and Modbus TCP/IP are the two that garner most attention. These and the other iterations are as follows: MModbus RTU - Is an open source Master/Slave protocol based on the serial RS-232, RS422 or RS-485physical layer, primarily RS-485. It provided the backbone technology and data structure of most subsequent versions. This is the most widely used and adopted protocol in automation. The Data is set up as Registers and Coils. More Detail on Modbus RTU Modus TCP/IP – Is essentially (for basic understanding) Modbus RTU on Ethernet TCP/IP with a 6 byte header to allow routing. There are a few other differences beyond the physical layer but the base technology and data representation is the same. More Detail on Modbus TCP/IP Modbus ASCII - Is used in serial communication & makes use of ASCII characters for protocol communication. This version never gained wide spread adoption. Modbus+ - Is a proprietary version of Modbus controlled by Schneider Electric. Modbus PEMEX - Is an extension of Modbus that allows for the support of historic and flow data. It was designed for the process industry and also never gained wide spread adoption. Beyond the standard Modbus protocols above there are literally 1000’s of proprietary derivatives of Modbus created to meet a company’s particular needs. These are not considered Modbus protocols but they took extreme liberties in borrowing many of the functions from standard Modbus. These range from industry giants like Eaton, Honeywell and GE to the now disgraced and defunct Enron. The reason so many companies based there solutions around Modbus are the same reasons that Modbus has become the most widely used protocol in the world. Why is Modbus Everywhere? The two biggest drivers of Modbus success are simplicity and that the code is open source. This combination has made adding Modbus Communication to a device nearly a no brainer for device manufactures. Cost and time to market are better than any competing protocol solutions. The simplicity also means that even low level processors can easily handle the protocol. That is why you see it dominating Industrial and Building Automation Market on the device side. Modbus messages are a simple 16-bit CRC (Cyclic-Redundant Checksum). The basic 16-bit Mobus register structure can be used to pack in floating point, tables, ASCII text, queues, and other unrelated data. Modbus has only a fraction of the functionality EtherNet/IP, Profinet, or BACnet/IP have but its simplicity and adoption means that end device can be found everywhere at competitive prices. Plus as other low level protocols prove there are plenty of applications and devices that are suited for less functionality. Less complexity means less confusion, support and integration efforts. The Nuts and Bolts of the Modbus Protocol Modbus is considered an application layer messaging protocol, providing Master/Slave communication between devices. On the OSI model, if you are OSI inclined, Modbus is a level 7 protocol. Modbus is a Master/Slave request/reply protocol and delivers services specified by function codes. The function codes in Modbus are elements of request/reply PDUs (Protocol Data Unit). To create a Modbus data unit, the Master must initiate a Modbus transaction. This function informs the Slave which type of action to perform. The function code field is coded into one byte. Only codes within the range of 1 through 255 are considered valid, with 128-255 being reserved for exception responses. When the Master sends a message to the Slave, it is the function code field which informs the Slave of what type of action to perform. To define multiple actions, some functions will have sub-function codes added to them. For instance, the Master is able to read the ON/OFF states of a group of discreet outputs or inputs (coils). It could also read/write the data contents of Modbus registers. When the Master receives the Slave response, the function code field is used by the Slave to indicate either an error-free response or an exception response/error response. The Slave echoes the initial function code in the case of a normal response as a form of hand shaking. MODBUS RTU versus Other Protocols Despite the limitations of MODBUS RTU, there are still many good reasons as to why it is still a contender among other industrial automation protocols. For one, MODBUS RTU is much easier to implement than newer protocols and is a dominant force in the market place. MODBUS RTU also requires significantly less memory. To implement MODBUS RTU, you can fit the necessary size of 2Kb on a small 8-bit CPU or PIC processor, whereas with BACnet and EtherNet/IP, you may require 30-100Kb of memory. MODBUS RTU Address Requirements Standard MODBUS RTU node addresses are 1-254, with 0 being reserved for broadcast messages and write only. However the 0 address is rarely used due to the fact that there is no confirmation that the message was properly received at the slave node. This doesn’t have much affect if your physical layer is RS-232 as only one node can be implemented anyway. RS-485 limits the number of nodes to 32, though some drivers will allow you to extend the amount. Bit Structure in the Byte The Bit of least importance is sent and received first. All devices within the network must interpret each transmitted byte analogously in this manner. There are no methods for automated recognition of baud rates is not assigned and the same baud rate must be utilized by the Server as well as all clients connected to the bus. No specific baud rate is specified by the MODBUS: typical baud rates are 9600 or 19200. MODBUS RTU Memory Map
The difference between MODBUS RTU and MODBUS/ASCII There are two basic transmission modes found in serial MODBUS connections, ASCII and RTU. These transmission modes determine the way in which the MODBUS messages are coded. In ASCII format, the messages are readable, whereas in RTU the messages are in binary coding and cannot be read while monitoring. The trade-off is that the RTU messages are a smaller size, which allows for more data exchange in the same time span. One should be aware that all nodes within one MODBUS network must be of the same transmission mode, meaning MODBUS ASCII cannot communicate with MODBUS RTU and vice versa. In MODBUS/ASCII, messages are encoded with hexadecimal value, represented with comprehensive ASCII characters. The characters used for this encoding are 0…9 and A…F. For every byte of information, two communication-bytes are used because every communication-byte can only define 4 bits in the hexadecimal system. MODBUS RTU, however, exchanges data in binary format where each byte of data is coded in one communication-byte. The MODBUS messages on a serial connection are not broadcast in plain format. They are constructed in a way that allows receivers an easy way to detect the beginning and end of a message. The characters start and end a frame when in ASCII mode. To flag the start of a message, a colon ‘:’ is used, and each message is ended with a CR/LF combination. MODBUS RTU uses a different method. In RTU, framing is constructed by measuring gaps of silence on the communication line. Before each message, there must be a minimum gap of 3.5 characters. To prepare for new messages, the receiver clears the buffer when a gap of 1.5 characters is detected. One of the main differences between MODBUS/ASCII and MODBUS RTU is that ASCII allows gaps between the bytes of a message with a maximum length of 1 second. With MODBUS RTU, continuous streams of messages must be sent. Properties of Modbus/ASCII and Modbus/RTU
|
1. Overview 2. Protocol of Modbus 4. Data Object Properties 5. Modbus RTU versus Other Protocols 6. Modbus RTU Address Requirements 7. The Difference Between Modbus RTU and Modbus TCP 8. Bit Structure in the Byte 9. Modbus RTU Memory Map 10. The Difference Between Modbus RTU and Modbus/ASCII 11. Properties of Modbus/ASCII and Modbus RTU Sign up for our FREE recurring newsletter to stay up to date on topics such as:
» Networking Technology » Latest Industry News 
» I want this file in PDF Format » I need to Modbus RTU-enable My Product For Your Immediate Needs Call: John Rinaldi Networking Project Manager 1-800-249-1612 1-262-439-4999 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
RTA, Inc. - The Industrial Networking Home for DeviceNet, EtherNet/IP, LonWorks,
Modbus TCP,
Modbus RTU, PROFINET CBA, PROFINET IO, BACnet, IEC 61131-3,
IEEE 1588, AS-Interface, PROFIBUS, EtherCAT, CoDeSys and other networks.
© 2009 Real Time Automation, Inc.
www.rtaautomation.com
Real Time Automation, Inc. 150 South Sunny Slope Road. Suite 130 Brookfield WI 53005 © Real Time Automation, Inc. All Rights Reserved. | http://www.rtaautomation.com |
(262) 439-4999 (V) (262) 439-4989 (F) www.rtaautomation.com |