Programmable automation controllers (PACs) excel in commanding complex automation setups that involve PC-based and HMI functions as well as process control (largely because of the way they handle I/O). PACs are also increasingly common in motion applications for machining or handling discrete product thanks to the flexibility and interoperability they offer machine designs.

Today’s PACs evolved as an option for complex control when microprocessors with significantly more performance became affordable and commonly available. PACs differ from the still-dominant form of control for motion — the programmable logic controller (PLC) — in that all PACs can perform as PLCs but not vice versa. That’s because PACs serve multiple channels of communication; high-data traffic; and coordination with intelligent subsystems. Most performance PLCs can host intelligent processors in their backplanes — such as Ethernet modules with ports for expanded data and communications, for example. But such setups can be expensive where vendors’ proprietary backplanes and operating systems are costly.

Consider how PACs emulate the behavior of electric-relay controls. Relay logic executes sequentially with repeatability and reliability — on hardware rugged enough to survive harsh industrial settings. All logic rungs are defined by inputs and outputs that are logically connected to trigger actions after satisfying precise circuit-logic conditions. This means one logic rung can’t execute without preceding conditions met first. Extra left-hand power rails for loops and jumps extend relay-system capabilities to build complex logic … but larger and more complex permutations of these setups can be costly to build and maintain.

Some history on this: PLCs themselves replaced relay-based controls and were the first standard as electricity became the dominant power source for manufacturing. As control requirements became increasingly complex, hard-wired relay control became impractical because manufacturing needed more reliable and reconfigurable (programmable) systems. Given their primitive hardware and rigid task execution, early PLCs were difficult to network. In contrast, today’s PLCs are quite easy to implement. The first PLC in the late 1960s used available electronics that duplicated the behavior of relays — plus were programmable instead of hardwired. This necessitated proof of repeatability and reliability on the plant floor. So custom memory boards, logic-controller boards, backplane interfaces to I/O modules, and heavy-duty circuitry helped these PLCs run in industrial environments. It was a new concept to let users write application code using the symbols and logic of relays.

Today’s PLCs are still more appropriate than PACs in standalone applications such as machine axes that run preset sequences. The rule of thumb is that anywhere PAC functions would otherwise go unused, it still makes sense to use the a more economical PLC. Pressure from plant personnel and the enduring value of ladder logic also make PLCs the first choice in many applications.

Where PLC setups yield to PACs — and the drive of DCS, RTU, and PC tasks

As various industries came to accept PLCs, they came to be used in myriad applications. Increased PLC use has also followed the continuous improvements in their speed, ability to run complex math functions, and communication networks.

But once PLC behavior was proven reliable on a computer, the PAC was born. The aerospace and medical industries are two driving forces here. The FAA and FDA mandate that day, date, and time-tagged data about manufacturing processes are stored for extended periods of time — particularly well run on PACs. Even manufacturers of simple consumer products find such information useful for defending designs in product-liability lawsuits. What’s more, it’s not just product-data logging that leverages the data-tracking functions of PACs; running predictive maintenance and operations monitoring uses data from controls, too. That necessitates more data and complex network interactions — which means PACs will only become increasingly common.

Just as PLCs, the controls known as distributed control systems (DCSs), PCs, and remote terminal units (RTUs) include hardware and programming to satisfy specific applications. PAC hardware can run functions as software to replicate legacy forms of these and other pieces of motion-system hardware. Here’s the catch: Early-generation versions of all these controls were engineered with features to serve specific markets. So for today’s engineers working in siloed industries served by legacy controls, the way in which PACs replicate several control schemes boosts convenience and familiarity during implementation.

Refer to the figure at left: IDEC and Advanced Micro Controls Inc. (AMCI) offer stepper motors and drives with integrated motion-control functions. The products combine with IDEC FC6A PLCs to let OEMs quickly implement single and multi-axis motion functions. Macro instructions embedded in PLC WindLDR programming software is configurable with drag-and-drop commands to control up to 12 axes. Motion-control macros in the FC6A PLC simplify programming.

Case in point: AMCI by IDEC’s iANF2E two-axis controls can accept encoder feedback; the controller includes six discrete inputs for move conditioning and other functions, and four discrete outputs to indicate status and provide diagnostics. A full complement of motion profiles is selectable via an IDEC MicroSmart FC6A PLC connected to the controller via an Ethernet-based Modbus TCP link. Up to six controllers connect to the PLC to drive 12 motion axes.

Note that computer processors’ increasing capabilities and declining cost have blurred distinctions between various control types. Case in point: The PAC itself is the extension of the PLC to incorporate greater data-processing and communications capabilities incomprehensible when the PLC was invented.

Originally, DCSs were a collection of RTUs operating on normal phoneline networks, and their communications were simple alarm states from remote equipment. RTUs were small standalone controllers to execute modest logic tasks — usually off simple information such as elapsed runtime or total units of counted, for example. Early DCSs didn’t transmit data, but one could rent a line from the phone company and create an alarm to indicate that a process value had been exceeded or the RTU needed reading, for example.

