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.