Machine control beyond PLCs

Rahul Kulkarni Product Manager,
Industrial Data Acquisition and Control
National Instruments Corp.
Austin, Tex.

It is no secret that machine-automation systems are growing more complicated. This trend arises from a need for what once were considered advanced functions: faculties for predictive maintenance, intelligent fault handling, and custom control algorithms that go beyond traditional logic or process control. It is tough to get these advanced functions out of ordinary programmable-logic controllers (PLCs) that have historically been used to make machines intelligent. So machine developers increasingly have begun using other kinds of control hardware that is better able to manage high-level machine tasks.

It is useful to examine how a PLC works as a way of illustrating why and under what circumstances designers should consider other approaches to control. In particular, some machine controls now incorporate FPGA (field-programmable gate-array) technology for its parallel processing capabilities. This approach can make sense when embedded control functions must handle real-time responses or complicated tasks that extend beyond simple interactions with input/output points.

PLC SCANNING
The thing to note about PLCs is that they repeatedly scan I/O points and take actions based on what they see. Historically, these devices have mimicked the ladder logic that once defined the interconnections of electromechanical relays that PLCs originally were designed to replace.

Today, however, PLCs typically operate in accordance with an international specification called IEC-61131-3. This document, developed by the International-Electrotechnical Commission, details the guidelines for using a number of programming languages besides ladder logic, as well as for other operating factors. These factors include the operating system execution, data definitions, and the instruction set a PLC uses. Unlike in the PC world, where one C program works well on any computer, each vendor in the PLC world has its own flavor of an IEC-61131-3-compliant specification. However, the basic architecture of the system remains the same.

To illustrate, consider a simple example of how a PLC operates. Suppose you want to toggle an LED every second. A PLC program has three components to help do this: program logic, memory map, and I/O scan. For program logic, you write out a value True to a variable you might call LEDValue. This variable resides in the memory map. An I/O scan function then transmits a binary equivalent of the value in memory to the physical I/O line, turning on or off the LED. Thus, the memory map acts as the link between the program logic and the I/O scan.

Note the program logic and I/O scan are decoupled. This relationship lets developers of PLC programs do a variety of useful things, such as force I/O onto the memory map when debugging in the field, or updating a program on the fly when the I/O scan is still running. However, PLC programming can still be tricky. For example, programmers must be mindful to never create code that works as a blocking function, which may force the program logic to indefinitely halt.

The scanning architecture found in PLCs is excellent for controlling such sequential processes as turning on a conveyor if a proximity sensor goes high, then turning it off after the proximity sensor goes low. Of course, modern machines are more complex and reactive than can be represented by mere sequences of events. A typical packaging machine today devotes 20% of its control program to the logic for normal operation and 80% to fault handling. It needs a combination of sequential and reactive programming architectures to control such complex machines.

There is another style of industrial control exemplified by devices called programmable-automation controllers (PACs). The term PAC is usually applied to controllers that can handle functions that PLCs can only manage through specialized add-on modules. PACs are also known for the use of an open architecture that makes it easy to expand the basehardware or make connections.

An example of a PAC is the NI CompactRIO. It incorporates such embedded technologies as FPGAs to implement reactive architectures. All in all, PACs combine the best of embedded and PLC technologies to create an architecture well suited for programming complex machines.

It is useful to review the role of FPGA chips in embedded applications delegated to PACs. The FPGA consists of many programmable logic gates and programmable interconnects. The programmable components can be configured to duplicate functions of logic gates and such combinatorial functions as decoders. Most FPGAs also carry memory elements or complete blocks of memories.

An FPGA can be interconnected by system designers in a manner resembling a single-chip programmable breadboard. The programming takes place after the manufacturing process to let the FPGA perform logical functions the application might need.

FPGAs are generally slower than ASICs of about the same complexity and aren't practical for supercomplicated designs. They also draw more power than ASICs. On the other hand, designs based on FPGAs can generally get to market faster than those incorporating ASICs. And FPGAs can be reprogrammed in the field to fix bugs. So engineers use FPGAs either where it is cost-prohibitive to develop and fabricate an ASIC, or where the hardware must be reconfigured after going into service. Today, FPGAs appear in a variety of devices that include instruments, consumer electronics, automobiles, aircraft, copy machines, and application-specific computer hardware.

Engineers often use FPGAs in industrial control products, but only as an internal component. Most controllers that incorporate FPGAs don't give access to them in a way that lets developers change how the controller interacts with the end application. The task of redefining FPGA functions has historically demanded expertise in HDL programming or use of complexdesign tools more familiar to hardware design engineers rather than to control engineers.

Recently developed PACs such as CompactRIO, however, have begun giving developers better access to FPGAs. FPGA functions in CompactRIO, for example, can be specified with the National Instruments LabView program. (As a quick review, LabView is a high-level graphical-development environment designed specifically for measurement and control applications.) Each FPGA-based device has Flash memory available to store a compiled LabView program and can run it immediately after power up.

Facilities in LabView now let engineers configure FPGA circuitry to generate synchronized analog and digital signals that would only be available from PLCs through use of specialized add-ons. With the FPGA, it is relatively easy for the CompactRIO to execute digital logic at 20 MHz, analog closed-loop control at 1 MHz, and get servo update rates of 200 kHz/axis for motion control.

FLOATING POINT
PACs such as NI CompactRIO generally have a floating-point processor running a real-time operating system. One reason is because FPGAs have no way of executing floating-point operations. So the floating-point processor may communicate with the FPGA while taking on tasks that don't lend themselves to an FPGA fabric. These tasks might include data logging, networking, e-mail, transfers via File Transfer Protocol (FTP), and remote Web control.

An example of this approach can be found in an application devised by Active Signal Technologies Inc. and Mink Hollow Systems Inc. Developers there used a CompactRIO with its FPGA capabilities to devise a mechanism that functions in a manner analogous to a camshaft. The virtual camshaft drives a rotary valve in a hydraulic pump.

In this instance, developers use the CompactRIO floatingpoint unit to synthesize a sine function for driving a pump actuator. (The FPGA could potentially have generated the sine function using a lookup table, but this approach would introduce problems affecting phase resolution.) The application uses a motor, which turns a rotary valve in synchronism with the rapid oscillations of an electromagnetic actuator. A 512-step encoder resolves the angular resolution of the rotary valve to 0.7° per encoder step.

The FPGA reads the position of the absolute encoder, which directly corresponds to the location of the rotary valve. It then puts out a corresponding voltage to the pump actuator. This action effectively generates sinusoidal waveforms at 3 kHz and creates a virtual camshaft coupling the rotation of the motor with the excitation of the pump actuator.

The need for the 3-kHz rate made the FPGA the only viable option. The 44-MHz loop rate of the FPGA let developers create an effective resolution beyond that of the raw encoder signal using a technique similar to a sigma-delta A/D converter. Specifically, the system oversamples the encoder and timing bit transitions to boost feedback resolution from 4.2 to 1.05°. At the top motor speed of 30,000 rpm, the 9-bit encoder changes from one step to the next every 3.9 µsec. A single-cycle loop running at 44 MHz on the FPGA iterates 171 times in 3.9 µsec. By counting the cycles between encoder steps, the software interpolates the angular position of the motor during the next step of the encoder.

All in all, embedded technologies such as FPGAs can complement the sequential processing offered by PCs and PLCs.

MAKE CONTACT
National Instruments Inc., NI.com