How to Specify a Controller for Your Motion System

A system might have ultra-high torque motors and precision bearings, harmonic gearboxes and 24-bit absolute encoders. If the motion-control solution isn’t properly application-specified to match the characteristics of the machine and the requirements of the project, the motion system will never perform as desired. Back in the day, the choice of controller was simple: A programmable logic controller (PLC) ran the machine and a standalone motion controller handled path planning for the motion system. Today, OEMs have a number of additional options, including PLCs with motion capabilities, stand-alone motion controllers that can tackle machine control, programmable automation controllers (PACs) that provide all-in-one solutions, PCs with motion capabilities, and even smart drives that implement decentralized control. With so many choices, the question is how to drill down to determine an effective solution.

“At a really high level, it's all about the level of coordination and the type of application that the customer is involved with,” says Mike Miller, Senior Commercial Project Engineer at Rockwell Automation. “The Mnemonic that I developed when I was in the field was the MMM:  mass, move, and means. What are you moving? How fast do you want to move it? What are the dynamics? What is the move profile? What are you using to move it? All of those pieces go into your sizing and selection.”

Controller Options
Choosing a controller starts with understanding the different approaches and mapping them to the needs of the application.

Smart Drives with Distributed Architectures
One approach for applications with a limited number of axes uses smart drives in a distributed control architecture. Today’s drives incorporate onboard processing power and memory to support closed-loop motion. They can control a single axis or, when daisy-chained to other drives, create a distributed control fabric capable of achieving synchronized motion. Consider a pick and place application with an XZ gantry. The Z-axis drive would begin its upward motion, then command the X-axis drive to translate the load on the horizontal axis. The result is a move from (X1,Z1) to (X2,Z2).

On the upside, a distributed hardware architecture significantly reduces complexity and cost, not just in terms of the standalone motion controller but also in cabling and installation. Instead of running a cable from the cabinet to the axes on the machine, the integrators can simply run a cable from one drive to the next. The result is less complexity, lower cabling costs, and fewer points of failure.

The approach has its limitations, however. In the case of the gantry, for example, the level of synchronization would be limited. “Would they move in a perfect vector move?” Miller asks rhetorically. “Would they move in a coordinated manner?  Could they round corners to make themselves more efficient?  Not without a higher-end controller. They would just move themselves and reach their endpoints at some random time.”

PLCs Used for Motion Control
PLCs are the workhorse machine control solutions. They are capable of handling large amounts of I/O for tasks like timing and counting, and other sequential machine logic. They are basically industrially hardened computers that are purpose built and tested for the application by the vendor. The result is a stable, reliable, and typically scalable control platform.

Because PLCs are computers, they can be programmed to interface directly with the drives to control motion axes. The degree of sophistication involves involved depends on the processing capabilities of the PLC. Low-end, commodity PLCs are best suited to simpler motion¾start, stop, simple motion profiles. For a machine that only requires a few axes of non-synchronized motion, a PLC can be an economical, compact solution.

There are trade-offs, of course. “They don’t always have the greatest interface in the world,” says Miller. “Another drawback is that the user has to now configure the drive and the coordination between the drive and the PLC, and possibly even the network that lets them communicate.”

They may also have communications limitations that can compromise performance. “They are typically slower in terms of communications with other devices when even moderate amounts critically fast real-time data are required across several systems,” says Kevin Hull, Motion Applications Engineering Supervisor at Yaskawa America (Waukegan, IL).

In contrast, the latest generation of high-end PLCs can perform tasks that used to be the province of standalone motion controllers, like linear interpolation and some types of coordinated motion. They can handle very high axis counts while still managing the overall machine logic.

One of the drawbacks to PLCs has always been that the common PLC programming languages like ladder logic aren’t particularly well-suited to motion programming. That said, function block, one of the programming tools developed as part of PLC open and the IEC 61131-3 standard, lets users take advantage of libraries of open-source motion functions such as wind-unwind. The new approach makes it possible to replace programming with configuring video point-and-click interfaces.

