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
times.

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.

IMG_20141013_220841276_HDR

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.

IMG_20141017_224518982

IMG_20141020_220739315

IMG_20141020_220821831

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.

IMG_20141029_214832034
Z axis assembled and X carriage on the gantry.
IMG_20141029_221001699
Attaching the Y axis rails to the “window frame” base.
IMG_20141029_221803675_HDR
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.
IMG_20141029_224823571
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.

IMG_20141102_094646112_HDR

IMG_20141102_133308324

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.

IMG_20141109_165103508

IMG_20141109_164953006

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.