Profibus is an interesting technology for a lot of reasons. It is still very dominant in Europe, although the number of Profinet IO nodes is now growing as fast, or faster, than the number of Profibus nodes.
Like everything else German, Profibus has a couple of variations. There’s Profibus FMS (Fieldbus Message Specification), Profibus PA (Process Automation) and Profibus DP (Decentralized Periphery). DP is all I am going to talk about here. Honestly, I know almost nothing about the others beyond how to spell them. Profibus DP is the one with the majority of the nodes anyway.
So, why is Profibus so dominant? One factor is that it is the preferred way to connect to a Siemens PLC. Rockwell has a lot of traction in the US, but Siemens is worldwide and growing stronger in the US.
Its speed is probably the biggest factor in its success. Profibus DP operates at a startling 12 Meg. That’s 24 times DeviceNet’s max speed. It’s not Ethernet, but it’s fast enough for most everything except some motion control applications. Profibus DP gets this amazing speed by using a souped-up RS485. Special connectors and components are necessary to achieve that kind of performance.
Profibus is a Master – Slave kind of network (as is Profinet IO). Masters, also called Controllers, are usually Siemens S7 PLCs. Masters send outputs to Slave devices. Slave devices send Inputs back to the Masters. You can have up to 127 Slave devices and like DeviceNet, there is only one Master per network.
It doesn’t move a lot of data. The IO transfer’s size is adequate at 244 bytes, but for the kinds of devices used in discrete automation, 244 bytes is just fine.
Just like many other protocols, there is a buffer in the PLC (Profibus Master) that gets moved to the device (Profibus Slave) and a buffer in the device that gets moved to the Master. These buffers are moved cyclically. Lots and lots of my customers tend to think that just because there is data moving in two directions that it must be request – response. It’s not. The buffers moves are cyclic and completely independent.
Profibus devices look like an I/O rack to the controller. An I/O rack has some number of slots. Each slot can have a module in it. Just like in a physical world, a Profibus device with a virtual I/O rack could have a 16-bit Input module in Slot 1 and a 4 channel Analog output device in Slot 2. Even if the device is a weigh scale, it has to somehow adapt its data to this I/O rack data representation. It takes a bit of effort for a device designer to wrap their head around that.
The GSD file is how that data representation is communicated to the Controller. The GSD is the Profibus equivalent of the DeviceNet EDS file, only it’s more functional. The GSD tells the controller not only about the I/O rack configuration but is the link to integrating that configuration with the data table of the controller. And, of course, everything better match or nothing works right.
What I Dislike about Profibus
There’s a few things I don’t like about Profibus. For one, it’s expensive. You really can’t implement it in software – there are performance and system issues that make that extremely difficult. There’s two ways to get into the Profibus DP world. You either buy the ASIC from Siemens, or one of a few other vendors, or you could buy some adapter hardware.
You need special connectors on your product for Profibus, special cables and a way to configure your device. Configuration is usually done with three switches to set the Profibus address (1-127). That’s a plus, I’ll admit;generally you just set the address and you’re done.
I also don’t particularly care for the data representation. That’s kind of an anachronism in 2016. We’re tied to a structure developed 50 years ago and can’t get away from it. I don’t see a way out of it, though.
The real upside for the user community is that there are a lot of Profibus devices around. They’re fast, reliable and highly functional. You do get value for your money in the Profibus world.