Programmable Automation Controllers
Integrated control solutions continue the trend toward ease of use. Loosely classed as programmable automation controllers (PACs), these devices combine multiple functions in a single piece of hardware. They are typically built around PLCs with high-performance processors and large amounts of memory that enable them to support multiple disparate operations simultaneously “Pretty much everything is baked into one environment so there is no separate motion controller, there is no separate robotics controller, there is no separate safety system, there is no separate PLC [for machine control],” says Corey Morton, Head of Product Management for B&R Industrial Automation (Roswell, GA). “They’re all in one platform, even the HMI.”

Here, too, there is a focus on making as much of the set up as possible configurable rather than requiring programming. “There’s engineering time associated with any programming that the user has to do, so the goal with any approach¾whether it is separate motion controllers or integrated¾is to make as much configurable as possible, especially the general set up,” says Morton. “It’s a little difficult to do that for application-specific functions because sometimes that involves the customer’s IP. From that standpoint, they need the freedom to be able to do whatever they want which means programming.” Many of these integrated packages enable the user to perform both configuration and programming in the same environment.

These integrated units are just as applicable to three-axis DNA sequencer as to a full CNC machine. At this point, other factors would come into play, however, such as cost and footprint. We will discuss these considerations more fully in a later section.

PLCs with Stand-Alone Motion Controllers For the most demanding applications such as those requiring submicron precision or control loops executed across multiple axes with stub milliseconds scan rates, the class a combination of PLC and standalone motion controller may still be the best fit. These involve purpose-designed hardware. They may have special features such as the ability to accept G-code, the language used to program CNC machines. “The controller would take in the G code commands, then break them down into coordinated kinematic systems in order to perform unique and complex operations,” says Darrell Paul, Marketing Manager for Robotics and Motion Control at Omron Automation (Hoffman Estates, Illinois).

Standalone motion controllers also offer enhanced functionality such as the ability to manage high-axis-count robots. An integrated controller with robotic capabilities might be programmed to manage kinematic systems with three or four axes, but only for certain operations. In contrast, a highly functional standalone controller could support more sophisticated schemes such as making multiple fixed-axis kinematics operate as a single kinematic system. This approach could be used for a single robotic work cell incorporating multiple robots performing multiple operations, such as one vision-guided robots serving up parts to a second robot that executes several different tasks on that part.

Kinematics also can be embedded into one another, for example, to operate a robot arm that needs to combine large-scale, high-speed movement with very fine, high-speed positioning.

The trade-offs for this performance include complexity, programming time, and cost.

Soft Motion
For applications that require a high degree of flexibility in performance, the best solution may be customized code running on high-performance, industrially hardened PCs. PC-based motion, or soft motion, combine the cost and sourcing advantages of commodity hardware with software customized to solve complex motion problems.

The processors used in PLCs and motion controllers tend to be purpose-built DSPs and ASICs. As such, they have much longer product upgrade cycles. Soft motion algorithms can run on any COTS PC with sufficient processing power, clock speed, and memory. The commodity approach enables soft-motion systems to take advantage of rapid product upgrade cycles propelled by the consumer market. Functionality is driven by software, which is faster, easier, and less expensive to develop than custom hardware.

The fast upgrade cycles for PCs cut both ways, however. PLC, drive, and motion-controller vendors make substantial investments in their products. They commit to supporting the technology for 20 and 30 years. In contrast, the PC purchased today may be unavailable in six months, let alone in six years if the motherboard of the shop’s CNC machine fails.

Understanding the Application
It’s not enough to know general controller types. To effectively specify an encoder, users need to address the specific needs of the project. “It’s always application first,” says Miller. What are you trying to accomplish?

A primary consideration is the number of types of systems that need to be controlled. Beyond primary machine logic, does the system involve systems for specific operations such as Motion control, robotics, and safety? At what performance level do they need to operate and interact? “Is the customer looking for more of a modular/cellular-based manufacturing process where they have multiple cells that are all locally controlled and just need to be linked together? Or do they need one central controller because they want very, very tight coordination across large spans of motion axes and all the different systems that are feeding into it?” Paul asks. The tightly controlled scenario might call for a PAC, whereas the multi-celled model could use a variety of technologies.

