Software

Top-Level Architecture Diagram

Moovr consist of 4 building blocks:

1. mainController - a state-machine that does the overall control of the machine.
2. Comms - the communications interface towards the GUI.
3. GCode - interpreting GCode, checking the syntax and translating it into GCode state and Motions.
4. Motion - non-real-time and real-time control of the Motion.

The interfaces between the blocks are kept minimalistic and simple:

Comms sends 'command' messages to mainController, mainController sends a status-reporting message back. GCode receives the command messages which are GCode and pushes Motions onto a motion buffer. This bufferLevel is sent back upstream to allow flow-control.

Thanks to simple interfaces, it should be possible to 'upgrade' a block, without changing anything to the others. for example, adding a USB interface, instead of the standard RS-232 Serial, would mean you write a Comms class doing that and delivering the same public interfaces as the current Comms. If you'd like to improve the real-time behaviour with, eg. a more computationally efficient algorithm, you could replace the Motion class.

Porting Moovr to other hardware should also be restricted to Comms and Motion, as the other two modules have no hardware dependencies and should run on any hardware.

Error Handling

Many things can (and will) go wrong in a CNC Controller. Buffers can overflow, underrun, invalid GCode, Comms transmission errors, etc. In general the errors are all handled in 2 levels:

1. For 'fatal' errors, the error is returned to the mainController and will be handled by going into a failsafe state.
2. For 'non-fatal' errors, they are remembered as a 'lastError' in each of the modules, and the status-reporting can report them back to the GUI.

C++ and Object Orientation

Moovr is written in C++, but uses limited c++ specific features:

• Code is encapsulated into Classes
• Constants are defined as 'enum class' enumerations instead of #define statements

Example:

enum class arcPlane : uint8_t { XY, YZ, ZX, nmbrArcPlanes };

• variables of type arcPlane can only be assigned values in the enumeration
• there are no naming conflicts between values for different enumerations
• by adding a nmbrXXXX value at the end of the list, you always know the number of possible values, which is handy in loops or boundary checks
• the values will be stored in an uint8_t

Coding Style

Moovr uses WhiteSmith coding style.