The mini mill motion controller

The last post described the physical setup of the mini mill CNC conversion. Apart from adding motors to the mill, you also need something to control those motors. Most people seem to just get a G540 motor controller from Geckodrive and hook it up to the Mach3 CNC software. This seems to be a nice “turnkey” solution if you just want to get things up and running, but I didn’t go that way. Let’s back up a second and talk about what functionality is necessary here.

To run a CNC machine, you need a way of making it perform the precise moves necessary to mill the part. This requires some form of “language” for specifying motion, and the standard here is NRS-274, commonly known as “G-code” since most commands consist of the letter G and a number.

When you design the machining cycle with your CAM software, the output is a bunch of G-code instructions that describe the machine motion. So how do you make your machine perform according to those instructions? Stepper motors are controlled with motor controllers, like the G540 mentioned above, that translate step pulses into energizing the phase windings that make the motor turn. They are fundamentally position-commanded actuators; give the motor controller a pulse and it will move the motor one “step” in the specified direction. (Most motors have 200 steps per revolution.)

So, how do you go from G-code to motor pulses? Something needs to interpret the G-code, calculate the exact path the machine should follow, and then convert that path to a series of pulses. Note that this is a “hard-real time” task — the pulses need to arrive at the exact times necessary or the motors won’t move smoothly. If the jitter is too large, the motor may even miss steps, and at that point it’s game over since that means the controller no longer knows where the machine is.

Here’s where one of my big problems with Mach3 is: it runs on Windows and outputs the pulses through a parallel port. A PC desktop operating system is not a realtime OS, which means you are always at risk of having something else on the machine do something and screw up the realtime task.

Instead, this seems like a perfect task for a dedicated microcontroller. For the ShapeOko, I ran grbl on an Arduino. The microcontroller does nothing except calculate motor pulses, so there is no possibility of having something interfere with the real-time task. All the host computer has to do is send the G-code instructions through the serial port to the Arduino.

From using it with the ShapeOko, I know grbl has some disadvantages that made me less enthusiastic about using it for the mill. However, there is another Arduino-based G-code interpreter: TinyG. TinyG has a more advanced “constant-jerk” motion algorithm than grbl’s “constant-acceleration”, which makes the machine move more smoothly. It also controls all 6 axes (3 linear + 3 rotational) specified in G-code as opposed to grbl’s 3 linear ones. TinyG comes as a motor controller board+code package using an Arduino Mega, but there is also a port to the newer and more advanced 32-bit ARM Arduino Due. This looked like a promising alternative. Because I’m using stepper motors with higher current than the grblshield motor controllers on the TinyG board can handle, I wanted to use separate motor controllers anyway.

Finally, the other thing that made me decide on TinyG over Mach3 is that TinyG (and grbl, too) is open source, while Mach3 is commercial software. I’m really partial to a solution where I can fix things myself if they don’t work.

The only problem with this is that Mach3 also handles the user interface. TinyG and grbl are only motion controllers. You interact with them through G-code, which isn’t very intuitive. While this doesn’t matter much when running an actual job, things like moving the machine around, calibrating the coordinate systems, etc, are much easier to do (and less error prone) with an actual user interface rather than by typing G-code. There is a “web-based” thing called chilipeppr which seems half decent, but I haven’t used it enough to know how it will turn out. That is also, however, open source, so if something I really need is missing I can probably figure out how to add it.

This was meant to just be the introduction to the description of the electronics box, but it’s long enough I’ll end here and leave the box for the next post.

2 Comments

  1. Pingback: The mini mill electronics box | Patrik's projects

  2. Pingback: CNC mill upgrade: servos – Patrik's projects

Leave a Reply

Your email address will not be published. Required fields are marked *