With a stouter cutter installed, we can experiment with less worry about breaking it. I started generating my own G-code programs from Autodesk Fusion 360 and testing them on the machine. (More about this test program later.) A safety practice I learned in my machining class is to test run a G-code program by intentionally setting a too-high Z offset. This way, when the machine runs through the program, it runs through all the motions but is only moving around in air. This lets us verify the range of motion is as expected. Including making sure it would not exceed either the XY limits of the machine or hit any hold down fixtures that are in the work space.

This process can be repeated any number of times, each time putting the Z a little closer to the workpiece than the last. And even if we don't expect to actually cut material, it's a good idea to power up the spindle just in case the cutter makes contact. While unexpected cuts in the work piece is not great, ramming a non-spinning cutter into the piece is worse.

Running in air is great for finding major problems, but minor issues aren't always visible. It wasn't until I cut into MDF that I found our latest problem: after the test program made its cut, its final position did not match expectations. Running the program again, we expected it to run through the same motion and not remove any new material, but it did. Checking the coordinate display on bCNC, we saw the machine believed itself to have returned to the same position after each run, counter to our physical evidence on hand. What happened?

To diagnose this issue, we tried eliminating individual variables from consideration. Running down the list of possibilities, from loose wires to loose fasteners. The key experiment was running the program without powering up the spindle, at which time all motion tracked as expected. (To protect the endmill from possible impact damage, it was removed from the collet for this test.)

This tells us the source of our unreliable motion was an electrically noisy spindle. A hypothesis is that it degraded our motor controllers' ability to distinguish signal pulses from Grbl, but the precise mechanism is not important. Whatever it was, we need to better protect the system from spindle motor noise. And since every motor will affect nearby electronics to some degree, this is probably not just a consequence of using the lowest bidder on Amazon.

In the immediate term, what we can do for our machine is to make sure the chassis is securely grounded, reroute signal wires further away from the spindle motor subsystem, and add a capacitor across the motor wire terminals to filter some noise. This was not precision tuning, as we just clamped the grounding wire to our gantry and the capacitor was chosen for its voltage tolerance rather than a specific capacitance. Still, the two measures seemed to improve the situation enough to proceed. We know "clean up wiring" is still on our list of technical debt, but this kicks the can a little further down the road and let me return to my test program - cutting holes for work fixtures.