Machine builders often use one centrally located controller to run multiple tasks. Although most controllers housing a single processor can provide multitasking routines, they only operate on one task at a time. Thus, multitasking does not mean data are handled simultaneously for numerous tasks. Data usually pass between a main task and others, or directly between tasks, where the main task coordinates or controls their activities.
A limiting factor is the controller’s single CPU. It normally requires one or more clock cycles to execute operating instructions on one piece of data. High-end CPUs and DSPs can run a little faster by executing memory fetches and read/write instructions in the same processor clock cycle. But they also work on only one piece of data at a time.
More than one CPU is needed to run simultaneous multitasking. However, when only one processor is available, it must handle multiple tasks in time slices. The CPU divides processing time between individual tasks, switching from one task to the next until all have received a piece of the processing time. Then it returns to the first task to repeat the procedure. Even controllers that execute multiple programs, such as those for handling I/O, user interfaces, and motion control, divide the programs into basic tasks, but do not process them simultaneously.
Many different schemes are used to define the amount of time allocated to each task and the conditions for switching between these tasks. In most cases, the choice depends upon the specific application. In typical real-time control systems, however, critical tasks such as servoloop updates occur more frequently than user interface tasks such as key strokes.
Conventional multitasking methods use multiple programs and conveniently divide machine control into logical programming tasks. But they have a downside. For example, programmers must decide the efficient scheduling of the time slices, because only a finite amount is available. They must then assign priorities to each program and decide how data should flow between programs when switching from one to another.
Such decisions add complexity to programming applications and uncertainty to how and when individual tasks are to be processed. In real-time applications, such uncertainty can result in less than optimum performance. Also, much engineering time is devoted to the details of the multitasker rather than solving the real application problem.
However, a new motion controller has been developed that employs an embedded multitasking operating systems and a single program. The system relieves users from allocating time, priorities, and switching criteria to individual programs. Instead, a multitasking real-time kernel periodically switches between key tasks within the single program. Real-world events generate interrupts providing rapid response to critical external events.
A timer interrupt starts the servoloop update and reads the encoder, I/O, and operator panel. Communications and position capture generate interrupts to the processor, but do not affect the servoloop update process. These controllers contain single user programs written in C or proprietary languages (such as in Mint from Baldor). During each multitasker pass, the next command in the program loads and executes. In an interrupt-driven event, subroutines within the main program define the commanded response to that event.
These motion controllers also support subroutines. They may be used to define a single process such as I/O or user input handling. They may be called numerous times from within the main program or from another subroutine. Hardware inputs can be used to generate interrupts which call a service subroutine. In this way, real-world events receive time-critical handling.
Information for this article was provided by Phil Strong, director of motion controls at Baldor Motors and Drives, 5711 R. S. Boreham Jr. St., Fort Smith, AR 72908.