Automation Adapts to Change

Sit and Spin: When engineers at TECO Westinghouse operate and test high horsepower motors, they use a PAC to supply control and measurement functions. The PAC facilitates hardware and software changes.

Engineers routinely specify programmable logic controllers (PLCs) as the "brains" needed to control industrial equipment. These controllers measure analog and digital signals, make decisions, and ensure process parameters remain within preset limits.

Often, though, when engineers design a piece of sophisticated equipment they run into a "PLC ceiling." Here's an example: Shell Global Solutions pumps natural gas, oil, and water through one pipeline from a North Sea well to an onshore storage tank. The tank naturally separates the liquids from the gas. Unfortunately, liquids accumulate in low spots in the pipe and form "slugs" that disrupt the normal flow and upset downstream processes. (Pressure builds until it blows a slug down the pipe, which creates pressure anomalies.)

To better control the flow, Shell developed a pre-separator and sophisticated algorithms that regulate the gas and liquid flow. But, to keep the process under control, the algorithms required more capabilities than a PLC could offer, so the designers turned to a process automation controller, or PAC, instead.

So, exactly what is a PAC? It includes flexible hardware and software devoted solely to measurement, control, and communication tasks. Thus, on the hardware side, a PAC may include a ruggedized cPCI-based PC, a PXI-based system, a custom-built embedded controller, or perhaps an FPGA-based controller with lots of I/O capabilities. A PAC still provides PLC functions, but it includes the ability to operate in multiple "domains," and it easily accommodates custom algorithms, gathers data, and communicates with high-level networks.

New test stations, production system, and other equipment often require engineers to include advanced capabilities such as machine vision, motion control, or high-speed I/O. PLCs may lack these functions, and those that offer them usually come with fixed algorithms and limited capabilities. A PAC, on the other hand, lets engineers integrate standard vision, motion-control, and I/O tasks with their control and measurement software. And engineers can customize the underlying software as needed.

Engineers often need to develop special motion-control algorithms that provide high-precision and low-overshoot motions, as well as customized motion profiles. Such algorithms cannot easily drop into a PLC, but a PAC can accommodate them and integrate them with existing software.

In a similar vein, the software used to develop a main control program must let developers easily test the application and quickly iterate measurement routines, control sequences, and specialized algorithms. Also, should an application require new hardware, perhaps moving from an industrial PC to a PXI-based system, the application-development software should make the transition with only minor modifications. Some minor hardware differences may require the use of new drivers, but the overall program structure should remain unchanged and should operate equally well regardless of the computer system that runs the PAC's application code.

Engineers who have programmed a PLC using ladder logic, functional blocks diagrams, or structured text should have no difficulty working with a language targeted at PAC-based control, test, and measurement applications. Some training, though, either obtained in formal seminars or by working with a consultant, can give engineers a head start. In addition, some hands-on training will quickly familiarize engineers with PAC software tools so within a short time they can develop useful code.

Not only does a PAC increase the flexibility of control and measurement functions, it also provides data-logging capabilities. In one case, a fastener manufacturer used a PAC to gather information about each fastener inserted into products. The PAC logged the insertion force and depth. That type of information can flow into a standard database for later analysis, or it can immediately drop into statistical quality-control (SPC) software. An SPC package helps operators locate and correct manufacturing problems before they cause defects. Keep in mind that the SPC software can run on the PAC. Software-development tools aimed at a PAC provide data-analysis and data-visualization modules that developers can customize. Again, that software runs on a PAC.

To re-emphasize the flexibility of a PAC, say the fastener company's quality-assurance engineers decide they need a camera to capture an image of each insertion. (A camera may need high-intensity LED lamps to "stop" the action on a fast-moving production line.) A PAC can accommodate a camera interface, and software-development tools can link the camera and lamp triggers to insertion parameters. Thus, the PAC can acquire images at, say, the point of maximum insertion force. The QA staff can later correlate images and process-variable data.

Because engineers use PACs in demanding applications, these units often must communicate with other equipment, either locally or over a network. Communications might involve downloading information to a corporate database, sending an e-mail alert message to an operator, or providing a Web page of quality-control information. Although some PLCs come with built-in Ethernet or serial ports, they may not let developers modify how they communicate.

A PAC, too, provides for built-in communications, but the overarching software includes access to the "stack" that permits communications via a protocol such as TCP/IP. (Don't confuse this ISO-model software stack with a processor's memory stack.) The open architecture of a PAC also accommodates communication-security software. And developers can add specialized communication ports that allow communications with custom or legacy equipment.