RealTime Software Architecture

The biggest challenge in a motion controller is to have the timings of all motors correct, independent of the load of the processor. This load may vary a lot, eg when one or all axis are moving, when gCode is being interpreted, or when manual overrides change the feedrates, and the speed profiles need to be recalculated.

The approach in Moovr is to keep the real-time part in a separate thread and really minimal. All other, non-real-time stuff is executed in a second thread.

The real-time thread is implemented in an interrupt routine of the Programmable Interval Timer. This is a hardware peripheral available in many microcontrollers, and intended to trigger interrupts at regular time intervals. But it is also possible to change the interval time, and as such trigger interrupts at **irregular **time intervals : after every timer interrupt, the delay until the next interrupt is loaded in the timer.

The non-real-time thread prepares all the changes for the motor signals, and all timings between them, and stores this in a buffer. The real-time thread will output the signal, and reload the timer with the delay until the next signal change.

It is up to the non-real-time thread to ensure that the real-time never underruns the buffer. We typically have 10 or 20 ms of steps in this buffer. The more, the longer the non-real-time thread can do other things without filling the buffer. But also the longer the machine responds to changes such as feed-hold, overriders, etc.