15 ways to fail at fieldbus - Part 1

If you are a “BG” (before Google) user of computer technology, you might remember when operating systems like Windows 95 and its successors touted an “easy” path to device integration. Most of the technologies—like USB and FireWire—were bus interfaces where disparate devices—keyboard, mouse, scanner, external drive—were auto-detected and presumably auto-configured for use by the PC. It was dicey in the early days, and many of us renamed the concept “plug and pray.” Today's reality is much closer to the original vision, but you’ll most likely still encounter a “Windows failed to install a driver for this device” message from time to time.

You might find a few engineers who will say fieldbus is easy, and continuing advancements in standards and systems make deployment less prone to error. But a perusal of any of the active user forums will reveal tales of troubles, which might make you think, “How did they mess that one up?” Fieldbus for industrial control systems is well beyond the frontier stage—there are scores of successful projects large and small—but there remain some common pitfalls that will prove vexing if they are not avoided early. Here are a few:

Fail to engage and train installers:

You may think all electricians can strip insulation and land wires, and for the most part that is all that’s required for fieldbus. But measures to ensure all screwdriver-wielding individuals are mindful of your desire for a quality install will pay off. With apologies to those who consider it part of their craft, I still review a guide for stripping-crimping-torquing (with illustrations) at the outset of a project, and inspect frequently with feedback. In harsh climates or where quality craftmanship may be elusive, use premade cables such as Turck.

Leave plastic shipping plugs in housings:

Water is the enemy of all things electronic, not just fieldbus. Sadly, this problem is not uncommon. Consider having your device suppliers ship instruments with permanent plugs/sealed threads in unused conduit connections, rather than rattling around loose in the box.

Fail to engage and train maintainers:

If fieldbus is new to a site, seek out every individual who connects a handheld communicator to an instrument, and spend time assuaging their fears. Get them functional methods for connecting to devices, whether it’s a handheld like Trex or a PC-based system. Provide or bring in trainers—there are many resources available. A lab or benchtop system for testing and trials is invaluable.

Fail to engage and train systems engineers:

Today, nearly all fieldbus configuration happens at the DCS level through its engineering interface. Devices can be delivered as blank slates with just a digital tag, and have all their important parameters downloaded at the time of commissioning. For most systems, the ranging and linearization is no different than 4-20 mA I/O, but there are some crucial things to know, like how inches of water column are measured at 4 °C and also at 68 °F, and one works for brand “blue” and the other in brand “turquoise.” Get these guys some training.

Get really creative with segment topology:

I haven’t calculated how many ways there are to connect 12 devices on a two-wire bus, and neither should you. I hate to discourage creativity, but simplicity is your friend. Except for very small projects (and then only with your constant oversight), make all your segments star (tree) topology.

Get greedy with device loading:

The fieldbus specification provides for up to 32 devices per segment, and most systems support up to 16. So, loading all segments to the max is possible and will reduce wiring and card count. But it isn’t worth pushing the limits, especially for an initial install. An installed device count that averages about 10-12 is plenty for savings, and ensures spare capacity and simplified, standardized segment calculations and documentation.