The following tip is from the ISA book by Greg McMillan and Hunter Vegas titled 101 Tips for a Successful Automation Career, inspired by the ISA Mentor Program. This is Tip #28, and was written by Hunter.
Over the course of many years, I have learned to be suspicious of anything that is marketed as “Plug and Play.” I suppose I may be the only person with this problem, but with amazing regularity, I find plug and play devices that do not plug and play.
Concept: Control system communications can be a tricky thing. In some cases, the wires are hooked up, and everything begins communicating immediately. In other cases, NOTHING works, and it can take hours, days, or weeks to get the first piece of data through.
Details: It is thrilling to browse for a network printer, find it, and suddenly be able to print without any further problem. Unfortunately, more often than not it does not work that way. The computer cannot find the printer, or the printer driver cannot be found, or the driver is not compatible with the computer’s software, etc. In short, it can take a great deal of time and effort to get “plug and play” devices to actually play.
With the advent of instrumentation networks, many devices and control networks are also marketed as “plug and play.” Presumably, one can just hook up a device, and it will immediately start communicating. However, real world experience suggests that it is not always so straightforward. In my experience, either it works just as marketed and the system communicates immediately, or it will take hours, days, or even weeks to get online … especially if the technology is unfamiliar. Once communications are established, the networks generally work well, but getting to that point can be a trying experience.
If the project calls for the incorporation of a new network type into a control system, fully test it BEFORE the start-up begins. Gather a couple of devices (ideally one of each type), and set up a temporary network in advance to establish communications and get the network configured. Even if the project is just extending an existing network, be sure to pretest any new device types that are not already functioning. New devices usually require a different communication file or may need a special character string to get them to respond on the network. Even new versions of equipment that have been used for years can be troublesome if the hardware revision has changed.
Watch-Outs: On one project, the team added a new positioner to an existing Profibus PA network and did not test it in advance. Once the plant was shut down, the positioner was wired into the network, and problems immediately ensued. First, the positioner was a new model and was not listed as a choice on the system. The correct GSD was found, but then it had to be incorporated into the gateway configuration without deleting the existing setup and rebuilding it from scratch. Eventually, that was accomplished, and the device was finally communicating on the network, but the unit ignored the commands being sent to it. After multiple phone calls to several tech support sites across the United States and Canada, the team finally located an expert in Germany who could speak no English but did know the product. Emailing through a translator, the team finally realized that the positioner required the system to write a hexadecimal command to a certain register in the positioner so that it would accept the system command value as legitimate.
The device literature marketed the positioner as a “plug and play” device.
Exceptions: Some communications networks really do work right out of the box. However, a project team would be wise to plan for the opposite.
Insight: About a week before every major DCS start-up, consider performing a “network startup.” During this time, power up as many of the systems as possible, and bring as many of the communication systems on line in advance of the plant cut-over.
This early effort is critical because it gives the team a full week to resolve any fiber or major communication problems before the plant comes down. If communications are not established in advance, the whole checkout can be stalled while engineers frantically try to establish system communications.
Rule of Thumb: Find a way to test any communication network prior to installation. It may work perfectly without any issues at all. But when it fails to work, it can take a great deal of additional effort to get it functioning.
About the Author
Gregory K. McMillan, CAP, is a retired Senior Fellow from Solutia/Monsanto where he worked in engineering technology on process control improvement. Greg was also an affiliate professor for Washington University in Saint Louis. Greg is an ISA Fellow and received the ISA Kermit Fischer Environmental Award for pH control in 1991, the Control magazine Engineer of the Year award for the process industry in 1994, was inducted into the Control magazine Process Automation Hall of Fame in 2001, was honored by InTech magazine in 2003 as one of the most influential innovators in automation, and received the ISA Life Achievement Award in 2010. Greg is the author of numerous books on process control, including Advances in Reactor Measurement and Control and Essentials of Modern Measurements and Final Elements in the Process Industry. Greg has been the monthly "Control Talk" columnist for Control magazine since 2002. Presently, Greg is a part time modeling and control consultant in Technology for Process Simulation for Emerson Automation Solutions specializing in the use of the virtual plant for exploring new opportunities. He spends most of his time writing, teaching and leading the ISA Mentor Program he founded in 2011.
Connect with Greg
Hunter Vegas, P.E., holds a B.S.E.E. degree from Tulane University and an M.B.A. from Wake Forest University. His job titles have included instrument engineer, production engineer, instrumentation group leader, principal automation engineer, and unit production manager. In 2001, he joined Avid Solutions, Inc., as an engineering manager and lead project engineer, where he works today. Hunter has executed nearly 2,000 instrumentation and control projects over his career, with budgets ranging from a few thousand to millions of dollars. He is proficient in field instrumentation sizing and selection, safety interlock design, electrical design, advanced control strategy, and numerous control system hardware and software platforms.
Connect with Hunter
