More CNC timeline notes, from first movement to first carving

The following are a cut and paste from my personal log on the milestones as I got the CNC working.  I figured I’d paste them here since rewriting them wasn’t going to be much more interesting than their content as they stood.

A few notes though:

  • Seb is my friend who is also an active maintainer of LinuxCNC.  I’ve learned most of what I know about LinuxCNC from him, and he’s been invaluable in helping me understand problems that I had no words to plug into Google for.
  • Jim is a friend who has a Shapeoko2 close to my design, so most of his config files and design helped me understand more of what I was attempting to do
  • Lee is another friend, who provided me the circuit board he laid out and designed for his CNC, which like Jim’s is very close in many aspects to how I decided to build mine.
  • Without these three friends, I would have not embarked on building  my own, I needed quite a bit of knowledge that they all freely shared.
  • The “gold brick” is my term of endearment for an industrial PC that my friend Brent gave me.  It was an ASUS Aaeon Intel Core2 Duo packed into a U shaped aluminum cavity that serves as the fanless heatsink for the whole thing.  It happens to be anodized to a gold color, is compact and it weighs a fair amount, thus the term “gold brick”.  This is one seriously awesome PC.  I was hoping to use it because it was an industrial PC, and being fanless could withstand the dust that it would be living in.


A very cold week of negative temps prompted me to find a propane fired heater for the garage.  Unfortunately, Home Depot and Lowe’s both were sold out, as it’s seasonal and that’s all they were shipped.  OK, I get that it’s a seasonal item, but seriously, I live in an area of the country that’s cold during the winter, and you only had 5 heaters? And you won’t get any more for the entire year?  It’s not May, it’s January!  There’s at least three more months of cold.  Sheesh, you brick and mortar stores don’t want to lose business to online retailers, but you refuse to restock, then I have no choice.  ACE and other stores in the area likewise were out.  OK, a visit to Amazon later and it was on it’s way.  Prime is an awesome thing, and today I unpacked and fired up the propane heater. Aaaaaah. Very nice.  Just need to make sure to keep vented.


First movement! Got the right signal out on Z-axis step. It only moves in one direction though, which makes me think that the z-direction isn’t being toggled. I’m using the “Test this axis” in stepconf, so it jogs it back and forth. Also in AXIS gui, trying to jog the z axis doesn’t go but one way.


Spoke with Seb about it (Seb is my friend that is one of the active developers of LinuxCNC). Learned a few new things about LinuxCNC, and the halcmd shell that allows you to toggle stuff. Also about HalScope and HalMeter. He definitely agrees that it needs to be scoped out from the PC down.  Looks like that’s the next step because there’s no other way to tell. Good thing I have a scope… Also spoke about the weird power issues. Turns out it might not be the right pin being toggled for the Amplifier Enable pin.


Tonight I used the scope and traced the signal for Z-axis direction out to the driver. The steps are making it through, but the direction isn’t. Well, you can plainly see on the scope, the signal goes into the optocoupler chip, but not out. It’s a fried channel on the optocoupler. Dunno if it’s from rough ESD treatment or just plain failure, but it’s needing to be replaced. Hello Mouser, here I come again. Sucks to pay shipping on a $0.70 part, and it sucks that a $0.70 part is hanging up the show. Oh well, I have other things I can test out.

In my friend Jim’s config, I noticed that he didn’t slave the A axis to the Y, he just set the Y pins (step and dir, inverted for dir) to Y’s nets. So that’s what I’ll do too.

Also changed pin 1 to be Amplifier Enable like Jim’s config has. That seems to solve some of the strange power control issues.

Got X-axis to move. I don’t know why the pins aren’t changing for pin 8 and 9 which is what I also have Y-axis step and dir mapped to. The pins off the port aren’t changing, so it’s not an issue with the board.


Working with the “gold brick” Asus Aaeon industrial PC, installing a SATA drive and putting LinuxCNC 2.6 on it. Wifi issues abound. As it turns out, through the various machinations, it’s somehow a problem of interference between the Parallel port card that was installed and the wifi card. I don’t know if it’s a PCI conflict, since the parallel and mini-pci wifi cards are both on the PCI bus, or what, but every time I pull the Parallel card it works, and when it’s reinserted, it doesn’t. Who the F knows. Ordered a PCIe wifi card tonight to avoid having a USB dongle hanging off of it, to give it a bit more mechanical stability. It needs the duck antenna if it’s going to be out in the garage, the little USB plug that I tried from Edimax loses packets because there’s too much interference.


