Skipping problem solved

I've had two jobs where the router went off program and started plowing through wood along the Y axis. Both times this happened as the router was cutting a curve.

Last night I realized that router wasn't getting extra instructions, or firing erratically. Instead, the X-axis was stalling. Since it was cutting a curve, the stall showed up as a move in the Y axis. After looking around for a bit, it looks like a heat related problem and adding a fan to the setup would help.

I ordered a small 24V fan, and made plans to build a wood box to house the fan and the gShield/Arduino Uno combo.

I was going to wait for the fan to arrive, but then I realized I didn't need to. I already had a very large fan in the room that I could use to cool the gShield. My shopvac. I hooked the shopvac exhaust up so that it would blow over the gShield.

I had no stalls on the next, larger and longer run. I had one problem where it lost some steps on the X-axis, but I'm going to assume for now that's because I had upped the cutting depth to 3mm.

Successful run

I've been working on a dresser for my daughter, and using the CNC for some of the curves that will go on the dresser's bottom.

Last week I had an unsuccessful run where the CNC router suddenly decided to diverge from the path. I'm not sure if it was a user error or something else; it happened as I was preparing to hand things off to another operator. One of the things that I noticed was that the router had no problems going through the oak, even though it was already about 10mm deep.

But this week I had a successful run. The parameters were: cut depth of 2mm (up from 1mm), feed rate of 197.302 mm/min. The full file is available at http://a360.co/1NOrm5Y. 

One of the reason this run was a success was that none of the plunges happened in the wood; they all happened slight off to the side.

Test oak curve cut

I wanted to carve a nice spline curve in some White Oak for a dresser, so I first I did a test cut.

For my first attempt, I laid out a block of wood in Fusion 360 with the curve cut out of it, but I struggled to get the 2D contour to only cut out the curved portion --- it wanted to cut out the entire block, which would be bad --- I'm going to do the rest of the block on the chop saw and table saw.

I abandoned my original approach and created a document with only a sketch and a 2D contour. By setting a bottom height I was able to generate multiple 1mm deep cuts with a feed rate of 542.58 mm/min, using a 1/4" straight bit.

Naturally, something went wrong. It didn't cut all the way through, presumably because I measured the depth incorrectly. I resent the g-code after manually lowering the Z-axis, and then realized I really should have set the retract height to be more than 5 mm, because the mill started going through the portion I was cutting out. Fortunately it made it through without missing any steps.

Just like your compiler, if you lie to your CNC mill, it will have its revenge.

Pinewood Derby

My 10 year old wanted the CNC router to produce carve his pine wood derby car, so I obliged.
I decided to use Sketchup to create the car's geometry, because Sketchup is easy to use.  The downside is that it has a polygon soup model of the world, but this wasn't a problem for us in practice.

The first thing we did was to cut a number of blanks out from a spare 2 by 4, because, as I told Peter, "Nothing has come out of the router right the first time."  This was a wise move, because we learned a lot from this project.

I decided to use SketchUCam v1.2 to generate the G-Code from Sketchup.  It generates G-Code, but in my experience getting it to generate the right G-Code can require some creativity.  It had problems when the car was aligned with the axis, which I was able to solve by offsetting the car by about 2 millimeters along the X and Y axes.  It doesn't seem to take the bit size into account, but I was able to compensate for that by making some of the features on the car extra large.

But the biggest problem was that the G-code would repeatedly go over the same space over and over again.  Fortunately SketchUCam generates very nicely structured G-Code, and it was easy to write an optimizer for it, which I've put on github here. It looks for repeated traverses, and replaces them with traverses to the next non-repeated section.  It tries to just be a peephole-optimizer; I figured that if I started tracking the space the that G-code had carved I might was well convert from Sketchup to G-Code myself.

The milling parameter that took the longest to get right was 1mm per pass; it was hard to get right because I tried being overly aggressive to save time.  It didn't save tine.  Even at 1.5mm per pass my machine would occasionally stutter.  Another thing that we got were wrong was choosing a bit without a square end; that version of the car had some cool V-stripes up and down the car's length.

The final run skipped a few steps at the end and I had to stop it after it ran through the cockpit dome, bit that was easily fixed with a bit of wood putty. I was able to restart the job without homing switches, probably because of the amount of practice with the blanks. 

A brief plumbing diversion

Pulling out your Dremel during plumbing work is probably a mistake.  I should have pulled out the WD-40 first, but I didn't.  I probably could have gotten the faucet valve off without the Dremel, but I'll never know for sure. What I do know for sure is that no one makes those types of valves anymore.

