Historically, motion controllers, programmable logic controllers (PLCs), and industrial PCs were separate components in a control system with clearly defined functions. With the rise of programmable automation controllers (PACs), motion controllers are increasingly difficult to distinguish from PLCs. Programmers are building custom applications on PCs to create decentralised control schemes that command a wide array of sub-control devices, including motion controllers, drives, vision systems, etc. The trend of merging traditionally separate control components can add confusion and complexity to the task of designing a new machine or expanding the functionality of an existing one. Luckily, with a bit of knowledge of the different control architectures and knowing the right questions to ask, designers can quickly identify which control scheme will be best for their application.
Programmable logic controllers: Essentially, a PLC is a ruggedised control device made up of a microprocessor, memory and a variety of peripherals. PLCs typically use IEC 61131-3, an industry standardised set of programming languages, including Ladder Diagram. Ladder logic, a language that reads the same as the electrical diagrams maintenance crews are already familiar with, makes the PLC a popular choice. Traditional PLCs typically rely on peripheral devices, such as smart drives and standalone motion controllers to provide advanced functionality. A potential drawback of this motion control architecture is the need to maintain separate programs for each device. Smart drives and standalone motion controllers often use proprietary languages, canceling out the benefit of using an IEC 61131-3 PLC in the first place.
Industrial PCs: Using an industrial PC increases flexibility, giving users the freedom to communicate to any device using either pre-built APIs or by writing their own communication drivers. This freedom leads to the creation of novel applications using smart subsystems that may not have been intended or initially designed to work together. Standalone motion controllers, in the form of smart drives or multi-axis controllers are examples of smart subsystems. Motion controller manufacturers typically provide an API that allows the developer to send motion commands to the controller— limiting the need to learn a full, separate language. Beyond increased flexibility, these applications have several benefits over traditional PLC systems. The HMI (human machine interface) is built right into the control application itself, reducing the need for additional devices for visualisation. In addition, a single programming language can be used to control all subsystems. This single application can also be a major downfall as the machine ages.
Motion controllers: It offers designers highly specialised functionality for controlling and coordinating the movement of motors within a machine. A range of form factors are available as motion control providers have developed solutions based on smart drives, PCI cards, Ethernet and just about every fieldbus ever created. Centralised or distributed solutions offer machine designers nearly endless possibilities for crafting a system that best fits their needs in terms of performance, size and cost. In general, motion controllers rely on a proprietary language that is tailored to fit motion commands.
Programmable Automation Controllers: PACs are the merging of PLCs, PCs, and motion controllers into a single device. Rather than requiring a separate standalone motion controller, PACs provide multi-axis motion trajectories over a bus such as EtherCAT—while drives close the local PID loop around the motor. This architecture not only allows the entire system to be programmed with IEC 61131-3, but also within a singular development environment—reaping all the benefits of standardised programming. Maintenance is significantly reduced as drives can now be queried by the PAC to determine the failure mode. Rather than needing to open up a machine to gain access to data either through manual multimeter readings or direct connection to subdevices, all the information can be accessed by connecting to a single PAC. When choosing a PAC, it is important to select a bus system that will allow flexibility when choosing devices as well as withstand the test of time. For example, the Parker Automation Controller uses EtherCAT as its main fieldbus and also offers support for EtherNet/IP, OPC client/server, Modbus TCP, PROFINET, and PROFIBUS, ensuring longevity and compatibility with the most popular industrial devices now and in the future.
Universal application questions
After understanding each system architecture and their pros and cons, it’s critical to weigh a variety of considerations to avoid ending up with a less-than-optimal motion control solution. Armed with the right questions to ask before beginning the specification process, the designer can avoid making the wrong control choice:
How is the application likely to evolve over the next 20–25 years? Consider what new functionality/subsystems are likely to be required/desired. Take the time to assess whether the solutions you’re considering have the flexibility to allow integrating new devices/subsystems readily.
Will the system require centralised, deterministic control scheme? This is common in industrial applications where a single PAC is in control of an entire system. Or does the design require a combination of multiple, decentralised smart devices, such as optical lab instruments, in addition to motion control?
What communication protocols offer the greatest flexibility and longevity? There are so many choices. It is important not only to select a bus that works best for your system (for example, EtherCAT is best for high-speed motion control), but also a bus that is proven, widely used, and growing in installation.
How will space constraints dictate system architecture and component choices? Must the system be compact enough to sit on a benchtop or can it span many meters? For instance, Ethernet-based bus systems can transmit data over extended distances, whereas traditional motion controllers are limited by the quality of digital and analog signals and are limited to smaller ranges.
What existing integration and programming resources are available? Many organisations are reluctant to take the time to acquire a new skill set and third-party services may be used in the future to maintain a machine. The choice of programming language is critical in determining how quickly an organization or maintenance crew can diagnose, change, and develop an application.
Common design errors
Designers that don’t take the time to determine the best control scheme or choose components too quickly without asking these critical questions have the potential for serious consequences further down the road. It is important to know and avoid these common design mistakes:
The tail wagging the dog: When a controller is selected first, with insufficient regard for the application, it constrains the designer’s choices, leading to longer and more expensive development cycles. The controller is often selected first when the designer either defaults to a controller he or she is familiar with or “falls in love” with a controller gussied up with all the latest bells and whistles. This forces the designer to use components that may not be ideal for the application but that work with the controller selected. As a result, the designer may need to find workarounds to get a system to operate correctly, increasing development time. Similar problems can arise when a designer doesn’t take the time to understand all that the application entails.
No place to grow: When new functionality requirements emerge, the wrong controller can mean great difficulty in expanding or extending the system. Without careful consideration of how a motion control system is likely to evolve over its lifetime, it’s far too easy to select a controller (such as a traditional controller based on I/O) with limited ability to accommodate new devices or functionality.
Penny wise, pound foolish: Selecting an inadequate controller for a given application to save a little money now or failing to plan for future necessary expansions of an application all but ensures a less-than-optimal return on investment. Selecting the wrong controller in the early stages of system development will demand additional design time and could force the designer to employ less efficient components to allow the poorly chosen controller to work. As the machine matures and requires maintenance, it may be difficult or impossible to keep it running, especially if the
programming language used was proprietary or no longer commonly used, especially if the original designer has moved on to another organization. If expansion is required to add a feature or device to extend the system’s lifespan and usability but the control bus used is no longer available, the system may have to be redesigned from scratch instead, costing significant development time and resources. ☐