Recently, our regular contributor Steve Meyer spoke to us about the history of motion control and how PC-based controls came about. Here’s what he said.

Traditional motion controllers are the result of decades of slowly evolving electronics hardware and custom software libraries … dedicated to performing motion-control tasks.  PC-based control systems are relatively recent, and their performance is more consistent with state-of-the-art computing. Ironically, while the tools have changed dramatically, the fundamental task is still the same.

Defining the electronics required for motion control comes down to this question:

How fast is fast enough? — in this case, to manage a mechanical (analog) load using digital control?

One example: Controlling a ballscrew-driven motion axis

Controlling a 500-step-per-revolution stepping motor moving a 5:1 leadscrew is not as easy as it appears.

One step is equal to .001 in. of linear motion, and one inch of travel is equal to 2,500 steps. Moving one inch in one second from standing start to stop means the output pulse rate to the stepping motor drive can peak at 5 kHz or higher, depending on the trajectory. Evaluating the commanded versus actual position on every step, and executing control algorithms to adjust on the fly and manage following error at ±0.001 in. requires processor speeds of 100 kHz or higher.

The general problem of managing a single-axis motion task becomes much more complex when multiple axes are considered. For a motion system to play tic-tac-toe, it is possible to create a mechanism with two linear actuators that require no actual coordination between them. In applications like automated storage and retrieval, the axes usually operate sequentially, with no coordination at all.

Upping the ante: Controlling multi-axis systems

For the same two linear axes to draw a circle, the position of the two axes must be updated every clock cycle of the processor … or every time the feedback device or position register changes value … whichever is faster. As speed increases, control-system performance must be orders of magnitude faster in order to correct for overshoot in the axes, or circularity error.

To this day, the standard test for controller performance is to draw a circle at speed.

Control systems 50 years ago were limited in solving math problems quickly enough. Complex architectures of digital signal processors and dedicated microcontrollers were needed. Dedicated I/O for end-of-travel switches and encoder signals were directly coupled to main. Custom code environments were created that were unique to each control system vendor. Users created programs that were compiled directly on the processor — with no operating systems between the user code and the real world.

Over time, the realtime operating systems or RTOSs emerged as an alternative to the dedicated processor architecture. Many customized RTOSs were created, marketed …

… and fell by the wayside as more powerful solutions like Linux became available.

Linux has emerged as the most popular of RTOS due to its shareware approach and massive working group support. Complex CNC and robot applications exist that are inexpensive, robust, and run on very low cost hardware.

PC-based controllers have benefitted from the increasing performance of consumer and mobile computing processors. Today’s PCs have virtually unlimited processing power and can run the most complex motion requirements with standard operating systems managing the hardware resources.

Compared to the dedicated processor approaches of the past, PC-based motion is an economical option to traditional controllers.