Wireless PCIe card arrived, installed it. No problems connecting. Must have been a PCI conflict of some kind, possibly both slots shared the same electrical connections. Also installed the new optocoupler chip into the driver carrier board. No dice. things still not working the way they fully should. I need to spend some more time on it, but don’t have it tonight. Got the internet connection up, so I’m happy about that at least. Now comes the tough part of getting the board debugged.


Wahooooo! All three axis are moving, all four motors! The transistor for the z-dir pin optocoupler was disconnected. No connection even though the trace is there. Some sort of defect keeps it from being connected. A bit of wire wrap wire and some solder got it working.  So I didn’t need a new optocoupler chip afterall, but whatever.  I didn’t expect the trace to not be connected.  Also, Stepconf wizard doesn’t understand sending the same signal (y-step and y-dir) to two sets of pins, so it only moved one motor not the two of the Y axis gantry. After getting the config written, AxisGui had no problem with the signal going to two motor controllers.


Used Pololu current setting document to setup drivers. Drivers running much cooler now. Each driver will measure at 0.70 of what they really are pulling, so when you want to find out what current they’re really at, you need to multiply by 1/0.70, or 1.4 of what’s showing on the current meter. Set trimpots and got the three axes on the right current. Drivers and motors both happier now.


Built small fan shroud out of strips of scrap ABS plastic. Smaller fan now blows directly across the heatsinks of the drivers and in the right orientation. Drivers are warm, but never burn-your-fingers hot now, due to this and the current adjustments. Now the biggest frustration lies in making it accurate. It doesn’t step right.

Found out that the switches that were installed on my control panel are wired correctly, it’s just that the 48v power supply that I bought has a ground fault in it (as evidenced by having only ground and hot hooked up, and it still tripping the GFCI). Every time power is applied to it, it trips the GFCI. Ordered a new one.


Wired up the new 48v spindle power supply, tested with the spindle and the motor controller. All in that chain work well. Got the control panel wired up with the new power switches, and all the wiring tidied up and looking good. Used a new step-down powersupply to drop 24v down to the 6v that my fans require. They’re 12v fans, but I wanted them to be quieter. I used a 6v power brick, but it means that it’s switched on and off different than when the motor drivers are. It’s easier that if they get turned on, so do the fans at the same time.

Got it to step smoothly. It’s now needing to have it’s carving space defined so that it can run programs. Might need to ask for help on that, but I’m also taking apart Jim’s files to see if there’s something there that could clue me in. Need to start coming up with artwork or at least some designs that I can run through a CAM program and generate some ngc files.

Update – got it to trace out the sample LinuxCNC ngc file it comes with. I still need to do work on scaling it so it can be accurate, and getting the Z-axis right. I’m not sure what I’m going to do, it needs to know where it’s home is, and I think I need a switch that is actually on the top for home, with the bottom being limit. Otherwise, I’m not sure it will carve right.


Early morning, got out to the CNC machine and tried more configuration now that I had used Seb’s G54 knowledge. Messing about with configs, I was able to get it accurate, for the most part. But now I need to get it tuned, because it’s close, but not enough. Z-axis remains a pain in my ass. I need to get it’s soft limits set in.

Problem now exists where it’s skipping steps or stalling on Z. While it works, it doesn’t work well for Z. Start looking into SMI and other possible reasons for stalling or skipped steps.

(Turns out, the gold brick just wasn’t awesome for this application, it had a horrible latency histogram, as found by the latency-histogram tool.  This is part of what I’m referring to in the comment about SMI above. I won’t explain that here, it’s better explained in the LinuxCNC docs.  I eventually had to go back to the HP Pentium4 desktop PC I was using before I obtained the gold brick.)


