With the rise of programmable automation controllers (PACs), motion controllers are increasingly difficult to distinguish from PLCs. Until recently, motion controllers, programmable logic controllers (PLCs), and industrial PCs were distinct components in a control system with their own defined functions.
Programmers are developing custom applications on PCs to create decentralised control schemes that command a wide array of sub-control devices, including motion controllers, drives and vision systems. The trend of merging previously separate control elements into a PAC can add complexity to the job of designing a new machine or expanding the functionality of an existing one. However, with an understanding of the different control architectures and armed with the right questions, designers can identify control schemes that best match their application.
PACs provide multi-axis motion trajectories over a bus, for example EtherCAT, while drives close the local PID loop around the motor. This architecture reaps all the benefits of standarised programming with the entire system programmed with IEC 61131-3 and within a singular development environment. Drives can now be interrogated by the PAC to ascertain the failure mode, and rather than needing to open up a machine to gain access to data either through manual multimeter readings or direct connection to sub devices, all the necessary information can be reached by connecting to a single PAC; this has the benefit of reducing and simplifying maintenance.
The selection of a bus system that offers flexibility and longevity is important. For example, the Parker Automation Controller uses EtherCAT as its main field bus, but also offers support for EtherNet/IP, OPC client/server, Modbus TCP, PROFINET, and PROFIBUS, ensuring long-term viability and compatibility with the most popular industrial devices in use now and in the coming years.
In response to the demand for more connectivity options, today’s motion controllers increasingly offer support for multiple communication protocols. For example, Parker’s PAC controller provides EtherCAT communication for real-time motion, I/O, and third-party device connectivity as well as EtherNet/IP, PROFINET, and an OPC Server for machine to machine and plant level communications.
The Parker Automation Controller provides the ability for users to develop their own drivers to connect to unique devices using ASCII. Like a PC, the Parker Automation Controller has visualisation capabilities built in, allowing the user to develop a complete application using Parker Automation Manager that incorporates programming the logic and the human machine interface all in one software suite.
After understanding each system architecture and its pluses and minuses, weighing up a variety of considerations to avoid ending up with a less-than-optimal motion control solution is critical. Equipped with the right questions before commencing the specification process will help the designer avoid making the wrong choices.
Considering how the application might evolve of the next two or so decades is important; giving due consideration to what new functionality and subsystems are likely to be required. The solutions opted for will need to have the flexibility to allow the integration of new devices and subsystems as readily and easily as possible. Another consideration is whether the system will require a centralised, deterministic control scheme. This is common in industrial applications where a single PAC is in control of an entire system. Alternatively, does the design require a combination of multiple, decentralised smart devices in addition to motion control?
The choice of communication protocols is large, and it is important to select one that will work effectively for a system and that is also proven, in wide use, and proliferating throughout the marketplace.
Space constraints are an increasingly important aspect of many new designs and need to be factored in when making component choices. The use of Ethernet based bus systems allow transmission of data over extended distances so equipment location choices are much greater. Conversely, traditional motion controllers are limited by the quality of digital and analog signals and therefore have shorter ranges and hence can lead to issues of space due to limited locations in the correct proximity.
Many organisations are reluctant to invest in the acquisition of new skills and subsequently external services may be used to maintain machines. The choice of programming language is critical in determining how quickly an organisation or maintenance team can diagnose, change, and develop an application.
Designers that don’t invest the time to assess all aspects of a project and determine the best control scheme and components to adopt may have to face potentially serious consequences at some point in the future; it is important to know and avoid some common design mistakes. For example, when a controller is selected with insufficient regard for the application, it constrains the designer’s choices, leading to potentially longer and more costly development cycles. The controller is often selected first when the designer either defaults to a controller he or she is familiar with or is drawn to a controller which incorporates all the latest features and functionality. This can force the designer into using components that may not be ideal for the application but that work with the controller selected. As a result, he or she may need to find inefficient and time consuming work-arounds to get a system to operate correctly. Similar problems can arise when a designer doesn’t take the time to understand all that the application entails.
When new functionality requirements emerge, the wrong controller can mean greater 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 with limited ability to accommodate new devices or functionality – for example, a traditional controller based on I/O.
Selecting a poorly suited controller for a given application for cost reasons or failing to plan for future necessary expansions of an application most frequently leads to a less-than-optimal return on investment. Choosing 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 enable the 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. 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, requiring significant development time and resources.
The ability to connect to other machines on the factory floor and to integrate internal drives are important considerations of machine design and controller selection.
All too often designers are pushed to develop the least expensive solution that will serve the immediate application hand. Asking the right questions and answering them comprehensively is the best way to ensure that a new motion control system can continue to evolve along with the application’s changing requirements and continue to provide a return on investment well into the future.