JohnRezabek

Ancestors of device diagnostics

Feb. 15, 2019
Modbus gave us our first “open” communications between analyzers and controllers.

It was 1983, and detailed engineering for the project was in full swing. The goal: to extract then-valuable aromatic hydrocarbons—molecules containing the benzene ring—from a gasoline stream. The project required a significant number of gas chromatographs (GC): online analyzers for separating and quantifying individual components of a process stream. These complex, online instruments were necessary for the licensor (the inventor and developer of the aromatics processing technology) to make crucial process adjustments, as well as prove that their design was meeting the client’s specifications.

Complex analyzers created a few challenges for instrument designers and engineers of that day, as well as the end users who had to maintain them. In the case of the aromatics project, one of the first challenges was bringing the numerous 4-20 mA outputs into the first-generation DCS. The four to eight outputs from each GC required a lot of DCS analog inputs, which was costly and consumed a lot of capacity, including physical space, in the early DCS. Both the GC’s Optichrome 2100 system and the TDC-2000 DCS were microprocessor-based, but each used its own unique network interface, protocol and physical layer (typically coaxial cable). What we called a PC wasn’t necessarily a personal computer, as that had only recently entered the vernacular. The original PC, the programmable controller from Modicon (now part of Schneider Electric), had only recently introduced Modbus for interconnecting its controllers. This open standard was only beginning to be explored for connecting disparate digital devices.

Within a few years, programmable controllers became PLCs, and the Modbus interface for both process GCs and DCSs became a routinely touted feature—in fact, the path by which many systems of the day proclaimed “openness.” It was not inexpensive nor especially easy to exploit the technology for getting data digitally from the GC network (or other systems, for example, PLCs). But it was well worth it. Not only did it eliminate the need for scores of analog loops (and all the associated wiring, loop diagrams, checkout, etc.), but it also allowed the controls engineer to actively monitor the health of every GC.

Each GC was tied to a unique Modbus ID, so rudimentary checks by those who configured the interface were enough to validate the loops. Optichrome GCs, for example, included the sample time of each result as a standard feature, and later versions even included some error checking based on flatline detection (e.g., are new results identical to the last set). This meant that data validation could be incorporated in closed-loop control schemes. Rather than placing advanced control loops in manual (and thereafter left in that state) whenever the results were driving the process somewhere clearly unreasonable (such as cutting column reflux to nil), the loop could shed to some more conservative mode (local auto, for example), and the operator could be alerted to a measurement issue.

Having a measurement device report its results digitally—frequently with little loss of significant digits for the 16-bit systems of the day—was one benefit. A huge reduction in wiring and all the associated engineering was another. And having a time stamp of sorts provided by the measuring device (GC in this case) along with its health is something we take for granted where bussed communications are exploited. Controllers don’t use measurements unless they are “good.” When the use of microprocessors in everyday instruments like valve positioners and transmitters became commonplace, it was natural to start thinking that all computer-based field devices should communicate digitally, and the same benefits and more would ensue. It took a decade or two, but today, they do.

Chromatographs and their ilk can still be integrated with Modbus, but the uptake of more modern real-time buses has been slow. Modbus is cheap and effective for GCs and doesn’t require a raft of (not free) testing and certification, such as that required for a fieldbus checkmark. Nonetheless, numerous simple analyzers—pH, conductivity, density, for example—are available with fieldbus communications, including Foundation fieldbus, Profibus PA, and Profibus DP.

Controls specialists seeking to employ analyzers should avoid the rut of analog communications. Modern systems support numerous buses as well as Ethernet and OPC (not necessarily the simplest, least expensive, or most reliable choice). Design your controls to make use of digitally integrated analyzers and associated diagnostics.

About the author: John Rezabek
About the Author

John Rezabek | Contributing Editor

John Rezabek is a contributing editor to Control