It started so innocently.  I had some extra time between Christmas and New Years, and my bathroom sink faucet was dripping.  It seemed like a good time to fix the sink, rather than the beginning of a journey down a dead end tree in plumbing's evolutionary past.  A view into an alternative reality that sucks.  I knew that the sink was old --- probably 90 years old --- but I hadn't thought through what that meant.

When my wife told me it was a Crane sink, I didn't give it a second's thought, because I'd never heard of Crane.  There is a reason you've never heard of Crane sinks --- they're so badly designed for maintenance that it boggles the mind and most people simply junk them.  I've been writing software for 31 years, and I've never seen anything in the software world this bad.  Except for FIX order state management.

The first problem, which we'd noticed when we looked at the house, was that the stopper didn't work, and hadn't worked since I first touched a computer.  Every now and then someone unfamiliar with the house would push it down, and then I'd have to get a knife out to lift it back in place.  Forcing repeat pusher downers to get their own knives prevented repeat occurrences.  The stopper couldn't be fixed because the pole for the stopper is in the ceramic box on the right.  Unlike modern, surviving sink designs, you cannot get to the stopper pull. 

You also cannot get to underneath the faucet, because it is blocked by the same ceramic box that keeps you away from the stopper pull.  Instead, the faucet is held against the sink with a butterfly-like anchor that you insert through the hole on the bottom and then screw up. The top hole is for the water supply.  Being the first person to view the wing nut in 90 years gave me the same queasy feeling I get when I look at gcc's codebase, and wonder, "Does this really work? But the {tests pass}/{water comes out}." It also turns out that no one --- and I mean no one still alive --- makes plumbing fixtures designed to fit this sink.  At one point Mary Anne said "Oh, so it is a four hole sink." No, no it is not. And Mary Anne claims to have realized that, too.

Once I took the faucet off, I was able to pull the whole assembly out:

It looks like something from an Alien movie.  The pipe on the right is the supply, and the long hooked rod is what (in some alternate world) moves the stopper up and down.

My offer to buy a 3D printer and print out a new faucet assembly was summarily rejected by Mary Anne.

A new pedestal sink is in our future.  90 years isn't a bad run.

Bits have width...

I'm working on generating custom gcode to carve topless boxes. The intent is to use them for a dresser I'm building for my daughter.

For my first test I did a bottom and a side; the side is the top piece.

The code for the boxes is up at https://github.com/razeh/gcode-boxes; unlike a lot of other box generators it generates straight gcode, without any intermediate vector representations.

It has two problems: it isn't take the width of the bit into account when it carves the indents, and it doesn't create an tabs for the sides.  I hadn't realized how important tabs are until the bottom piece dropped out from the plywood while the router was still moving.
  

Expanded z axis, new spindle

Over the last weekend, I upgraded my Z-axis.

I replaced the stock spindle with a more powerful DeWalt DW660, which included replacing the stock mounts with DW 660 mounts. I'd bought the DeWalt spindle and the mounts a while back; if I had to buy again today I'd buy a quiet cut spindle, so that I could control the spindle's speed from software.  

While I was at it, I also replaced the stock 200mm Makerslide with one of the 500mm sections from my original Shapeoko 2 kit.  I don't need the extra height now, but when I upgrade the X axis I will.

Both upgrades are working fine, but I'm still having problems with the cutting depth. When I try to carve a circle 1/2 an inch deep I only get a circle about 3/8 of an inch deep.  If I reduce the depth per pass from .028 inches per pass to .014 inches per pass it goes a bit deeper.  If I support the table under the spindle it goes even deeper.

I think there is too much flexibility in the current setup.  Right now there are two big sources of the flexibility.  

The first is that the 25mm by 50mm extrusions that make up the table have too much flex in them, given that they span 1800mm.  I'm going to deal with this by using some of the 25mm by 50mm extrusions as supports under the table instead of as the table surface. I'm also going to start using 25mm by 75mm extrusions for the table surface.  The 25mm by 75mm extrusions are a lot stiffer in 75mm axis (with a moment of inertia of 37cm⁴ vs 12cm⁴), and a bunch stiffer in the 25mm axis (3.1cm⁴ vs 4.5cm⁴) as well.  They also manage to be a little bit cheaper per surface area than the 25mm by 50mm extrusions because you don't need as much hardware to hook them up to the table.