Installed new USB wifi dongle, it works. Continuing with removal of PCIe wifi card and inserting a PCIe video card. Tried several from the stash, settling on one that supposedly doesn’t do too much better than the Intel G945 one that’s built in. Ha! Launched and played around with Axis GUI and it’s fluid. FLUID. Not this chunky crap that the Intel one had. OK, it stays in.


Spent time rebuilding the gold brick. Long story short: nouveau driver works, but is broken. Predictably broken, but annoyingly so. It’s workable. What isn’t is the nVidia drivers. Because of a problem with a GPL symbol, the driver wouldn’t compile. and left the system in a crippled state. Had to copy off my crap and rebuild to get it back. Not happy. Tried again, but it had the same effect. Finally reverted back to nouveau, and sticking with it. Wasted too damn much time on it.


Talked with Seb, he thinks that latency issues aren’t to blame for the z-axis missed step/stalling. he thinks it’s an issue with the threaded rod possibly. This was something he mentioned after I mentioned that the noise was coming from the center of the carriage rather than the motor. Sooooo, time to take a critical look at the entire axis and see if it’s got mechanical issues.


After getting the Z-axis re-aligned again, I was able to see a correlation I hadn’t seen before: when the Z motor was jogged when the Axis gui was set to a high jog rate, it seized. I always had to drop the jog rate because it would just go too fast. I discovered that slowing down the velocity and acceleration for the Z-axis significantly allowed it to move the axis without seizing and losing steps. In other words, the acceleration and velocity were set too high for the motor to handle it, and so it wasn’t a latency issue, it was that the motor just couldn’t move fast enough. once those values were turned down, the axis didn’t lose a step. After this, I was able to get the system using a sharpie without ramming it into the bed. Of course, I also had to learn that the LinuxCNC sample gcode has the 0 for the z set at 2mm above where it puts the tip as it’s moving. When I accounted for that, I got the right results. I also created a spring loaded pen/pencil/marker holder so that I can use pencils in the CNC. Works like a charm. I set it to move on 5mm increments, and it does. It’s now fairly accurate. Next step is getting some Gcode put together and attaching a spindle. I might use my dremel tool to start, so that I can see how it goes before putting my more expensive spindle in harms way.


A quick and dirty pen holder that uses a rubber band to keep the pen connected with the paper, without ramming the pen into the bed.


The first complete tracing.
Oh so close. Close enough. Each square is supposed to be 5mm.


Z axis is driving me nuts. Damn thing can’t move faster than 632mm/min without seizing and stalling. And what’s worse is it seems every CAM program doesn’t get that on evac out of a cut, the Z can’t move that fast and needs to go slower. I’ve tried editing the gcode, to limited success. I took time to figure out how to adjust that with Cut2d, and CamBam.
Installed the T-Nuts and got the wasteboard zipped down to the frame using 10mm M4 BHCS and drop in nuts. Used the Forstner bit and went 7mm deep, leaving 5mm of it to grab onto. Now I need to cut some hold down pieces to use with the T-nuts.


Tore down the Z-axis in anticipation of replacing the screw drive. I had thought it was bent by the way it wobbled, but it turns out it wasn’t. It was how it was fastened together. Only by tearing down the Z could I also figure out (now that I had something to drive the motors, unlike I did when first installing it) that the high jog rate would stall the motor even without the load of the carriage and the screw drive. Implemented a much better limit switch solution, got it so the carriage can now travel the full negative z. This gives me a z axis length of 57.5 mm.


CAM is a nightmare. I’ve tried many of the different packages, free and commercial demos. it’s a nightmare to get a usable piece of software, but it’s also a format nightmare. Even when you get a usable piece of software that isn’t cryptic, it may have issues not being able to read the drawing files you need to hand it.  Some allow you to route “on the line” instead of to the inside or outside of it. Others won’t, and if you want to it’s an “engrave” operation. Oy.

My selection criteria are:

  • needs to be easy enough to learn on my own by poking around and knowing basic terminology
  • the workflow needs to be uncomplicated
  • the more complex features need to be present even if I don’t need them for everything I do.  I need to be able to start simple and grow into the program
  • It needs to work, on what I feed it for 2d as well as STL files for 3d.
  • Getting an evaluation license can’t be a pain
  • It can’t cost an arm and a leg.  I get that it’s a tool that people have spent time on, and being a software engineer myself, I don’t expect to get all of my software for free.  But it has to be accessible to the hobbyist, and that means I’m not dropping $15k on a SolidCAM license.

