What could have been and never was…
Once a year or so, just like the annual Girl Scout cookie sale (I love them all except those thin mints), I’ll talk to someone who has a Modbus Plus network. Once I hear that, I know exactly how the conversation is going to go. In short, they’ll tell me what the application is and what they need – but they’re out of luck.
Modbus Plus has always been interesting to me. You would think that if a technology had a name like Modbus Plus, it would be related to Modbus. You’d think that Modbus Plus might have a different command set or a modified transport layer but in the end it would look a lot like Modbus. It’s like the Ford Explorer having a Toyota engine and a GM suspension. You’d think that maybe it would offer some useful feature to you as you move up from serial Modbus technology. The name tells you it has to be related.
Well, if you thought any of those thoughts, you’d be wrong. Modbus Plus is not really related to Modbus at all. It uses the same data representation, but it’s an entirely different protocol built around a token passing scheme invented by Schneider Electric over 25 years ago. At that time, DH485, another token passing scheme from Allen-Bradley, was popular. I don’t have definitive proof, but it seems reasonable to believe that Modbus Plus was created in part to counter that technology from Allen-Bradley.
I’ve always been interested in token passing schemes. Instead of devices just passing messages from a Master to a Slave device, in a token passing network, all the devices take turns being the master device. When they hold the token, they get to send messages to anyone else in the network. Once the current token holder completes its messaging, it gives up ownership of the token and passes the token ownership to the next device downstream.
In concept, token passing is pretty simple. In practice, it requires a set of very sophisticated rules to make sure that token holders behave properly and that devices can enter and leave the network at will. A token holder, for example, must be prevented from monopolizing the token. Sharing is important. There have to be rules that govern how to generate a token on power up or if one is not circulating, who gets the next token, how new devices can join the network, and what happens when a device leaves the network – especially if it has the token when it leaves. When you begin to sift through the issues, what seemed pretty straightforward gets pretty complex rather quickly.
If an application requires a lot of peer-to-peer communication, token passing is going to be very advantageous over any other kind of architecture. Most other kinds of systems require configuration changes when new nodes are introduced or leave; in token passing networks the membership of the network is dynamic. That is useful in situations where nodes might physically travel from one place to another: on a pallet for example. When a node like that arrives at a new network, it announces itself and then forms a link between two other devices on the network so that it will get the token after the first device and before the second device.
Token passing is much more prevalent in non-industrial networks. It’s been tried several times over the years but has never achieved much traction. Modbus Plus did achieve some good penetration in the Schneider Electric customer base. The biggest hindrance to its widespread acceptance was probably that the specification and the chip set were always kept proprietary.
I hate relaying bad news to clients, but when they mention Modbus Plus, it just a matter of time until I tell them it’s time has passed.