Speed
The core function of the controller is to process algorithms and manage I/O, for example, analyzing encoder feedback and using it to generate path commands to deliver the load to the intended position on time. It’s essential that the controller is fast enough to accomplish its processing and deliver output in a timely fashion. As a result, the cycle time of the process is one of the most important details to determine when specifying a controller.

Consider a machine designed to process 300 parts per minute. That corresponds to 200 ms a cycle time of 200 ms, within which all process steps need to occur, including any idle time between operations. “You need to get familiar with the smallest timeframes that are critical to the operation, and make sure the equipment selected is capable of processing and sharing data inadequate timeframes,” says Hull. Consider a motion system that uses machine vision feedback. If the cycle time from image acquisition until the window closes for a motion correction is 30 ms, then all process steps must take place within that interval. “The camera must be able to take a picture in 5 mSec, process the data in 5mSec, and transmit in 5 Msec, allowing the motion controller to make a correction if necessary in the remaining time,” says Hull. “These details are sometimes hard to nail down exactly at the beginning of a project, but a reasonable performance margin must be determined.”

The strategy is to identify the fastest moves, the quickest cam profile segments, then use that data to choose a controller that can deliver that level performance. “Sometimes when a customer application involves extremely fast coordinated motion, we will advise them to get a controller with a larger CPU just because of the need for speed, not necessarily that they need the capacity of that CPU,” says Paul.

Number of Axes and I/O Points
The controller CPU needs to be sized to handle the sheer volume of operations to ensure that it can work within the allotted cycle time. It’s important to consider the number of axes and I/O points when specifying a device.

Communications Protocols
Communications can heavily influence the top-level performance of the system. Not all communications protocols are created equal, and not all controllers support all protocols. Care should be taken to select a protocol that operates at a speed that complements application cycle times. Some controllers act as data loggers or edge gateway devices to aggregate data, perform some preprocessing, and port it to the cloud. Confirm that the controller CPU can support these additional operations and at the speed required.

Safety and Security
Safety has become a topic of increasing importance over the past decade, both because of its ability to protect operators and its effect on optimizing OEE and streamlining operations. Safety implementations vary. Some systems use safety-rated drives with safety PLCs. Others are built around PACs that incorporate safety control functions as part of their features. In either case, the controller will need to meet target specifications for parameters like latency, loop education execution rate, and communications requirements.

System-Level Considerations
PACs offer a number of advantages, including ease-of-use but sometimes the best solution is multiple solutions. Consider an application based on the use of three independent smart drives. If one of the axes is mission-critical and must remain operational even if the rest of the machine goes down, then the control systems will need to be decoupled. “If you have a completely integrated solution and the PLC that is the brains of the solution goes down, then you're probably not going to be able to run anything,” says Morton. “If you have an architecture was smart drives that can potentially run on their own and standalone mode¾maybe they’re controlled in that case through discrete inputs and outputs on the drive itself¾maybe that’s the architecture that’s going to give you that type of fault tolerance.”

Using a PAC for one part of the machine in combination with smart drives or selected axes can actually deliver a more effective overall solution. Offloading those axes from the central controller can decrease the computational burden. That can enable a less expensive controller to do the job while maintaining performance.

The key point to remember is that while budget is important, it should not completely drive the decision. It might be tempting to use a low-end PLC to control a four axes system because of the cost savings. If the PLC can meet the performance specifications, however, the system will never execute the application effectively.

OEMs have a wide variety of control options from which to choose. Strategies for success considering the application is whole before beginning the selection process. Proper selection can be a nuanced process. Timing, as the saying goes, is everything when it comes to controllers but there are seemingly simple and easy to overlook aspects such as communications incompatibilities and security that can ultimately derail a project. To arrive at the best solution, listen to the experts. “The single biggest pitfall in selecting an encoder is not fully understanding the machine requirements, and later struggling to meet specifications due to performance constraints or a discovered incompatibilities or missing features,” says Hull. “The workaround strategies take more time to develop and test. Instead, work closely with your supplier. They should be a good partner to ensure success.”