First real part off the mill...

So I've finally got a part to run to completion! It's not the x-axis part I was making last weekend. I decided to give up on that for two reasons (1) it is a large piece and (2) if anything the printed x axis is the least weak part of the system. I have a bunch of aluminum cutoffs I scavenged ( ~ 50mm x 150mm x 5mm) so I made a smaller part. It's a spinning weapon from one of my kids' combat robots, scaled down by 50%.

This lovely weapon is then attached to a 2822 brushless outrunner and spins at about 7k RPM. It slices, it dices, it kicks other bots out of the arena!

Here's the first attempt. First g-code to run to completion! There are four, 1mm high tabs to hold the part to its stock to prevent flyoff. You can see there is a thin layer of aluminum between two of the tabs, clearly the stock is not flat or the head not perfectly trammed. 

The part tore out easily. I used a decomissioned pair of wire cutters to trim the flashing then a rough diamond file. Careful eye can see a fair bit of backlash in the larger holes and a dimple (due to backlash) on the bottom curve.

So back to the machine. Fiddled around with a number of things and found two things I thought were culprits. The first was play in the y-axis - I fiddled around with my printed housing for the motor and the bolts, and they were a bit loose. I did this on purpose at first because when I tightened everything down the axis became very hard to turn, likely because the print is slightly misaligned which shifts the housing around the shaft out of center. I took the housing apart and drilled out the bolt holes a few mm wider so that the print could slide around laterally. This helped quite a bit - I could lock down the print and the tension only increased a little bit over being loosely coupled. Secondly I tightened a few of the set screws in the saddle - again, to the point where it felt a little harder to turn, but not completely locked down. I also slowed down the Z axis a bit - some testing I was doing mid-week showed slips in the Z over time. I wanted to make sure I wasn't driving down the end mill too quickly and either moving the part or sucking the part up.

This one turned out much better. tolerance on the outer holes is ~0.15mm. The interior hole is about 0.05mm average narrower than the CAD. Which may make sense. In Fusion 360 I have the tolerance set to 0.1mm, and when you are adaptively milling out a hole you are essentially milling concentric circles. If you discretize a circle you get a polygon with a lot of sides, which is inscribed the circle, so perhaps this outcome is a-o-k. I need to study a little more to make sure my intuition is correct.

Anyways, super happy to have a part come off the mill. Repeatability in the Z axis is a bit of a concern and rebuilding the Z axis in metal is likely the #1 priority. 

metal chips

Well, I almost made my first part. Almost.

I bought some cheap 1/8" two flute end mills from Amazon. 10 for $11. I am actually quite happy with them. As you might recall when I was cutting wood, with the 1/4" end mill I had I could cut out the big void in the middle and the perimeter, but the 1/4" end mill was too large to make the bolt holes and socket cap pockets. These end mills do the trick, and I only broke one in the process of making those bolt pockets.

I used adaptive clearing, setting a boundary of the outside of the part, with these settings it was able to clear all the holes with the 1/8" end mill. I omitted the center circle because man, that would take a long time to adaptively clear all that material! Here is the adaptive settings I used for the bolt holes and socket cap pockets:

• Under Linking, section Ramp, set minimum ramp diameter to 1mm. This will allow you to mill out a pocket of (end_mill_diameter + 1) 
• Turn off rest machining and ensure it isn't leaving extra stock
• Change the optimal load to 0.75 (reduces loading, prevent snapping)
• Make depth of roughing cut 1mm
• Set "Order By Area" to ensure it finishes one pocket before moving to the next one - otherwise it will do all pockets at 1mm depth, then all pockets at 2mm depth, etc... 
• Adjust speeds. I chose 250mm/min travel speeds, with my mill running at ~ 2000 RPM. If you have a router going faster, you can travel faster

