Controller Software Overview

I got a chance to give some thought to the software for running my mill. Before starting on the hardware I did some simulation to get a feel for what would be required to generate tool paths (the host software). After completing the stepper driver build I wrote a simple routine to generate step signals on the real hardware. My confidence in handling the low-level coding (precise timing, interrupt handling, fast I/O) is quite high. My day job is writing high-level code, so no worries there.

The RepRap project has spawned a number of GCode/CNC/Motion Controller projects. I can't seem to find it now, but some of the earlier versions were criticized for being poorly written, written by someone who has experience writing desktop applications, not microcontroller software. That sounds a lot like me. The use of C++ object-oriented programming, floating point math, and maybe lack of hardware interrupts were cited. OOP is mostly just a way to organize code. It's a nice way to build software components that model the real-world entities. So I plan to use it in my design. I've written my share of software that is wasteful in system resources. I write code with the main intent being speed and maintainability. I often leave performance to the "big iron" of a powerful server. So I do need to be sensitive to the capabilities of a microcontroller. Using C++ instead of "highly optimized C" may cost a little extra memory but I'm not going to be creating and destroying object instances all over the place. The main service routine for the steppers will be pretty tight with integer-only math (addition and subtraction only).

I haven't had much occasion to use UML for software design, but I should be able to pull off a simple diagram of the main components.

Controller
I've used the word controller to refer to the box that holds all the hardware for controlling the stepper motors. Here I'm using it as a software design term, the C in MVC. The controller handles all the messaging between the sub components. This keeps the sub components lighter. You can think of fewer wires between things to get crossed up.

ButtonManager
The ButtonManager handles the input from the 6 direction buttons plus the throttle thumbswitch. InputPin is a button. "Pin" refers to a digital input or output on the microcontroller, also a "line"; it's where you connect wires to it. I'm using a generic name, InputPin since it could be a button to be pressed, a limit/home switch, or any kind of switch-like component. You can ask an InputPin if it is on or off of course, but you can also ask it if it turned on (or off) since the last time you checked (so you don't have to manage the transition state outside InputPin). ButtonManager will act a bit like a radio button set. Only one button is allowed to be on at once. (Not sure about the throttle button yet.) This is important because it frees me from having to manage complex trajectory planning. Imagine pressing the "move left" button until the machine is up to full speed, then (while still holding the first button) press "move forward". The machine would make a 45 degree turn at full speed. This might be jarring. The machine must come to a complete stop before moving in a new direction. This also takes care of the most difficult, press "left" to full speed, then quickly press "right". My host software will address such trajectory planning but I don't want the firmware to be so complex.

LightManager
LightManager takes care of the, wait for it, the lights. Like InputPin, an OutputPin is a pin you can turn things on and off with. So an OutputPin object may turn an LED on and off, set the direction for a stepper motor or tell the motor to take a step. I'll be lighting my arcade buttons with LEDs. So LightManager will turn these lights on and off according to the mode it's in. If the machine is in continuous manual mode, no lights will be on. If it's in in "discreet" mode, the position of the throttle bar will light up one light indicating how far one press of a direction button will move the spindle. And, best of all, in automatic mode (controlled by the host software on the laptop) the lights will flash in pairs like those on a snow plow dump truck or the back of an ambulance. You know.

VectorBuffer
This holds a list of "moves" to be fed to the StepperDriver.

StepperDriver
This class models the stepper driver, of course. It has a current "vector" describing what direction in 3D space to move in, what speed to accelerate to, and if in automatic mode, how many steps to take in that direction.