Industrial PCs have advanced with processor capabilities following Moore’s law. Early industrial PCs were merely programming terminals and storage devices, because their operating systems weren’t robust enough for industrial controls. Now there’s no such limitation, because of vastly improved hardware and widely available realtime operating systems such as Linux for IPCs.

Some PACs have multi-processor architecture to support multiple programming environments — and run multiple DCS, RTU, PLC and PC functions. PACs also have high-bandwidth internal architectures that allow multiple processors and multiple tasks to simultaneously execute … so designers can create myriad control-system structures to satisfy complex and concurrent application requirements.

Single-axis and multi-axis motion designs (where PACs make sense)

As mentioned, PLCs are still by far the most common choice for simpler setups of standalone or single-axis motion. As a side note, such applications are seeing more inroads from motor drives sporting controller functions. These motor drives excel in machine designs that still need PLC functions with multiple interfaces — including Ethernet communications and digital I/O, for example. Because such motor drives can also incorporate motion controls delivering S-curve, camming, and freeform motion profiles, OEMs are more likely to pick them than PACs in otherwise-simple designs eliminating standalone PLCs.

Contrast the needs of these motion designs with more complex setups. PLC modules for single-axis motion are managed by a main processor or primitive sub-processor in the motion module; they interface with a main processor over a PLC backplane. But any PLC modules for single-axis motion control with low encoder-frequency rates can limit performance. Other PLCs limit how fast the position register can update, which in turn limits machine throughput. In contrast, PACs handle higher bandwidth on the backplane, so in complex motion applications can share motion data with multiple motion modules. That boosts performance. High-bandwidth backplanes also makes for more powerful motion modules … so depending on the processor core, a motion module here may be capable of complex axis-to-axis coordination sufficient for advanced motion in machine-tool or robotic applications.

No matter the permutation, multi-axis machine controllers include hardware and software in a structure organized around the management of complex motion. Consider the task of tracing a circle with two linear axes. Such coordination necessitates fast axis-position updates and comparisons to predicted position — along with error correction to the speed command of each axis-driving motor. This is a very demanding realtime task. The speed of the processor’s execution must be many times faster than the speed of the motor feedback. Given the computing capabilities of today’s processors, PACs (and PC-based controllers) are primed to handle such multi-axis motion control. It’s true that each platform does this in its own way — and it’s common to have myriad independent motion axes in a machine with each operating independently off a start-signal input. But full multi-axis motion usually works to coordinate multiple axes through mathematical definitions.

The earliest multi-axis motion control was computer numerical control (CNC) of the 1950s. These CNCs had computer hardware running programming languages for automating metal-parts manufacture. The advent of the transistor and integrated circuit drastically reduced the size and cost of CNC hardware, but its command language and architecture persists to today. In fact, multi-axis motion control since the 1950s has evolved as a unique class of controls to satisfy programming-environment requirements. The development has been complicated by how suppliers choose different processor platforms to go with their proprietary programming languages. User libraries arose to give users higher-level programming tools … but some are still vendor specific, complex, or time-consuming to use.

Trends towards standardization continues to address such issues. PAC vendors now produce general-purpose control hardware that integrates into IT networks but is rugged enough for industrial settings — and modular like the PLC form factor. This necessitates relatively advanced controller hardware so the PAC can function in any control application. It also means that PACs are equally capable of managing large data-gathering networks, or running machine control logic, or doing both simultaneously. So when it comes to running multi-axis motion control, today’s computing power delivers. Prompting more standardization on the software side is IEC-61131, which dictates the form of much of today’s ladder-logic programming and (in versions 3 and 4) motion extensions for motion programming in the ladder environment. Depending on the motion job, the ladder approach may be fine … but it’s not usually multi-axis.

In addition, motion-controller inputs and outputs from homing and limit switches and encoders are high-level inputs that must be dedicated to a specific axis on which they’re setup to work. Sometimes PACs need add-on modules to execute their special functions. Remember that PACs are architected mostly as PLCs, but the major difference (from an electronics standpoint) is how PACs have a high-bandwidth backplane that:

• Allows integration of various architectures

• Allows additional processors to boost the functionality of the primary PAC.

So software in the main PAC can manage intelligent peripherals, but it’s often useful add devices to the system architecture when an application needs control functions that exceed the main processor’s capabilities. A common add-on is remote I/O racks using standard offerings implemented with high-frequency Ethernet as the communications interface. These setups often use an Ethernet gateway module in a local rack with the main controller … which in turn supports the Ethernet link to the remote I/O rack. Ethernet updates faster than older PLC backplanes … though in a PAC with high bandwidth, data rates aren’t an issue.

Consider the special cases of testing and machine vision. Test setups needing high-speed data acquisition often include timing and triggering functions on their PXI backplanes. Adding a PXI bridge module (or PCI or VME) to a PAC makes the technology available on other bus architectures in the PAC environment. Most machine vision still uses standalone control because the processing burden and speed of vision demand it. But PAC suppliers continue to expand the repertoire of control capabilities by offering high-speed communications bridges to other subsystems. So machine-area networks with machine vision can be demanding — and yet the high-speed communications supported by PACs are an industry-accepted solution.