Modbus RTU Protocol Overview by Edward Hague 
The History of Modbus RTUModbus RTU is an open, serial (RS-232 or RS-485) protocol based on master/slave or client/server architecture. It is popular, well established, relatively easy to implement and reliable. Since it is so easy to implement, Modbus RTU has gained wide market acceptance wherever Industrial Automation Systems (IAS) or Building Management Systems (BMS) need to communicate with other devices. In fact, Modbus RTU is probably the most implemented automation protocol of all, and a quick search of Google will confirm this. Modbus RTU messages, although simple, contain a 16-bit CRC (Cyclic-Redundant Checksum) to ensure reliability. The simplicity of Modbus RTU messages is a mixed blessing; on the one hand, the simple message structure ensures widespread, rapid and accurate implementation, but on the other hand, various companies have corrupted the basic 16-bit Modbus RTU register structure to pack in floating point, queues, ASCII text, tables and other types of non-Modbus data. ProtoCessor modules and FieldServers are user configurable and allow user adjustments to compensate for the above issues The best source of Modbus RTU protocol specificationsOne of the best sources for more detailed information is www.Modbus.org. Shortcomings of Modbus RTUReport by ExceptionAs mentioned, Modbus RTU is a client/server or master/slave architecture. This means that in order for data to reach the client, the client node needs to poll the server node. Modbus RTU can also be multi-dropped, or in other words, multiple slave devices can exist on one Modbus RTU network, assuming that the physical layer allows this, usually via the use of RS-485, modems or radio. Often dozens or hundreds of nodes are multi-dropped in this fashion, and at relatively low baud rates. Because of the low speed and number of Modbus nodes involved, changes in the field nodes can take tens of seconds, or minutes, to reach the client. There have been various attempts to create Modbus RTU “report by exception” or “unsolicited message” enhancements. However, as soon as this is done, the protocol is no longer Modbus RTU! Although the methodology may work if the same vendor provides both the client and the server nodes, this approach almost guarantees incompatibilities. If an application requires very fast data transfer it would probably be best to investigate a protocol that supports “report by exception”, such as EtherNet/IP or BACnet. Data Object Properties, or naming of the dataModbus RTU packets only transfer data. There is no provision for parameters such as point name, units, resolution etc. Modern protocols such as BACnet, EtherNet/IP and LonWorks all provide for these sorts of properties. In addition, there are various committees that also create profiles for various types of devices, for example, thermostats, generators, light switches etc. The LonMark organization (www.lonmark.org) does this for LonWorks. Once again, this has nothing to do with Modbus RTU. Complexity of protocols that compete with Modbus RTUAt first glance the enhanced feature set mentioned above may seem to eliminate Modbus RTU as a contender for new designs. However, Modbus RTU has been around much longer than these other protocols and currently has a larger market share. More importantly, these other protocols are much harder to implement and support. For example, the source code for BACnet can be had for about $20,000.00 and uses 32-100K of program memory. Also, there is no way that BACnet or EtherNet/IP can be fully supported on a small 8-bit CPU or PIC processor, whereas Modbus RTU will easily fit into a spare 2K or so. Maximum number of Modbus AddressesLegal Modbus RTU node addresses are 1-254. 0 is reserved for broadcast messages, and useable for writes only. This is very seldom used since there is no confirmation that the message was successfully received at the server node. If the physical later is RS-232 then only one node can be implemented anyway. The RS-485 specification limits the number of nodes to 32, although some RS-485 drivers will allow this limit to be extended somewhat. Modbus RTU Conformance TestingIn order to guarantee compatibility, a Modbus Conformance Test Laboratory has been established at the University of Michigan. See their website for more details. It needs to be remembered that although testing at this conformance test lab will guarantee that the raw data reaches the other node, the other node may not understand what all the numbers mean. The receiver of the data still needs to know what the data points in the “Modbus Memory Map” mean. FieldServers and ProtoCessors provide user configurable tables to allow users to “remap” the data. See the section on the “Modbus RTU Memory Map” later. Modbus RTU Interoperability TestingAs mentioned in the above section, simply guaranteeing that the data reaches the other node is not enough to guarantee that two dissimilar systems will work together. In addition to “Modbus RTU Conformance Testing”, devices need to go through a process of “Modbus RTU Interoperability Testing”. To my knowledge, there is no such organizations that do this testing at this time. Once again, ProtoCessors and FieldServers, through the configuration file, take the raw Modbus RTU data and provision it with additional properties such as names, units, alarm limits etc. and make all these properties available to the more sophisticated protocol. Modbus RTU vs Modbus/TCPOfficially now known as “IEC Publicly Available Spec: IEC PAS 62030 (pre-standard)” Modbus TCP could almost be defined as Modbus RTU inside a TCP/IP connection, with a 6 byte header to allow routing. For more information on Modbus/TCP see the official Modbus website at www.modbus.org. Other names that have been used for Modbus/TCP are Modbus/IP, Modbus Ethernet and Modbus TCP/IP. The Modbus RTU Memory MapAs defined, this Modbus RTU standard provides data in four Modbus memory map groups or data types.
|
For more information: |
