Motion Control is a big topic. Motion Control refers to the use of servo (and stepper) motors in your system. A servo requires a motor and a position feedback device such as a resolver or an encoder, and it controls the position of the motor using a feedback control system.
Motion Control systems are not new, but they have a parallel lineage to PLCs. Since around 2000 we’ve seen more and more convergence of Motion Control and PLC systems, but they are still separately packaged modules within the system. In TwinCAT 3 they are separately licensed modules. The PLC system is licensed as TwinCAT PLC, and the motion control system is called TwinCAT NC. The latter is licensed depending on how many “axes” (i.e. servo motors) your system needs. The base package is 10 axes, and you can add more axes for more money.
The “NC” in TwinCAT NC means “numerical control”. It’s the same NC as “CNC machines”, which can mill (or cut) away material from a block of steel with accuracies better than a thousandth of an inch. In fact Beckhoff originally got its start in motion control systems, so TwinCAT 3 includes one of the better motion controller systems available today.
The TwinCAT NC module is just a basic motion controller that gives you “point to point” motion. That is, each axis is controlled independently. If you need your axes to work in a co-ordinated way, such as in a 3-axis CNC mill where you need to follow a complex path in 3 dimensions, then you need “interpolated motion”. TwinCAT 3 offers this as an add-on to TwinCAT NC, called “TwinCAT NC I”. This add-on actually includes a built-in G-code interpreter. G-code is the language that CNC mills (and FDM-type 3D printers) use to instruct the motion controller on the path to follow to create a finished part.
Industrial robots, such as those from ABB, Fanuc, Motoman, etc., are actually controlled by interpolated motion controllers internally. It’s no co-incidence that Fanuc is both a leading supplier of industrial robots and CNC mill controllers. The technology is similar. In fact TwinCAT 3 does support kinematics packages for industrial robots, and you can even purchase a Codian Delta Robot through Beckhoff and use TwinCAT NC I with a delta robot kinematics package to control
the robot directly from TwinCAT 3.
Since motion controllers have evolved from their origins in CNC milling and industrial robots, the sequential nature of their programming (in the form of G-code or proprietary robot programming languages) has never fit well with ladder logic programming, and gives rise to what I call the Ladder Logic/Motion Controller Impedance Mismatch.
In PLC programming it’s typical to think in terms of discrete outputs. Turning on an output can do many things, such as turning on a pneumatic valve to apply air pressure to a cylinder, turning on a motor to run a saw or a pump, or turning on a heater to control the temperature of a fluid. In all of these cases you can think of a discrete output meaning “try to do X.” For instance, “try to extend this cylinder,” or “try to start motor,” or “try to increase temperature.” We normally have feedback mechanism like a proximity switch, or a level or temperature sensor to tell us that our action succeeded. This try/confirm idea naturally gives rise to ladder logic programming patterns like the Five Rung Logic Blockand the Step
Pattern. Implicit in the Five Rung logic is the idea of “when is it safe to perform (and continue performing) this action?”
Motion controllers, on the other hand, are designed to follow a strict set of sequential instructions, with little consideration of how to recover when things go wrong. Consider the idea of a weld robot. It waits for a part to be loaded, follows a path (series of points) to move the weld tool into position, clamps the welding tool, fires the welder, unclamps, and follows another path back to the home position. The linear nature of the sequence makes this particularly easy to program, but what if someone opens the gate and removes the part while the robot is moving in towards the part? The robot can’t continue the program because the part is no longer there. However, the check for part presence would have been done at the beginning of the program. That means you need to insert a second part presence check right before you clamp the welder, and if it’s not present then skip over the weld and jump to the move-out sequence. Unfortunately this means the robot recovers by continuing in towards the missing part. The “right” thing would be to move back out immediately, but programming a way for the robot to find its way back away from the part without crashing into an obstacle can be quite difficult and complicated. That’s why many industrial robots are tended to by operators who frequently have to enter the cell with a teach pendant and recover by manually “jogging” the robot safely around obstacles back to a known home position.
If the motion was done by a PLC controlling a sequence of air cylinders, the recovery logic would be comparatively simple: just retract them in the right sequence. Typically your “safety” rung in your Five Rung logic block already contains the logic about when it’s “safe” to retract those cylinders without crashing, so if you give them all the trigger signal to retract, they’ll automatically retract in the right order.
When a new control system programmer comes out of school, they always want to program the industrial robots because they look so cool. However, I always tell them, “the robots are stupid but PLCs make them smart.” For a PLC to make a robot smart, it needs to know the current robot (or motion controller) position. If you don’t know where the robot is, how can you program a smart recovery path? Unfortunately, getting the current robot position out of the robot and into the PLC can be difficult at best, and nearly impossible with some older robot controllers. Thankfully, with TwinCAT 3, the motion controller and the PLC are operating in the same runtime, so the PLC automatically has access to all motion controller information, which makes your job a lot easier.