Ones I’ve tried:

  • pycam
  • cammill
  • freemill
  • meshcam
  • cambam
  • vectric cut2d
  • makercam
  • easel
  • dolphin cam

What I’ve used to draw with:

  • draftsight
  • inkscape

I’ve learned that DXF isn’t always a DXF that is compatible.  Apparently, as my friend who works for a CAD vendor said, “welcome to the hell of CAD file formats”.

(I finally settled on CamBam.  I’ll probably do a post purely on that, there’s much to cover.  It’s $149, it does all of the simple and all of the complex stuff that I’ve thrown at it.  And above all, the guy that wrote it allows you 40 free unrestricted uses, which helped me while I was attempting to get things working and not have to worry about plunking down the full money for it until I did.  If you’re looking for a CAM solution, I highly recommend CamBam.)


I was able to get the SVG to DXF script to work, and was able to get my daughter’s request (“LOVE” drawn out) done with pink marker. She was happy, but so was I: finally able to get inkscape SVG drawings into CamBam. So this looks doable. As for 3D? None of them seem to be easy to get a 3D STL file mapped out, except for MeshCAM. I would be willing to spend the $250, if and only if it made it easier to do 2D and 2.5D CAM, but it doesn’t seem to. Since the majority of what I’ll be doing is 2.5D, CamBam is more appealing as it is easy to get paths laid out. It does 3d too, but i haven’t had much luck with it yet, and can give it time since that’s not the primary focus of my CAM experience.

Tonight’s the first cut! Started with a 1/8″ end mill, in the spindle with about half the speed it can go, and did some cutting using manual jog. I was attempting to use it to cut the side of a pinewood derby car, since my daughter wants an ice cream sandwich for a car and I needed to cut down the side of one. After failing at this miserably, I decided to get a piece of 1/4″ MDF cut to the right size, and give the good old LinuxCNC logo a try. Set to a height off the surface of 1.5mm, this meant it would (should) cut .5mm deep, since it plunges 2mm on that program. It finished without an issue. WOOOOT!

Pinewood derby car side, not very well managed. Oh well, a good first try at using it for something.
Yay! First actual gcode guided carving!

Wiring of the Shapeoko2

Wiring is a pain.  One of my friends at the hackerspace that had built his Shapeoko2 mentioned that assembly was the easier part, the hard part was wiring it up and he was right.  Included in this work was also figuring out how the power supplies and the other bits would be arranged. OK, it wasn’t that much of a pain.  It was fun trying to figure out the layout of the power supplies and the control boards, as well as where the emergency shutoff switch was going to be located.  It was one of those moments where you look around for what you have on hand, because you need to solve problems you didn’t know you had until you run smack into them.  McGyver moments if you will.  A few examples are the fan shroud, the cable strain relief, limit switch mounts and the e-stop button.

It starts with a slab of particle board as the base of the layout.  This section of board is meant to be somewhat detached from the table, so that I can move it in and out as needed to service various parts.

Control Panel

I had to figure out how to mount the e-stop switch as well as the spindle speed controller’s pot.  I decided to make myself a slanted control panel.  I had some of the black plastic you see in the picture, already cut at a slant.  I grabbed a piece of clear acrylic and slapped it together with some glue.  The best solution isn’t always the prettiest.  Over time this panel has grown to include the master power switch, the lights, motors and spindle switches.  At some point, I may re-engineer this panel, including using the CNC to machine it’s own panel, complete with engraved labels.  But that’s off in the future.


Cable strain relief

Had to get inventive on this one.  I needed a way for the cables sticking out of the side of the machine to be strain relieved so they didn’t damage the motor controller board if they accidentally got yanked on.  It doesn’t happen that often that something falls or something gets caught on the wires, but once is enough if there’s nothing there to hold it in.  The mounting board is a bit of acrylic, which I solvent welded a thicker chunk of acrylic to.  With some holes in the thicker acrylic, wire ties can now be used to keep the bundles from being yanked out of the screw terminals.  To date, it’s saved the controller board terminals at least three times.  The bluish colored blobs are epoxy putty (love the stuff, so useful) which the aluminum stand offs are stuck into.  This solves the problem of mounting the circuit board to the acrylic strain relief board, without having to counter bore the underside to use screws.  Simple and effective.

