Evolution in motion: the machine automation controller

The machine automation controller (MAC) is the latest stage in the evolution of the automation controller, meeting machine control needs more effectively than previous controller solutions.

To paraphrase Albert Einstein, the opportunity for development is directly related to the potential for value. This is particularly relevant to technological development, where market forces establish need and value, and then science and engineering are applied to meet them.

Look at the use of machine control hardware for automation. During the past 50 years there has been a powerful and dramatic development of controllers: distributed control systems (DCSs), programmable logic controllers (PLCs), industrial PCs (IPCs) and programmable automation controllers (PACs) (Figure 1).

Figure 1: Controller historical development.

The explosion of industrial applications continues to challenge the functionality of those controllers, fostering further innovation. The need to combine the capabilities of traditional process/discrete industrial control has led to adaptations or extensions of existing technology. The efforts to evolve resulted in underperforming machine automation due to limitations in architecture and a lack of cross-discipline expertise.

Today we see the emergence of a new controller type: a machine automation controller (MAC). An MAC resolves the integration of control technologies without sacrificing performance. Only after painstaking development from the ground up - specifically for high-speed, multiaxis motion control, vision and logic - has the MAC emerged. Let’s revisit how this point was reached.

The industrial controls market split into two distinct segments: process - where pressure, temperature and flow were paramount; and discrete - where sequencing, count and timing were the key metrics. PLCs dominated the discrete market, while DCSs led the process market. Customers were well-served.

As machinery advanced, technologies converged and the PAC was developed to address the overlapping of process and discrete markets. The PAC incorporated the fundamental capabilities of a small DCS and a PLC with the addition of low axis-count motion control. The PACs provided redundant processors, single database, function block language, high speed logic, component architecture and online programming (Figure 2).

While PACs cost less than traditional distributed control systems, and also integrate motion and logic into a single controller, they encounter limitations when applied to high-speed motion with multiple axes. Motion control continued to be implemented with a separate network and performance issues were tackled by adding processors. This meant additional code for controller sequencing, which resulted in inefficiencies in system synchronisation. Inevitably, machine performance was compromised.

Figure 2: PACs, PLCs, motion controllers and MACs.

The emergence of the MAC

Manufacturing demands performance in terms of throughput, yield and uptime: the overall equipment efficiency (OEE) model. Moreover, manufacturers are always pushing for greater accuracy and lower cost while maintaining quality and safety. These factors are the key drivers.

Increasingly, manufacturing also requires moving product automatically during setup or production. This calls for a system that centres on motion and relies on it to be fast and accurate. If a controller has not been designed around motion, it may have inherent architectural barriers to performance when used to increase OEE. Consequently, machine manufacturers are forced to coordinate and synchronise the controller across technological boundaries such as motion, vision, logic and safety.

System synchronisation in such a system occurs when the user application program coordinates with the motion scheduler, the network servo drives, and ultimately controls the motor shafts. With each motor shaft synchronised with each other, what is true for two axes is true for nine, 17 or even 64 axes.

There are many 8-axis and 16-axis controllers on the market, but if there is a need to expand the coordination of motion beyond that number of axes, another motion module is typically added. However, this is where many controllers fall short, because the application requires synchronisation across the expansion modules, through to the network, and back to the application program into the motion scheduler.

Figure 3: Problem - control cycle time not fast enough to approximate the desired profile.

To best approximate the intended motion profile, the controller must be deterministic to accurately coordinate all axes in the system. All this points back to the main driver: in order to increase throughput, the system requires the axes to remain synchronised with great repeatability to guarantee higher performance of throughput, yield and uptime (see Figures 3, 4 and 5).

Figure 4: Attempted solution - increase profile generation cycle time, but network or backplane delays cause loss of system synchronisation resulting in profile execution delays.

In achieving this, lower yields will result and the system may require shutdown to make adjustments. Uptime is not necessarily just a factor of the equipment itself; it’s also a factor of the production process. If motion is not accurately controlled to match the process, when speeds are increased the result is bad parts as the machine goes slightly out of control. This clearly impacts uptime because upstream and downstream processes need to be readjusted as well.

Figure 5: MAC solution - faster cycle times with system synchronisation allows for closer profile execution without delay.

Enter a new category of controller called a machine automation controller, where the most important attribute is motion performance. A true MAC can handle applications that require a high level of synchronisation and determinism, as it integrates multiple technologies stretching across the boundaries of motion, vision, logic and I/O without sacrificing performance.

An MAC features an advanced real-time scheduler to manage motion, network and the user application updates at the same time to ensure perfect synchronisation. An MAC such as Omron Industrial Automation’s NJ Series is capable of updating all three in the same scan.

