Catching the ModbusFollow article
ment that came to Modbus was with the use of Ethernet as a media. Up till then it had lived only on RS-485 networks. However Ethernet is quicker and allows you to run over existing cables and reach out into the world if required. As such there is a dedicated port number for Modbus-TCP/IP or Modbus-TCP for short (if you can call that short!). This protocol variant dose not require checksums like RTU and ASCII as TCP and IP already include checksums that will detect errors in the Modbus payload. This also means you don’t have to worry about calculating it either - which is a little fun and I’ll come back to.
There is also another Ethernet variant that uses RTU as the payload - effectively adding back in the checksum. This is sometimes called Modbus-RTU/IP so that is stands out from Modbus-TCP. This variant however has a place in that it can be quickly passed though serial to Ethernet interfaces that have little or no intelligence allowing RS485 devices to co-exist on a larger Ethernet networks.
Despite the Ethernet developments Modbus-RTU is still as popular now as it was back in the late 70’s. This is because its very inexpensive to us a RS485 driver IC and use a UART that basically comes as standard on most micro’s now.
So the details of Modbus are as follows; a standard network will have one master and up to 255 slaves, each are polled by the master to either send or receive data. Each device, slave or Node will have a bank or registers that you can read or write to and from exactly like you would see in a I2C or SPI device. In fact Modbus is a lot like I2C.
The basic packet payload consists of a target address, a function command telling the device the type of transfer that's being sent (single bytes, block data etc) and then the data its self. This is then terminated with a CRC checksum.
The actual data that is sent and its meaning is totally open. There are no hard standards as to what should be loaded in to what register number or a format for the values. This is a protocol for allowing transfer of data between devices, as I said a lot like I2C and SPI. Having said that you will find that companies supplying Modbus solutions will stick with a set approach and some have even mirrored each other to allow some cross compatibility.
Here at ebm-papst we make fans that come with a RS485 and Modbus-RTU built in. I have talked about the benefits of using Modbus to communicate with equipment in this way and this can be found in the current etech magazine.
There are however two parts of Modbus RTU that people do struggle with, Timing restrictions and the CRC checksum.
The Timing is crucial in that there must be a set period of dead time between packets and a maximum gap size between bytes in the packet. This may sound a bit of a fiddle but its good as you can detect the start of new packets and sync your micro to the network.
The CRC uses a 16bit polynomial which sounds and at first looks really difficult, however there is lots of example code on the Internet that will allow you to quickly generate a CRC. However if your a PIC developer don't fall for the CRC generator that inside the PIC24’s and above, yes it does polynomials but not the same as required for Modbus, you will need real code to calculate it.
To go into the real detail of either of these points is another post in itself - and ones I plan on writing up and will place in the knowledge area on this site. I’ll add links to the post when they are available.
For anyone wanting to know more about Modbus then you have to go and visit www.modbus.org which is the true font of all knowledge. This site is the best place to start for developers or if you just want to troubleshoot problems your having.
So when looking back at the article in Elektor I can see reasons for using their own protocol but they could have made their Nodes compatible with a world or other equipment already out there.