Strain relief holes drilled and populated with zip ties.


Bluish blobs are the epoxy putty that the aluminum stand offs are stuck into.
Wire bundles connected to the terminals, and strain relieved with zip ties.
Wire bundles connected to the terminals, and strain relieved with zip ties.

Wire gauges

The NEMA23 motors for the X and Y axes required a gauge that could take a continuous load of 2 amps.  I decided to use a flexible 16ga speaker wire, I needed the flexibility for movement, and although I technically could use 18ga, I tend to over engineer.  Monoprice had a wonderful deal on a 100′ roll of 4 conductor speaker wire for $40.  This gave me enough with spare.  I used 12ga solid core conductor from the power supply to the motor controller board, because it could carry a max of 34 amps.

Cable chain mounting

I finally figured out that I could use a salvaged block of HDPE to mount to the side of the X gantry and attach the cable chain head to that.  A bit ugly, but it works well.  The cable chain for the X carriage is less sophisticated, and at some point in the future, I’d like it to be a proper cable chain, but at the moment the woven cover is good enough.



Limit switches

The limit switches I bought came on these little circuit boards and while they looked nice, there were two problems: they were wired up wrong for my electrical setup, and they got in the way.  I had to throw them out, they just wouldn’t work.  So I desoldered the switches off of them and decided to mount them myself with a few pieces of plastic.  I over engineered the switches mounting plates.  I figured you couldn’t just glue them to the plate that you screwed onto the rail, because over time the pushing on the switch might crack the glue.  Thus I used #1-72 screws.  If I’d thought harder, I’d have realized that it’s total overkill because if your limit switches are taking enough strain to crack glue, then you’re doing something wrong. 😉

Mounting plastic and screws with one of the salvaged switches.
Limit switch mounted to the X gantry.


Stepper drivers get hot.  Like burn your fingers hot, and that’s even well before they hit their melt down temp.  They definitely need cooling if you want to use them long term (longer than a few runs of the CNC that is).  My first attempt was poor, because even though the fan was sitting on top, it wasn’t blowing across the heatsinks in a way that would maximally remove the heat.  Eventually I threw out this shroud in favor of a shroud I created from some scrap ABS, a server fan and a bit of glue and epoxy putty.  Even at full tilt, the motor drivers are kept well ventilated and they do well.

Heatsinks lined up in a row.
Original fan mounting.
Improved shroud, with higher volume fan. Also higher noise, but with the voltage regulator, I have turned down the voltage so that it’s not too annoying and still maintains a decent flow of air.
Photographic proof that this project has drew blood, along with the sweat and tears that most large projects exact from their creators. A note of caution: don’t have fans powered on and fingers anywhere near them. This one not only broke the blade but also cut me good when I made the mistake of getting too close.



A solution to Pidgin, Plasma5 and the missing systray icon


I found out a while back that Pidgin’s underlying library libpurple has the ability to have many functions called through dbus.  So if I can’t figure out how to get the systray icon back, could I at least poke it to show the buddy list again?  Turns out with a short bit of research and some playing around in an ipython shell with the dbus module, I was able to come up with the following (hackish) script to display the buddy list window when it accidentally gets  closed:

#!/usr/bin/env python
# coding: utf-8
import dbus
bus = dbus.SessionBus()
purple = bus.get_object("im.pidgin.purple.PurpleService", "/im/pidgin/purple/PurpleObject")

I put this in a script called “buddylist”, and call it if I ever close the buddy list window.  Works like a charm.

The longer story:

In the wake of KDE’s Plasma 5 desktop being released last year, I discovered what many did about some systray icons: they no longer appeared.  This is a problem for any application that minimizes to the systray like Pidgin does.  While it’s not hard to leave Pidgin’s buddy list (it’s main window) open, sometimes it accidentally gets closed, which means it closes down to the systray.  If the icon isn’t able to display in the systray, then all is naught, because killing pidgin and bringing it back only restarts it in the status it was last time, i.e. minimized to the systray. Google didn’t help here, because I kept finding old posts about a different systray problem from 2010, or 2013.  Great.  I had fallen into this hole of Pidgin being minimized, even on restart.  Not fun, I had work to do and people at work to IM to collaborate with.

