It's been around since the beginning of time. Well, certainly since the beginning of the PLC industry. It was developed for use with Modicon—now Schneider Electric—programmable controllers. The name, "Modbus," comes from Modicon bus.
The two constant reasons for device communications are programming and data transfer. Modicon needed a way to load and save programs into its controllers, so there are a set of commands that do that. The most used commands are the data transfer commands.
Modbus is a master/slave—generically referred to as request/reply—communications protocol. One device, the master, sends requests to the slaves, which, in turn, reply. The master can read data or it can send data. The master addresses only one slave at a time. This scheme is referred to as polling and it keeps thing simple. One command, a request and reply must be completed before the next one is started. Allowances are made for failure to respond and other errors.
In the old days, the devices were connected using multi-drop networks such as an RS-422 or similar networks. Sometimes modems were used.
A system at Niagara Mohawk Gas & Power had a master in Syracuse, N.Y., that collected data from 17 remote sites across upstate New York. The modem at the master connected to leased lines to each remote station.
[pullquote]The modems communicated at 2400 baud. The master was an Intel 8080-based card bus system with Modbus master communications programming. The slaves were single-board computers based on the Intel 8085 CPU, and the Modbus communication was something that I developed for the project. The software was divided into functions for sending data, receiving data, building the Modbus commands, decoding the Modbus replies and polling control. I thought that I had correctly implemented the CRC message error-checking routine. It was the same on both ends, so it did not report any errors. When I tested it with a Modicon 484, it didn't work. I looked at the CRC bytes for different large messages, and they were all the same. After a close look at the specification, I realized that with large messages, the CRC bits were being shifted out of range.
Modbus commands read and write data to blocks of memory—discrete inputs, coils, input registers and holding registers. The first digit of the address indicates registers (4), inputs (1), outputs & coils (0). One of the most confusing things about Modicon Modbus addressing is the communications command address of zero is "register 4001" or "40001," depending on the device. The same thing applies to the bits command address of zero: "1001" or "10001."
The first thing to do when you’re getting data—it's not what you expect—is to check the address offset. The second-most-confusing thing is the byte location in a word. Is it high byte-low byte or low byte-high byte? The original Modicon Modbus used the unconventional high byte–low byte. The registers are 16-bit, but do they represent a signed or unsigned integer? The user has to coordinate this at both ends. What about scaling? You can use fixed-point scaling in 16-bit registers, but this is hard to keep track of and document. You need 32 bits to properly represent floating-point data.
Old Modbus now can be packaged in Ethernet (TCP/IP protocol) packets to transport the requests and replies. If the devices are programmed to operate as both master and slave, then each device can control the communications it needs to transfer data. It would be like a peer-to-peer protocol.
Modbus is a good protocol for reading from and writing to devices from different manufacturers, using a memory map agreed on by both parties. It requires extra effort to map data and keep documentation up-to-date. I use an Excel spreadsheet to organize everything. I can make a column of Modbus addresses quickly by entering the start address and dragging the fill handle in the bottom right corner of the cell down the cells that I want to fill with the addresses—autofill. Then I can relate each address to tags and descriptions. It's easy to cut and paste cells to rearrange things.
There are pros and cons to using Modbus. Native protocols don't require you to map the memory to numerical addresses, and the data types and formats are handled behind the scenes. Old Modbus does the job when different devices don't have a common denominator.
N. Lewis Bodden is a control systems consultant in Houston, with 35 years of practical experience in all aspects of system integration and control system design, completing many PLC-based projects across many industries.
