Many process control applications require much more than just real-time control, and extensive communications and data handling can tax the functionality of PLCs. In these instances, a programmable automation controller (PAC) can be a good fit. Most PACs are derived from the PC world; hence their relative strength when it comes to communications and data handling.
A good example of using a PAC instead of a PLC or a DCS is a recently implemented mercury emissions sampling system for monitoring stack gasses in a coal-fired power plant. A DCS would be too expensive and not rugged enough, and a PLC would struggle with the required communication and data handling tasks.
System integrator Data Science Automation (DSA) handled the project in collaboration with its client, Clean Air Engineering.
When measuring mercury emissions from coal-fired power plants, a proportional measurement technique is used that requires sampling rates to be adjusted continually to remain in proportion with stack flow, reports Richard Brueggman, the president and CEO of DSA.
All calibration, maintenance and leak-checking modes must be automated. The system we designed uses a National Instruments PAC mounted at the stack. The PAC operates autonomously to control sample collection for as much as a week, and the only hard-wired connection is an RS-485 output to a data logger. All control and programming of the PAC is through a wireless connection to a PDA [personal digital assistant], explains Brueggman.
Process control tasks performed by the PAC include closed-loop PID control of a set of heaters that maintain the sampling ports at constant temperatures. Each flow path is also under PID control in order to maintain the sampling flow at a constant ratio to the changing stack flow rate. Each of these PID loops references user-defined setpoints in conjunction with measured values to maintain correct the flow and temperature.
The real complexity in this application comes with data handling and with integration of the PDA and the PAC. Data is collected at one-second intervals, with each collection of data broadcast over a serial connection to the remote data logger. The data is averaged hourly, and averages are saved to a local non-volatile memory and used to adjust setpoints for flow and temperature control.
All data is compared with a series of alarm setpoints that raise system flags or stop sampling during the alarm. The system needs to enter and return from a suspended function during an alarm. The integrated RS-485 connection on the PAC allows industrial serial communication, and the expanded memory of the CompactFlash slot on the PAC enables long-tem data storage for the system, points out Brueggman.
Besides data handling, the other main challenge of the project was ensuring full remote control via a PDAanother function for which traditional languages arent suitable.
To my knowledge, you cannot program a PDA with ladder logic, structured text or any other IEC 61131 language. We chose LabVIEW graphical programming language to program the PAC and the PDA, says Brueggman.
The PAC is connected to an Ethernet switch, which allows network communication with the PDA through a wireless access point and wired communication with the plant TCP network. The PDA serves as the terminal to operate the PAC as there is no local operator interface.
Most PDA/PAC interaction consists of sending structured commands and data to the PAC from the PDA. These commands enable change of state, or updating of process variables, including PID coefficients and setpoints. The PDA obtains the output from the PAC by reading a library of hosted variables on the PAC.
When complex communications and extensive data handling are required, a PAC can simplify programming and be a better solution than a PLC.
