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.

Version One of Case Complete

The Sanguino is all wired up to the stepper driver board and I've got 2 cables for manual controls connected (16 wires). I connected the throttle controller and ran a test with all three motors spinning at a speed proportional to the throttle position. While the Sanguino will be the final microcontroller, I consider the optoisolator board temporary as well as the 2 Cat-5 cables connecting the manual controls. I intend to mill a nice PCB board with proper connectors on the back panel and secure it to the case properly. Right now the connections are all made internally and cables have zip ties at the rear panel to keep them from being pulled free. The manual controls will be connected with the DB-25 connector that was intended to be used to connect the stepper driver to a "real" computer.

Things are looking a little more crowded in there now. It's mostly wiring taking up the air space. I've got the cover on it now and my workbench is quite a bit neater.

These days my day job has me working almost exclusively on one project, a product that we sell. I used to do a lot of custom projects lasting 6-12 weeks on average. In the middle of a project you got a lot of momentum going. The foundation was laid long ago and you're hammering through each component. Then when the project is done, it's time to start the next. That's when things slow down. It's hard to change gears and start arranging the pieces for the next project. I call this the "New Project Blues".

I just finished about 8 or 9 weeks of electronics work. Now it's time to write some software. That's a pretty big mental shift. Last fall I dashed out the prototype for a tool path "scripting language" along with a 3D preview / animation. I have a simulator of the milling controls that is coded the way I intend to code the firmware on the Sanguino, taking "steps" for each direction in 3D space. So the next step is to build on that to simulate the manual control. The basic idea is to set the "vector" indicating the direction of travel and the target speed and have the firmware interpolate the current speed to the new speed. I'll flesh that out in simulation first, then port it to the Sanguino. I'll need a serial communications protocol to set variables and send commands from the laptop.

Optoisolator and Sanguino Built

After quite a few hours of soldering, I have finished the opto-isolator board assembly. Well, I'll call it v1.0. I hope to make a much nicer one using my mill to cut a proper PCB. I've used a Radio Shack "PCB" that is arranged much like a bread board. Here is my layout design:

I did this in Inkscape. I have the free version of Eagle but don't know how to use it. I've also messed with Fritzing a bit. I went with Inkscape because I know it pretty well and I wasn't really designing a PCB but just trying to figure out how to put it all together. I marked places where I needed to cut the traces and where I would be putting headers and whatnot.

Here it is fully assembled:

I had a lot of confidence in my soldering going into this. I found it a bit more challenging than the boards I had purchased and assembled. I think the through-hole PCBs wick the solder in better. These boards with copper on one side are a little harder to get the solder to attach to. So the back side isn't that pretty. And it sure did a long time to put all the wires in. A tool path generator for milling PCBs will be really sweet. I'll redesign this thing at a later date.

I've been using a Modern Device Bare Bones Board (BBB) Arduino clone for my experimentation up until now. It's a good little board, but I knew I was going to need more pins. And more memory would probably be pretty nice, too. So I sprung for a Sanguino. This thing has 32 I/O pins and 64K of memory.  It's like an aircraft carrier compared to the BBB. I guess that makes the BBB something like a class C frigate or something. I put that together in 2 sessions, maybe a couple hours. I do manage to take my time with this sort of thing. Really I can't believe I can do it at all. Modern Device also makes a little USB to serial converter since the Sanguino doesn't include USB. The BBB doesn't either which is great for an embedded microcontroller, but this will be connected to the computer most of the time.

Anyway, here it is:

I've got the output wires going to a proto board for testing with some LEDs for identifying which Sanguino pins ended up going to which output lines (I deviated from the plans so as to produce the best wire runs.) I uploaded Bitlash to the Sanguino to make it super easy to turn the LEDs on and off.

The next step is to wire in the stepper driver. I've got a simple ribbon cable that I'll just solder directly into the opto PCB. In v2.0 I'll put in some nice inter-connectors. Also I'll wire in the arcade throttle control. Then it's time to write some software!

Manual Controls

CNC is about the computer controlling the movement of the machine, or automatic movement. Essentially programming it to move. The process of machining any given part will usually require multiple operations, or even if just one operation, you have to set it up. You have to mount the stock and position the spindle/cutting tool with respect to the stock. The program to cut the part "thinks" the cutter is in a certain position relative to the stock and you need to put it there.

