Distributed CNC Motion Control
Main > Digital Fabrication > RepLab Tools > Torch Table
Contents
Centralized Motion Control
CNC tools like the CNC Torch Table, HydraFabber, etc. require precision synchronized multi-axis movement. Typically a central controller, such as CoolRAMPS or Steppernug, has the responsibility of generating synchronized step-and-direction commands on three axes, with rates up to about 20,000 pulses per second. As more axes and auxiliary functions are added to the machine, the hardware resources and software coordination required to maintain "hard real time" performance in the single central controller become a bottleneck.
Distributed Motion Control Concept
Distributed motion control, in contrast to centralized control, supports a modular design process in which new functions can be added with additional loosely-coupled processors, rather than being knitted into a single program. Modularity is appropriate for OSE designs.
Communication and OS Latency
Loosely-coupled processors receive commands and report status over communications links. In practice, it is difficult to obtain the low latency and low jitter (latency variation) required to simply pass motion commands in real time, just in time to be executed. Furthermore, low-cost serial communication channels have a limited bandwidth.
Similar latency and jitter issues arise when a complex operating system (such as Linux or Windows) is used to generate multi-axis motion commands through multiple threads or processes.
An overall scheme to achieve precise coordination in the face of variable latency is needed in order to make distributed motion control feasible. In general, this means that commands are prepared a little bit ahead of when they are needed, and stored in a buffer at the receiving end.
In CNC applications, we know the required motion pattern in precise detail before the work cycle begins. In principle, adding buffers and latency simply delays the execution of the pre-programmed path by a small amount. However, it is important to consider every machine behavior which is not pre-programmed, and how it is impacted by latency. For example,
- The operator hits "stop" on a control panel.
- The machine uses a touch probe to locate a feature of the workpiece.
- The operator interactively increases or decreases the cutting speed.
- A fault condition occurs.
Trajectory command distribution
CNC machines are most commonly programmed in G-code. Each "motion" line of a G-code program specifies a coordinated move of the entire machine (3, 4, or more axes), telling it to arrive at a target endpoint following a particular trajectory. Often the trajectory is simply a straight line, but there are standard G-code commands for circles, partial arcs, and helices.
In a distributed system, where (for example) one processor handles X,Y,Z motions of a milling machine frame and a different processor handles a "4th axis" rotary table, it is not enough to simply send the target endpoint information to the rotary-table processor. It must also know when to start moving, how fast to accelerate, and a few other parameters in order to assure its movement is precisely coordinated with the machine frame at every point in the move. The process of breaking up a single G-code motion command into individual axis commands for distribution to loosely-coupled motion processors can become somewhat tricky and bandwidth-intensive. Furthermore, there is no "industry standard" format for these distributed commands that is comparable to G-code itself.
Synchronizing command execution
When commands arrive through a variable-latency buffered communications path, an "execute on arrival" policy won't work. The execution of the commands must be scheduled by some mechanism relying on each receiving processor's local timebase. Furthermore, it is necessary to synchronize the distributed processors continuously so that they do not drift over time. A CNC may take hours to complete the motions required to shape a part, and a drift of less than 100 microseconds between axes could cause a measurable dimensional error in the part.
Relation between CNC and Robotic Control
Robotic control, like CNC machine tool control, involves coordinated movement of several axes. Robot design and programming techniques can be considered in the CNC world, keeping in mind the different emphasis in these two disciplines:
- Robots tend to have large numbers of actuation axes compared to simple machine tools
- Robots tend to have lesser requirements for precision during a move, even if they must arrive precisely at a final position
- Robots often expect feedback from their environment, causing them to dynamically alter trajectories. Unlike "canned" CNC programs, interactive systems do not tolerate latency well.
OSE Implementation
How to implement distributed CNC machine control in accordance with OSE principles...
(Possible techniques, to be expanded)
- ROS (robot operating system) framework [1]
- Shop-wide communications ROS Multimaster
- Orocos realtime software in nodes if appropriate
- Distributed motion commands as PVT (position, velocity, time) messages
- semantics: "starting where you are now, at your current instantaneous velocity, arrive at absolute position P at absolute time T, moving at instantaneous velocity V when you arrive"
- usually implies cubic-spline interpolator
- Lookahead trajectory planner to process G-code (see grbl? LinuxCNC CAM references?)
- convert line and arc G-codes to PVT
- coalesce adjacent commands if accuracy isn't compromised (reduces PVT command rate)