I love all of the hard work that the Plasma 5 and KDE devs do.  You guys rock, and my world has been better for it for the last 16 years of using KDE.  Consider this my heartfelt thanks for all of your hard work.  But as with most things that change out from under you, it’s irksome to get a new version and things are broken.  Of course, the first thought it to blame someone for things being broken.  There’s a phrase I keep saying and trying to remember : there’s always extenuating circumstances.  In other words, when criticising other coders make sure you understand all the factors that went into their decision before opening your mouth, otherwise you’ll only embarrass yourself.  That is definitely true here, as demonstrated in the following two article links.  It looks as if they’re attempting to correct hackish behavior with respect to systray icons, so that we can transition to something like Wayland in the future and get rid of X baggage.  Ah, so there *IS* a reason…

Where are my systray icons?

System Tray in Plasma Next

Footnote:  I rely heavily upon Pidgin, and before you suggest XYZ client because it’s better, we all use software that we’re accustomed to for a reason, and we’re more efficient for it.  Doesn’t mean I’m unwilling to try out new clients but sometimes sticking with what you know when it just works, is worth it.  I like to save my brain power (or brain damage) for the new things I must learn.

Assembly begins

The Shapeoko 2 comes in one size: 500mm x 500mm.  If you want a larger footprint, you’ll have to buy longer lengths of makerslide and make it happen yourself.  In addition to larger makerslide, you’ll also need to get longer lengths of 20×20 rail, as the two Y axis makerslide rails are tied together by bolting to two lengths of 20×20 rail, one in the front, and one in the back.  What isn’t immediately obvious is the rails that the Y axis makerslide connect to are not 500mm long, they’re 550mm.  Now, if you’re sensible, you’d realize that this extra 25mm on each end is for the end plates to get a good grip on these rails.  Alas, I wasn’t paying attention and ordered replacement 20×20 rails at 1000mm instead of 1050mm. This is a bit of a problem because I also ordered the standard 1000mm makerslide, which means that 1000mm on the X axis doesn’t account for the extra 50mm needed for the ends. Since the gantry is 1000mm long, it stands to reason that the Y axis rails need to be mounted outside of that envelope. Duh.

I always order more than I need, by about 10-20%. Murphy’s law for
ordering parts says that the relationship between how bad you need
something and how long you have to wait for it is inversely
proportional. If you got to have it now, it’s going to take all the
longer to get it shipped to you. Misumi is not exempt from this,
especially because I didn’t read the fine print that it would take 3
weeks just to get my rail cut, before it could be shipped. If I had
ordered a 4m segment, I could have had it within the week, but getting
it shipped to me would have been quite a bigger issue. That being
said, let’s be clear that the screw up was mine, not theirs, because
they clearly state it ships in 3 weeks. Let me also mention that
their pricing is pretty competitive, and they’re worth buying from
again. Just beware of what it means when you look at their shipping

Back to the original thought: it’s good I order extra. I figured I
could use the extra extrusion on a future project if I didn’t use it on this one, so I ordered seven 1000mm bars. Turns out I was short that 50mm on three of the lengths in the design of the frame so instead of waiting longer, I decided to make use of the other bars. I cut 4 of the 1000mm bars to be 550mm, and made a square frame with the 6 inner bars at 550mm, with the longitudinal 3 bars being 1000mm. This meant that I could match one dimension in 1000mm (the Y-axis) while making the X-axis have the extra length so I could fasten the Y-axis rail endpoints to it securely.

While we had a horizontal autofeed metal cutting bandsaw at the
hackerspace (which I probably really should have used, since it makes
really good square cuts) I decided to use my own 9″ bench top bandsaw
with a metal cutting blade. Since the blade was new and tensioned
right, it tended to cut straight. I still had to square up the ends a
bit with a file, as well as take down the burrs. But it had worked,
and soon I had the “window frame” done.