Convergence

The revolutionary step is to purposely design an MAC to integrate multiple specialised controllers with exacting system synchronisation to deliver high performance throughput on a single controller.

Consider the MAC advantages in a simple application such as a vision guided, Cartesian pick-and-place robot (Figure 6).

There are two parts: the setup and actual production. The coordinate system of the camera must match with the coordinate system of the Cartesian robot. To get the camera data to the controller in a coherent form, a lot of time is spent developing the protocol. Previously, this might have taken the combined efforts of an articulated-arm robot manufacturer, a third-party vision system engineer and a PLC vendor. There could be three different systems from three different companies using three different technologies. At this point there would be three engineers in a room, taking them weeks to figure out how the systems can communicate with each other for commissioning. By design, an MAC allows these technologies to converge together so protocol development can be completed in a matter of hours.

Figure 6: Application - a vision-guided Cartesian pick-and-place robot.

On the performance side, the use of a real-time network enables the passing of vision data to the motion system without losing a scan. This is only possible if vision and motion are on the same network.

As another challenge, machine builders want to adjust servo parameters on the fly. This added functionality can create performance loss as the whole system gets overloaded with a high number of axes moving a high speed with full synchronisation. In the absence of an MAC, achieving this with non-MAC controllers require additional CPUs.

The new performance benchmark

Today’s benchmark to qualify for the MAC category is processing 32 axes and updating in one millisecond. There were many earlier attempts to create a multidisciplinary controller, PACs being the most prominent. There were attempts to apply them to process control, cell control and machine control; but the PAC had to have an extensive operating system. Also, for truly high-speed motion control, the controller and configuration required many CPUs, since the performance of motion control will drop as the number of axes increases.

Where MACs are best used

The market for the MAC is where the motion market, the vision market and the PLC market have commonality.

Companies have different types of controls and control systems. In their higher-end controls, they may have a deep need for higher-end performance: motion, vision, functional safety and I/O together. But they also want to program their lower-level machines in the same language. They want to re-use the same libraries in scalable systems and not develop twice. Code re-use helps amortise the engineering investment over a wide range of projects into the future.

Imagine yoghurt packs travelling on a conveyor. They get inspected, checked, picked up by a series of delta robots, put in boxes, lined up in cartons and so forth. Before the MAC, a typical line like this would have many controllers that would have to be coordinated - the vision controller, the robot controller, the motion controller and, on top, the PLC that sequenced all of them. This is a typical application where customers have been asking for one controller and one software application to know what is happening on the production line from vision inspection to pick-and-place to synchronisation of the robot with the conveyor to packing and palletising at the end of the line. An MAC meets these requirements, streamlining operations by reducing the amount of equipment and integration traditionally required when different systems were cobbled together.

In the packaging industry, machines for packing, wrapping, cartoning and palletising use a certain amount of robot functionality combining vision and motion, and a great amount of axis synchronisation. These represent the successes where early MACs have been applied. Further applications may include intelligent controllers that can handle multiaxis synchronisation at the heart of machine operations. An example of this use is an application involving soft material cutting or 2D cutting - be it wood, plywood, glass, stone or industrial textiles - where a certain amount of path or pattern execution functionality is needed, as well as handling and positioning. It is multiaxis control, but not requiring the extremely high functionality of typical CNC controllers.

Conclusion

“Every great and deep difficulty bears in itself its own solution,” said Niels Bohr, Einstein’s contemporary and peer. “It forces us to change our thinking in order to find it.”

Controller inefficiencies that were exposed by machine innovation caused the new thinking that led to the development of machine automation controllers. Now that MACs have emerged as a revolutionary solution, further machine development incorporating their advances will continue evolving, with motion at the core and with the creation of value as its ultimate work. Today, with MAC, the potential for value is being realised to a higher degree than ever before.

A condensed history of industrial control (1961- 2012) Where we are today could hardly have been imagined in the early 1960s. Consider the following developments that demonstrate how far we’ve advanced in the past five decades: Mechanics gave way to relays, which gave way to microprocessors and low voltage differential signalling and expansive power distribution, which is now harnessed for inverter, servo and robot control. On/off and open/closed status moved first to mechanical time, then electronic time, then distributed electronic time, and now to GPS time. Visible gears became virtual elements that are defined as electronic axes. Information has gone from pen and paper to an iPad displaying a SQL database query pulled from a server in the cloud. Custom became proprietary; proprietary became open. Communication media and connections overcame physical barriers: Hardwired copper >> bus systems >> point-to-point serial ports >> multiport networks >> digital networks >> gigabit speeds on fibre >> wireless industrial control architectures were initially distributed, then centralised, then distributed over digital networks, then highly distributed.