I then set up a separate adaptive clear for the large center hole, and a 2D perimeter cut with tabs. For these I set up a 1/4" end mill. I managed to snap several of the 1/8" end mills trying to do 2D perimeter tests and gave up on that idea for today. It would successfully make a few passes, then bind and snap. I have some culprits (the Y axis is still sloppy, maybe it lets the bit drift and bind). But I figured sooner or later I'd have to entertain tool changes, why not start practicing now. 

Code set up, I kicked it off with ChiliPeppr. I had a few stumbles (y axis grub screws came loose, y axis end nuts came loose - I locktited them) but once I was cutting reliably in scrap aluminum it was time for a clean sheet.

The four bolt hole with socket cap pockets and the two thru-holes cut excellently. The tool change triggered. This part was nerve wracking but turned out to be no big deal. The steppers lock in place and so long as you drive with the GUI you can raise the head up, do your tool change, and drop it back down no problem. Which I did! Once you drop it back make sure you measure the position of the tool relative to the part. You can drop it to zero, align the tool on top of the surface, and tighten up. Resumed the code - a it did wind up binding up on the second pass - the X axis stumbled a bit and the bit gummed up and I killed it. I should have had the RPMs set higher on the spindle. DAMN. What to do.

Well, I decided to generate new GCode which just has the center adaptive clear and the perimeter cut. Instead of referencing the corner of the part, I referenced to the center of the circle. Using a compass, it is easy to find the center of the circle as the starting point. This went well, clearing out the middle pocket, but then it bound up on the second pass of the perimeter. I was using the same feed and speed as the adaptive clearing, but the adaptive clearing only loads about half the tool, whereas the perimeter cut is loading the entire tool. I should have the spindle going faster, or the tool going slower, or take a shallower cut. 

The other culprit is the slop in the Y axis. As it is going along the channel it can drift back and forth and suck itself laterally while still being driven, and potentially gum up the works because the channel depth of cut is deeper than the direction it is being driven.

So close, and yet so far away....

Next thing I am going to do is fix the Y axis coupler, before trying again. But regardless, videos below:

Controller configuration

For initial testing, I would take my laptop out to the garage and use Grbl-Panel.

Slick as Grbl-Panel is, I don't relish ingesting a chip into my laptops' keyboard. So I am going to use an Orange Pi Lite as a grbl server. Prior to the advent of the Raspberry Pi 3, the Orange Pi devices were half the cost and came with integrated wifi, and had more powerful processing power - while the latter is no longer true they are still cheap, nearly expendable computers. I'm not sure the exact configuration I'll end up with but I have had 3 ideas

1. Get a Raspberry Pi touchscreen and go full touch interface.
2. Get cheap used DVI monitor/keyboard/mouse and use the OrangePi as a computer interface
3. Use server software and jog via tablet/upload gcode for production

I'm going to go with (3), with (2) as a backup. During testing I can use my cheap windows tablet as a pendant and during production runs I dont need to have any computer there except the Orange Pi. If this is limiting I'll add a monitor/keyboard from the thrift shop.

Orange Pi Configuration

I installed a fresh Armbian image, added my user acoount and enabled wifi (nmcli c up id <router name>).


First things first: perform an apt-get update, apt-get dist-upgrade to ensure the latest packages. Reboot and make sure your wifi configuration sticks.

First program I tried was grblweb. This is a nodejs-based program that allows you to control your mill remotely through a web browser. It looks fairly simple and well thought-out, the only downside to the naked eye is that github hasn't been updated in 2+ years.

Clone it from github:

 git clone https://github.com/andrewhodel/grblweb

grblweb is built on nodejs, so we need to install nodejs/npm and various dependencies:

 sudo apt-get install nodejs npm
 sudo ln -s /usr/bin/nodejs /usr/bin/node
 npm install serialport
 npm install socket.io
 npm install node-static

now you should be able to cd into grblweb and execute

 node server.js

Load up a web browser to the IP of the machine, port 8000 and you should see the GUI.

If you want to run it as a service (start on boot) you can use forever and crontab. First install forever
sudo npm install forever -g (g=all users) Then follow the instructions from the top answer at stackoverflow.