Although the plates allowed NEMA23 motors to be mounted, it meant I had to go get different bolts and nuts than what were provided for the NEMA17 size that normally comes with the Shapeoko 2.  The new hardware collided with the rails, until I read and also heard from my compatriots at the hackerspace that you want to push your rails off to one side, this way it keeps you from having any mismatch in both side’s mount points. I had to make sure that the motor shafts were able to reach, which the pulley was able to with enough to grab the shaft.

Using my dremel tool and a grinding wheel, I ground down the shafts,
on the shaft in two places 90deg apart for both of the set screws on the pulley.




For the most part, it’s a piece of cake to assemble. Just tons of
parts. The two tough assemblies were the Z-axis motor mount and the squaring of everything.  Holy cow, the z-axis needs 3 or more hands to be able to put everything together.  They’ve fixed that issue with design of the  X-Carve.

A good reminder: Loctite! Locktite! Locktite! While it seems trivial, I had an eccentric nut fall off during a cut because I didn’t locktite those.  I had to readjust it, then loctite it. Use the blue type not the red type, because it’s likely you’ll need to remove or adjust things later.

Z axis assembled and X carriage on the gantry.
Attaching the Y axis rails to the “window frame” base.
Sometimes you need to be an octopus to put these things together. Attempting to mount the plates while the weight of the X gantry was on the rails was a bit challenging, but I was able to use some scrap plastic that happened to be the right size for being a spacer.
Finally assembled!

Building the control board

There’s an overall workflow for carving anything with a CNC machine.  The three basic phases of this workflow are:

  • Create a drawing in a drawing program.  Save it in a vector format.
  • Convert this vector based drawing into machine commands, known as gcode.  Usually this is done with a Computer Aided Machining or CAM program.
  • Interpret this gcode into actual pulses and steps for the motors.

When I started on this path, I didn’t know which interpreter I would use.  The four friends I had at the hackerspace convinced me that I should go with LinuxCNC running on a PC instead of using a gcode interpreter based on arduino (GRBL).  While LinuxCNC is a bit more complicated, it’s very powerful.  To drive the motors, LinuxCNC is a hybrid between the Linux kernel, and a real time kernel.  The Linux kernel yields control to the real time kernel when real time deadlines need to be hit.  For something to be classified as a real time system, it needs to have the ability to respond to an interrupt, or to hit deadlines (like setting a signal high or low) within a very short time window.  This requires an interface capable of being toggled in real time, and that happens to be the trusty old parallel port.  Why can’t we use a USB interface?  Why do we have to use an actual parallel port and not an adapter?  USB just can’t offer a real time response capability because USB is considered “Isochronous”, which means “equal time”.  USB has timeslots that are assigned to the endpoints attached to the bus.  This means that an endpoint won’t get data until the timeslot for it comes around.  If your real time signal fires, and it has to wait because it’s timeslot passed by, then by the time the timeslot comes back around you’ll have missed the deadline.

Timing is only one aspect.  The pins of the parallel port can’t drive a stepper motor directly, it simply doesn’t have the power to do so.  This is where a stepper motor driver comes in.  It is a module that takes a few inputs, like “direction” and “step”, as well as some others like “enable” and “microsteps”, and turns it into pulses out on four wires.   It makes driving a stepper easier, especially if you’re doing any sort of microstepping.   While we could hook the pins of the parallel port directly up to the stepper driver boards, that would be somewhat foolish because it would expose the CNC controller PC to potentially hazardous (for it’s health) electrical transients.  Usually when interfacing any type of logical signal to the dirtier world of electromechanical signals, you want to use some sort of isolation.  Optocouplers are the right choice here.  Luckily, I have a friend from my hackerspace who designed his own carrier board for Pololu DRV4425 driver boards.  It comes with optocouplers to connect the output pins to the drivers as well as the input pins for the limit and home switches to the input pins on the parallel port.  I have four of these drivers to plugin to the carrier board.  For my build, I need a driver for the X and Z, and two drivers for the Y axis.  These are the ones I am currently using:

Pololu DRV8825 High current stepper driver

He gave me one of the blank boards and the BOM shopping list at Mouser, but the rest was up to me to assemble it.  Armed with my trusty Metcal soldering station and my newly constructed redneck-fume-extractor, I got to work.