I have double-ended shafts on my stepper drivers. I intend to remount the handwheels so I can move the machine manually when the system is off. Or do I... I will put the handwheels on. They are special wheels with an embedded quadrature encoder connected to a DRO, or digital readout. But I don't intend to do much of any cranking of these wheels. I think most CNC software packages come with some manual control interface and I could certainly write such a thing for my system. But I don't want to lose out on the ease and speed of using the stepper motors because my computer (laptop) is not nearby and powered up.

I designed this system such that the commands to step the motors comes from an Arduino microcontroller inside the same case as the stepper driver - not from a PC tower computer with keyboard, mouse, and monitor. This means without my laptop connected I still have a "computer" I can write software for and that I can connect with the real world, i.e., connect buttons and other input devices to. With a flip of a switch and a 2 or 3 second pause, I'll be able to start moving the machine around. Sure beats several minutes connecting the computer, booting up, and starting software. I'll be able to do basic machining operations like I do now with the handwheels only faster and with less effort.

Heres a picture of an industrial control unit for a CNC machine:

Many of these look OK, but I'm not buying one and I want something cooler. I've worked with the Arduino before, I built a free-space "joystick" for the computer with an accelerometer. I knew I could connect various common input devices like the Wii Nunchuck or PlayStation controllers. It seems like a joystick would be natural for moving the X/Y table around. Some button for toggling to the Z axis would be fine. The Wii Nunchuck has only 2 buttons. The PS controller has way more than I could use. I think the PS controller has an LED or 2 but I wasn't sure I could control them. The Wii has none. So I'd need some other device for feedback, like what "mode" I am in or something. In any case, with both of these devices I'd have to find someone else's software to control it and possibly deal with voltage level differences and so on. I didn't want to have to struggle with this part of the system. I also didn't want to have to hold the controller.

Then I though about an "old school" PC analog joystick. These have a bunch of buttons and at least 2 potentiometers for joystick position. I could rip out any electronics and easily connect things directly to the Arduino. But still nothing for feedback. I want to be able to walk up to it and know if it's in Z axis mode or X/Y axis mode, for example. Also, I felt the options looked kind of cheap. I wanted something really tough. Like arcade controls.

I attempted to win a couple of eBay auctions for this puppy:

This thing is built like a tank. It's got 4 buttons plus a 4-way "hat switch". That seemed like enough for me. These things sell for over $200 each. The full video game, Blazing Angels, runs over $10K. So not surprisingly, the bidding quickly went over my maximum amount. After losing twice, I thought things through some more. I thought about how I would program a joystick. How would I manage acceleration, for example? What would I do if the stick was far left and then jerked far right? One control I want while running cutting programs is a feed speed override. I could move the joystick forward and back to do this, but it didn't seem quite right. And still no visual feedback for manual settings.

I tooled around some more looking for arcade controls. It seems there's a pretty big market for people making their own arcade machines wrapped around a PC. I found a listing for a switch-based joystick and 6 buttons with LEDs to light them up.

Arcade buttons are pretty darn tough, too, with people pounding on them all day. But the switching joystick was less appropriate than an analog joystick - no proportional control.

Then I found this:

This is a brand new arcade throttle control with full proportional output (potentiometer) that springs back to center and has a thumb button (not pictured). This is perfect for feed speed override and controlling the speed in manual mode. The arcade buttons can then be laid out to control the mode and direction of movement. I figure 4 buttons in cardinal positions to enable direction, a button in the middle to toggle between X/Y and Z, and another button for "nudging". The buttons would light up according to the selection. In "non-nudge" or normal mode, pressing the button on the throttle would make it go and the position of the throttle would change the top speed. In nudge mode, the position of the throttle would change the distance, say 0.5, 1.0, 5.0, 10.0, 15.0 thousands of an inch and each press of the throttle button would move the mill that amount.

This throttle control sells for $90. I got lucky and won it for the opening bid of $9.99 + $10.50 shipping. That's pretty awesome!

It seems many of the arcade buttons with LEDs have LEDs that are 12 volts. I'll be running 5V so I think I'll pick up some "translucent" buttons and add my own lights.