Lost in the "bus war"


Thread Starter

Jorge Torres

I´m an old-timer instrument engineer living in the happy 4-20 ma world with PLC´S and simple DCS´S. Now that we are involved in a process control modernization prograam we are receiving messages from our suppliers to go to the bus technology. It seems to be a good solution and we don't want to buy equipment that will be obsolete in the near future. Kindly request help to learn about previous experiences and ways to jump to the new technology. How to avoid confucion in the vast filed of the bus war? What are the premises and justification to change? What would be a logic process control plan for the mill.

Crystal Majercik


Recently there was a supplement to InTech magazine called World bus. This supplement is sub-titled "Conquering the Digital Divide". You may want to try and access a copy by visiting:


Best to you,


Dear Jorge:

There are several good technical papers on this subject. However, you should also consider field experience and real implementations, since those tell the final truth.

I notice that you are located in Colombia, and so are us. We would be glad to share our experience with you. You can contact me at [email protected]

Best regards,

Alvaro Rodriguez
Tel 3609288
> How to avoid confusion in the vast field of the bus war?


> What are the premises and justification to change? What would be
> a logic process control plan for the mill.

Dare anybody reply.........

(There should be a FAQ for this!)

If you have a strong bent towards a particular supplier (i.e. nearly all Siemens......Nearly all Omron etc) you could just accept what they
propose, you will have plug and play support with most of your kit and there is always some way or other to link to other kit. OTOH, if you do not thouroughly understand the ins and outs you will pretty soon find yourself hedged in and will find that you have to select your hardware on the basis of it's network support, which can often
turn out inconvenient and pricey.

Siemens, and a few others, will of course propose Profibus. Profibus is an umbrella for a number of connection mechanisms which, although sharing some common ground, are quite different. In reality only one form of Profibus is highly deployed, DP. Profibus DP is very
straightforward, it is like a conveyor belt that continually rotates a set of values (called tokens, but not to be confused with a token ring) around all devices connected on the network. It is very easy to use and fits in nicely with the scan cycle concept of PLC programming. The big problem is that it is not scalable. Many people
who have had success with small DP networks lose their head, and plan on using it on a plant wide basis. This does not work. As the network gets bigger, you need to shift more and more data, remember that all the data that is to be used is being continuously cycled round. Profibus DP is notorious for eating up bandwidth, and little wonder that speeds have been pushed up to 12Mb/s, it needs it. But, at such speeds cabling becomes critical, special and expensive cable and
connectors must be used, and even so, the distance that may be covered is very small. Pretty soon you run into speed/length limitations.
Other Profibus protocols, such as FMS, do not suffer this problem, but they are not an upgrade. Switching from DP to FMS requires a re-think of the whole software/comms archtecture, and a lot of software re-writes, whatsmore FMS is not supported by all products that support DP. As a rule of thumb, DP is a good choice for interconnecting PLC's and field devices in a radius of up to about 50M, it can and is used
way over that, but you must study carefully what it has, and will have, to do (or cross your fingers, you could be lucky....!)..

If you are connecting together windows based PC's and HMI's, windows also has its own protocol for remotely accessing information, DCOM. There is an organisation called OPC which specialises in defining DCOM profiles (which they call interfaces) for automation applications. They
are backed by Microsoft and have a lot of marketing flair and savvy, and support from SCADA package vendors. They publish their standards
freely, and will even send you a copy on CD to anywhere in the world totally free of charge, not even postage. Now that is what I call open.
The catch? Well, it only works between windows platforms, interfaces to field devices generally require costly middleware. It is totally
unsuitable for use at a field device level, such as connecting an inverter to a PLC.

Then, of course, there is MODBUS, the 4-20mA loop of the fieldbusses! Nobody shouts about it but everybody does It. In reality MODBUS is a proprietary protocol designed for Modicon PLC's. However, they implemented a simple straigtforward mechanism for getting data from A to B and published the standard. They have never tried to extort any money from its use, or restrict its deployment. As such it has been very popular amongst field device manufacturers (motor drives,
temperature controllers, I/O units etc etc.). In addition to being open and free, it is so simple it can be done on the simplest microcontroller,
so just about anything with a micro and serial port can do it. With it being so widely used by smaller manufacturers (including specialists),
it is consequently supported in one way or another by just about all PLC manufacturers and SCADA packages. Siemens, who plug DP so much,
do not make DP available on their bottom of the range PLC's except by means of a comms module that can cost more than the PLC itself. Yet
you can easily implement MODBUS on the built in port using the freeport mode. Ironic really. MODBUS can also run over TCP/IP networks, i.e. over ethernet networks, standard dial PPP conections, or the internet (but add a password register;-), basically anywhere. Everything
you can do over MODBUS can be done over DCOM, so you can switch over to OPC using a wrapper at a higher level if that is required for windows
software packages if that is desired (or FMS et al come to that). The Downside is that MODBUS is not particularly fast or deterministic. It is great for supervision and control, but not suitable for high speed process control. The BIG downside of MODBUS is that it is not SEXY. There is no big organistion plugging it, there are no official logos, no seminars or standards committees (doesn't need them, its simple format
has been unchanged for years), you will not see MODBUS booths at trade shows, you will not see MODBUS articles in trade magazines. Even the Modbus.org website is pretty bleak, rarely updated and mostly comprised of links to what is a pretty poor subset of what is out there
(Tip: if you want Modbus links just stick 'MODBUS' into your favourite search engine). You cannot even produce a rich feature list. The only attributes of MODBUS are that it is simple, it is low cost, and everybody is doing it; and these are not good selling points, the first two because customers like to think they are paying high prices for high technology, and the latter because nobody actually shouts about using it.