You always need to double check your boards.  There were two defects that caused me problems that should have been caught in electrical test.  I don’t think my friend paid for that level of service though.  The first defect is a missing plating on a drilled hole.  One of the holes for the DB-25 pin connector wasn’t plated, and was effectively electrically unconnected.  While I could attempt to load up as much solder on that pin as possible and see if it would connect, the simplest answer is simply to figure out where it should connect and solder up a small jumper wire.



The second defect was far more insidious and took 3 weeks of time to find and fix.  The problem was that the direction pin for the Z-axis motor controller didn’t seem to be connected to the stepper controller.  In tracing out the signal with the oscilloscope, I discovered that the signal went into the optocoupler but didn’t affect any change on the output pin for that signal.  My first thought was that the optocoupler had either been defective from the start, or that I fried it with a static charge.  I try to be cautious about static, but I’m also not paranoid, so it’s possible that it got fried by a bit of my easy going attitude.  An order into Mouser and a week later and I had a new optocoupler.  I plugged it in and…. nope.  No change in signal.

It hadn’t occurred to me initially that it was a circuit board issue.  Not until I tried the new chip and it didn’t work that I removed the board and started actually metering out each connection with a continuity check.  Turns out, the copper trace for that signal connected up to the stepper driver, but didn’t attach to the pin of the optocoupler.  This too required a jumper wire fix.  I’m happy to say that’s all that was wrong with the board.

Redneck fume extractor

As I was getting ready to build the motor driver controller board, I realized that it would be a good idea to use a fume extractor.  This was a major soldering build, more than I’ve done in one sitting in quite a while.  I’ve seen these used, and my local hackerspace has one:  Hakko Fume Extractor


I didn’t have an extractor, but I did have the parts for one.  A spare wall wart power supply, a surplus squirrel cage fan, an activated carbon filter, and a bit of plastic to mount it on.   The first item to be selected was the fan.  As any good hacker, I have a junk box and happened to have a squirrel cage type in the pile.  Squirrel cage fans are good for moving air, which I need if I’m going to be sucking it through a carbon filter.  I already had the formed plastic on hand, it just needed a hole cut for the fan.  A 3″ holesaw did the trick to cut a hole for the intake.  A 12v wall wart provides enough power to spin the fan at it’s highest speed, which is too noisy and moves too much air.  Downgrading that to a 9v wall wart seemed to give enough air movement without being too noisy.


It sits nicely over the PCB holder in my PanaVise.  It worked well during the soldering of the motor controller board, and it’s continued to serve me well.


Building the table

The table was definitely a lot of work.  It was a simple enough plan, three levels, locking castors on the bottom so I could move and adjust it, and sealed with polyurethane to keep it from warping with humidity.  I stuck with a 48″ by 48″ size, which would give me plenty of space for the 1000mm squared CNC frame.

Starting frame

I started with two 2x4s for the bottom frame, because the screws for the wheels needed something to grab onto.


I love pocket screws now. The printer hutch I put together earlier, and this table were the start of my building with them. They make putting furniture together easy, and sturdy.  Don’t forget to add some glue to the joint.  You have to be aware that they will pull upward, so if you’re trying to be accurate, make sure to take that into account.


The finished assembly of the frame.  Time to put wheels on it.

IMG_20140920_203032793_HDR IMG_20140922_224116464

Locking castors are only on two of the corners, and both on the same side.


The top is the only attached surface, the other two platforms are cut in half, and placed after assembly.




This is after the shelves are cut and placed in, and after the top has been trimmed with the router to fit.  It’s secured down with screws at this point.


Here’s the finished table, and in this picture you can definitely notice the glossy top.  The top surface has 4 coats of polyurethane, and each of the support structure members has at least 2 coats.  The only thing left uncoated are the shelves, which are unattached.

As I was working with the table during the build out of the CNC, I noticed that it was a bit more wobbly than I preferred.  I looked at right angle brackets at the hardware stores, and they all seemed to be too expensive.  16 of them are needed, which adds up quick when they’re $6 each.  I decided to get some strap steel with holes and cut it to size for each corner.  This was pretty quick to implement, and worked like a charm.  The table has definitely improved in stability.