I went out in the garage to test. I was able to jog the mill with the graphical joystick on my laptop but this was problematic on my tablet - sometimes it would be interpreted as moving the screen, other times as a joystick jog. Additionally there weren't a whole lot of features to do interactive positioning or gcode playback. I was a bit disappointed - this is probably great for production use but I needed something more oriented towards diagnostics.

So I went to the backup plan - ChiliPeppr. The concept is that ChiliPeppr is a "hardware fiddle", a more-or-less generic gui for various hardware devices. By forking the code and creating workspaces, you can create interfaces for new devices. Among these devices are grbl devices. NOTE: if you are using Grbl 1.1 (ie: the latest release) you want to use this workspace, not the grbl one which supports 0.9. In order to talk to your mill you need to download the JSON server for your computer (arm in our case) (download link bottom-right part of screen) and start the service on the Orange Pi. Now with any other device on your network you can connect to your device (bottom-right) using a URL that looks like ws://192.168.1.10:8989/ws. Your device will show up. Before connecting, you must change the connection type dropbox to GRBL! This will cause confusion if you do not. Click the checkbox next to the arduino and you're connected. You can jog by clicking the "jog" button and clicking on the screen. You can play back the test gcode by clicking "play". The code will pause at tool changes, hit the pause button to un-pause. I chucked up a pencil and pressed it against a notebook on my bed... and it worked !  more or less. I lost a few steps in the x-axis at one point.

TL;DR: suggest using Grbl-Panel for diagnostics, ChiliPeppr for gcode testing.

Mill tear-down

So Robothon was yesterday. My metal combat bots were both 0-2 but neither was demolished; in fact they both still run. The next competition is at the end of January at the Northwest Model Hobby Expo, so I have a solid 3 months and some change to finish the conversion. 

Today I stripped down the table of my mini mill, because the y-axis has always been particularly sloppy ever since I got it. And I figure I should start with a clean, dialed-in machine. After cleaning chips and wiping down the machine I took off the x-axis by spinning the table all the way to the right and then taking off the handle and key. By jamming the table left to right a few times I was able to free the outer bearing and remove the table. The last bearing I took off by placing a crescent wrench against the bearing and then tapping it with a rubber mallet. Now the Y axis is exposed and the culprit became immediately apparent: the nut on the leadscrew is free floating in a slot in the y-axis table and is supposed to be pinned in place by a screw which was loose. Screwing it down and tightening the handle, the slop was instantly gone. Great, but I proceeded to finish stripping it down to clean and oil. Once the table was off I discovered the column was not properly aligned:

I loosened the outer two bolts and took a half-turn off of the center bolt and was able to rotate the column to visual alignment - once I have the table rebuilt I'll use an indicator on a magnetic base to confirm proper alignment. 

I cleaned off all of the packing grease I could find and rubbed everything down with an oily cloth and reassembled the y-axis. I tightened the screw which pins the leadscrew nut and tightened the nut on the handle to a comfortable tension and there was no visible play in the bed - of course once fully assembled I'll verify with an indicator. 

Tomorrow night I'll assemble the x-axis and work on confirming things are nice, smooth and aligned.

3D printed soft jaws

So I've been a little slow to make progress on the CNC conversion. Besides work ramping up and kids' evening sports I've been occupied by building combat robots. Here's my 3 pound bot, Love Hate Love (left) inspired by my 1lb plastic bot, Rain When I Die:

If you sense a theme in the names, it's the song playing when I go to hit "Save" on the CAD file, and I've been on an Alice in Chains kick as of late.

In the process of making hubs for the wheels, I needed a pair of soft jaws. I have two 3D printers so I whipped a set up in CAD and printed them off. I added them to Thingiverse. Here's what they look like on the lathe:

They are printed with ABS at 100% infill. I don't expect them to last terribly long but they work well for touching up parts and surface finish passes. I plan on printing a pair in Nylon in the near future.