George Griggs

I couldn't help but notice that no one has mentioned HART. I have had a great deal of sucess using it, It offers a couple of advantages over fieldbus. First it is a digital signal laid over a 4-20 ma signal. This means you can still use some of your old devices. Second there are about twice as many mfg.'s who product HART compliant devices than there are fieldbus, so if you want a particular vendor's product the chances are greater that if he offers it in a smart device. That device is most likely HART.
There are a lot of variables that will go into your selction ( location of devices, types of devices etc.). I too would recommend reading all you can. Good Luck!

Michael Lloyd

Hello, My group and I recently finished the implemetation of a Rosemount Delta V system. The system was installed in two, parallel train gas processing plants (turbo expander). It included 6 processors in separate, remote mounted panels. There were slightly under 200 Fieldbus I/O points, 12 HART points, 20 or so analog points, 4 RS232 or RS485 links to other equipment, and 250+ discrete I/O points. When the configuration dust settled we had determined that, in our collective opinions, the Fieldbus I/O was the only disappointing feature of the system. From a configuration perspective it was time constraining. There appears to be so much data that transfers to/from the device that any change in the configuration of the device is very timeconsuming. If you only have one workstation that is capable of configuration all work is stopped during a download. From the perspective of a technician we were unhappy that it took so long to verify calibration and that it took at least two people to perform the calibration/verification. They do not currently offer a handheld communicator for Fieldbus I/O. You can use a laptop but at 10 degrees F below zero and in the snow we could not make use of that option. Had there been a handheld comunicator available each person could have calibrated / verified / configured each end device simultaneously. This would have greatly sped up configuration / implementation / troubleshooting. As it was, one person had to be at the end device and another at the workstation. The HART I/O was pretty nice but it was slower than conventional analog I/O (configuration). The MODBUS communications capability of the system was fantastic. Very easy to configure and easily handled 3 different manufacturers idiosynchrosies. We have an S7 / Profibus system in a power plant that we own. The Profibus system is s l o w. Roughly speaking, Profibus follows the same architecture as Token Ring. In a Token Ring (and Profibus) system each device has to wait it's turn. The polling device passes a token around the ring. Each device looks at the token and determines if it is for that device. If it isn't it passes it on. If it is, it returns the token to the polling device to let it know that it is ready for the information to be sent. There is also error checking data that is passed between devices. As the system grows it slows down. Of all the systems that we have installed in the last few years (Foxboro IA, Rosemount RS3, Rosemount Delta V, Siemens S7 / Profibus, Siemens TI555 / Ethernet, TiWay, H1, RS232) the quickest, most reliable system has been the TI555 using remote base controllers to extend the I/O to the field and CTI2573 Ethernet comm cards (set on UDP). We built a switched ethernet network out of fiber optic cable, 10baseFL to 10baseT converters, Cisco 10/100Mbs switches, and Wonderware installed on NT platforms and with 10/100 Mbs ethernet cards installed in them. Update speeds are very quick (I've set the polling time for the Wonderware app as low as 250ms and had no problems. Norm is 750ms), reliability is fantastic (no failures of any kind in 3 years), accessability is great (If I am on our corporate WAN, either through a RAS connection or logged in, I can access each PLC on the network, there are 20, as well as each Wonderware node (there are 4). This makes support for this facility (there are 66 others) the easiest for my group. If you miss the Bus, I wouldn't worry about it too much. It's crowded and slow. Take the Ethernet express route and enjoy the freedom that reliability and servicability brings. Michael Lloyd DEFS

Michael Lloyd

I wish I would have read your post before I posted mine. Your Profibus analogy was great. You left out the best comm option for the Siemens PLC line (S7 and TI505 series). Ethernet. It's faster and easily as reliable as Profibus. It's also scaleable. You are limited to 100m is you use Cat5 UTP cable (copper) but you can extend that at least 20 fold (not sure of the exact limiting distance) by using fiber to copper converters and fiber optic cable for your data bus. ML