Why Aren’t More People Getting on the Fieldbus Bus?
Migration projects often ignore opportunities to add new functional capabilities with field devices.
After being involved in a number of migration projects, I’m surprised at how few of these considered taking advantage of the extra capabilities of fieldbus-based instruments, drives, and positioners. This is not a new phenomenon, but it was more understandable in the early years of the technologies. To some degree the fault lies with the manufacturers. Fieldbus communication was marketed as being a way to reduce the number of wires required and the size of the cabinets required. To a great degree the real benefits of its ability to support smart instruments was a marketing afterthought, “Look at all the room you can save and, oh by the way, you get this extra information.” As a result, the typical migration project team says, “We already have all these HART instruments that give us the extra data and we’re not pulling any new wire, so why should we change?”
Of course this assumes they’re using HART, which many plants don’t, so they have no capability of accessing smart devices without using a handheld communicator.
Sounds like a logical argument, but is it really? What’s being overlooked? How many migration projects ignore the opportunity to replace a few worn out devices? How many migration projects are justified solely on obsolesce?
On the other hand, how many migration projects don’t involve control and/or operational improvements? In my experience, the answer is none. One or all of these have been a part of every migration I’ve done, but at the same time, the end user has only been willing to consider upgrading to fieldbus networks if the migration was from pneumatics. Yes, there are still facilities in this country that are controlled by pneumatics.
As you discuss the parameters of a migration project, keep in mind that changing to a fieldbus may not involve pulling new wire. Changing to fieldbus communication with its improvements can be as simple as replacing one nearby device with a bus device and using its existing signal cable as the trunk for a bus segment. Then you just have to pull enough wire to reach the bus “brick” that the other device is connected to. This works fine with Foundation fieldbus or Profibus because the cable spec is easily satisfied with a good analog instrument cable. It may also work with ASi depending on the kind of wire connecting the discrete since its cable spec matches a good non-shielded non-twisted electrical cable. DeviceNet is a little different as it requires a two-pair cable with a bare ground, but again, you might make it work if you’ve pulled a multi-conductor cable to a junction box.
What is the downside to doing this? If you don’t do something to clearly identify the wiring as being different from that connected to classical analog and discrete I/O you could, as one of my customers did, have a technician connect a non-bus transmitter to your segment. Depending on which fieldbus it is, it may or may not cause any larger problems, but you’ll have an impossible time getting anything out of the device. That particular customer tried to save even more money on his project by making his own Fieldbus bricks out of terminal blocks, but that’s a story for another day. My recommendation is to find an application where you’d like to have additional sensors but can’t pull new wire or to find an opportunity to make such a conversion and connect the most feature rich bus device you can find just to find out what you’re really missing.
This post was written by Bruce Brandt. Bruce is the DeltaV technology leader at MAVERICK Technologies, a leading system integrator providing industrial automation, operational support and control systems engineering services in the manufacturing and process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, and business process optimization. The company provides a full range of automation and controls services – ranging from PID controller tuning and HMI programming to serving as a main automation contractor. Additionally MAVERICK offers industrial and technical staffing services, placing on-site automation, instrumentation and controls engineers.
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.