Skip to content

Motion Profile

Pascal Roobrouck edited this page Sep 28, 2022 · 8 revisions

The motion instructions in the G-Code cannot be executed just like that, for the simple reason that they assume an infinite acceleration/deceleration. A real physical machine only has finite maximum acceleration, deceleration and speeds.
Thus the job of the controller is to find the motion that is closest to the G-Code motion, but within the limitations of the machine.

Machine limitations are maximum acceleration, deceleration and speed. When exceeding these, stepper-motors may loose or skip steps, a fatal malfunction in an open-loop design.

Moovr can use both second-order (constant acceleration - T-profile) or third-order (constant jerk - S-profile) speed profile : constant jerk (mm/s^3), linear acceleration/deceleration (mm/s^2), second order speed (mm/s), third order distance (mm). This profile is a good compromise:

  • smooth movement
  • close to fastest possible movement
  • not too complex math, most of the calculations can be prepared out of the real-time part. The real-time part is feasible on the Cortex M4F

Simplified, the big difference between T- and S-profile is that a T-profile has sudden changes in acceleration, whereas in S-profile these changes are continuous. F = m * a and so acceleration is related to the forces on the machine. A sudden change in acceleration, means shock to the machine. A simple analogy can be found in old (electro-mechanical) elevators, which have a shock at start and stop, versus modern elevators which have smooth accelerations.

However, the S-profile also has some limitations: As each change of direction implicitely means an accelleration, the machine needs to come to a stop at each turn of the path. Also when switching from linear moves to helical (and back), the machine has to come to a stop. When running GCode that consists of many short segments, there is no 'time' to speed up, as the machine needs to stop at each junction. In this scenario, Moovr can fall back to T-profile, which allows some sudden acceleration changes, and as a result can take turns with non zero-speeds. The minimum length for S-profile can be set in the machine settings, and allows for all T-, all S- or mixed T- and S-profile operation.

Trajectory and Speed Calculations

Trajectories and Speed-profiles are prepared in a non-real-time part of the code. These calculations are done in double precision when needed to ensure minimizing rounding errors, maximizing accuracy. Then the execution of the motion is done by real-time parts and here the math is single precision floating point, as this is supported in hardware.

Is single-precision floating-point providing enough accuracy ?

Imagine a 3000 mm long machine, with 0.01mm resolution. So this axis can have 300 000 'positions' or roughly 18 bits. A single-precision float has 24-bits of resolution, so 6 bits of 'spare' resolution on top of our machine's needs.