I’m not convinced yet that this thing will be able to do PCB isolation routing, but I’m willing to give it a try. It’d make it much simpler to do one-off’s, instead of having to live with this:

But I’m not quite willing to dedicate an Arduino Mega and the UltiMaker electronics that is offered as option in the workshop. If you’re interested in 3D printing: the UltiMaker is derived from the RepRap and the MakerBot CupCake, as described here.

So instead of following everyone using the MPU-based approach, I’m going to re-use my parallel-port laptop running the EMC2 software, and let the laptop do all the work, instead of yet another dedicated board. I can always switch to a microcontroller setup later if this machine is practical enough to use it frequently. And if it doesn’t work out, my investment will have been relatively low.

There’s also a second reason for doing it this way: I’d like to build my own electronics for this CNC/3D stuff one day. I think there are better ways to do this sort of thing, more modular, more extensible, and more flexible (why not Ethernet? why not closed-loop servos?). But it wouldn’t be realistic to think I can take on that challenge as well, with everything else also going on at Jee Labs. So for now, the parallel-port shortcut will have to do.

Driving CNC stepper motors from a parallel port is a proven (but by now somewhat outdated) concept. Either way, it all ends up doing the same thing: executing the CNC world’s de-facto standard G-Code scripts.

You still need stepper motors, and stepper motor drivers, since a parallel port can only send out feeble 5V signals.

To save some time, I decided to try something a bit whacky by re-purposing an UltiMaker electronics board to hook up its motor drivers to the parallel port:

Lots of stuff on there I won’t need: heater control, extruder control, PWM…

Here’s a minimal setup, using just 3 stepper drivers and a little JeePlug board sitting on top of some extra headers on this board:

I patched a 5V regulator (plus LED) on there to feed the logic levels of the Pololu stepper drivers, and left everything else off, basically. Only thing left to do is wire up 7 signals + ground between the parallel-port breakout board and the JeePlug.

And then figure out the software side of things…

As a result, the first part I printed did not contain enough material, and ended up too fragile for actual use. That’s part of a micro-lathe I’m printing for someone else, btw.

So I disassembled the extruder again, and replaced the PTFE rod with a new black one:

Yippie, now it’s working again. I’ve also upgraded to a heated build platform, which works great – no warping and the parts come off real easy, with raft and all:

Here’s a component from the Wade extruder which I’ll need for the Mendel:

Alas, not all is well yet. This was supposed to be the other half of that gearwheel pair:

Hmm, looks more like a cupcake to me…

The other nasty problem is that the main body of the Wade extruder I’m trying to build is too large for the CupCake. I can’t print it! Now I’ll either have to buy a complete extruder for the Mendel or find some other extruder which works with it. So as far as the next-generation “Mendel” is concerned, I still need to assemble the electronics and find some good extruder for it. Drat, it’s always those last 20% that bite…

The horizontal base comes out ok (I cleaned up the hole):

Interestingly, the top of the bracket isn’t filled in, which is actually better:

The sides look much better as well:

(the Skeinforge settings aren’t perfect yet, layers could be mashed smoother together)

But wow – what a difference this makes! Thanks for the tip!

Here’s another object, a Geneva Wheel from Thingiverse:

Turning is not very smooth, had to cut off some plastic from the round shafts, but hey: it works!

PS. Don’t worry, I’m working most of my time on JeeNode stuff, hardware and software that is… ;)

Here’s the design:

The design dimensions are 25 x 12 x 10.5 mm. It was created with OpenSCAD, which takes a description of the object and generates the solid model shown above:

Does it work? Can it be printed? Can it be used? Yeah, sort of…

Works for JeePlugs too, since all the boards have the same 21.1 mm width:

Took me three tries to get the sizes and the little ridge right (the middle one):

Pretty ugly stuff, when seen up close. But hey, that’s what pioneering looks like!

The ridge which holds the board doesn’t come out very clearly – the features are not yet a match for what the JeeCake 3D printer can do (or should it be the other way around?):

But despite appearances, this bracket is already surprisingly functional. Apart from the awful surface and rough shape, it’s a springy and very robust little piece of ABS plastic. It could easily be screwed down, and it would hold the board quite well.

Fascinating, it’ll be fun to see how this evolves over the next few years.

This is my current test setup:

The JeeNode on the printer side implements a packet pass-through system, receiving command packets from the JeeLink and sending back response packets. Here is the sketch which does all the work:

On the Mac/PC side, some Tcl code was added to go through the RF12demo text-mode protocol to send and receive arbitrary data, using the “a” command. Still work in progress, but the basic transport encapsulation works.

The tricky part is timing … it always is with this sort of real-time control stuff. Unfortunately, the current G3 software on the CupCake isn’t quite as responsive as defined in the specs. Some responses take way over 80 milliseconds to come back from the motherboard. This is the case when scanning the SD card, as well as when stopping the extruder motor.

So what this sketch does is wait up to 500 ms for a reply to come in. Even if there isn’t one, an acknowledgement packet will be sent back. The new code on the Mac in turn waits up to 1 second for that ack to come back.

If no ack came back, then there was an error in the wireless connection (this can happen either during the request or during the ack, there is no way to tell!). Probably best thing to do would be to resend the command.

If an empty ack came back, then the response packet did not arrive within 500 ms. In this case, we could send an empty command and wait for its ack. This hasn’t been implemented yet, but it will allow dealing with even the slowest responses, simply by polling a few more times with an “empty command”.

But hey – it works, and the output is the same as before:

This is probably the first wirelessly controllable CupCake in the world :)

What I should mention though is that this doesn’t yet work reliably due to those very loose timing behaviors and the fact that packet errors are not yet dealt with. Test runs fail occasionally – mostly in the SD card access code, i.e. while grabbing all the filenames with NEXT_FILENAME.

And sure enough, it works:

You’re seeing the nozzle cool down, after heating it up via ReplicatorG. The connected JeeNode has been given node ID 19, and it’s transmitting in group 5 of the 868 MHz band, so I can simply track these incoming packets through the JeeLink which is already collecting all sorts of data anyway.

So much for the easy part – the real software will be more work!

The RepRap Motherboard is the main on-board controller, based on an ATmega644. It drives 3 stepper motors, communicates with the Extruder board, and talks to a desktop computer via its FTDI interface and a USB cable.

On the PC side (which can be Windows, Mac, or Linux), there is a Processing-/Arduino-like package called ReplicatorG to control the machine. It takes G-code, which is not related to Google in any way, but rather an ancient CNC control language from the 60′s.

ReplicatorG then converts this to a binary RepRap 3G protocol, as documented here and then uses that to drive the CupCake. Everything from moving the axes, adjusting the nozzle temperature, controlling the extruder motor, to writing settings in the machine’s EEPROM memory.

The neat part is that the v1.2 motherboard has an SD card adapter on board, and that the CupCake can run unattended by getting its detailed build instructions from files stored on an SD card.

Except for one little detail: there are no controls or displays on the CupCake, other than a few LEDs. This is not enough to select which file to print, adjust the zero position, or start a build. It looks like a new “Generation 4″ design is on the way, including an interface board with an LCD screen and some push buttons.

Right now, you have to connect the machine via USB, start everything up via ReplicatorG, and then you can yank the USB plug and it’ll happily continue printing what it started, right to the end (well, except that on Mac OS X 10.6, yanking USB cables can lead to kernel panics – looks like a serious bug in the FTDI USB driver).

Anyway, I don’t really care for controls, or even displays on the CupCake. All I want is some way to control a unit sitting on the other side of the room, or in a nearby room. It can be fairly noisy due to some sort of occasional wood panel resonance, and having it printing right next to me is not really my idea of fun.

Which is where JeeNodes come in: wouldn’t it be nice to be able to control the CupCake via wireless? The protocol is already perfectly suited for it, since it uses packets of max 32 bytes – well within the 66-byte limit of the RF12 driver. And if the object being printed is already on the SD card, then only a few packets need to be exchanged to get going. During printing, some status info could be sent back – again very low rate stuff, easily within the JeeNode’s wireless constraints.

Here’s the idea:

Hook up a JeeNode to take the place of the USB cable, and let it behave as a RecpicatorG control program.

The interface needs to swap RX and TX for this, and because the CupCake’s signal levels are at 5V, two 1 kΩ resistors need to be inserted to prevent excessive current. One more detail is that the power pin on the FTDI connector is not connected, since the motherboard is powered off its own PC supply. So a separate wire needs to be added to power the JeeNode off the ISP connector right under the FTDI connector:

The one wire not shown here is the ground wire, running from top right to bottom left on the other side of this little custom interface board.

It turns out that the motherboard is actually powered from the 5V standby supply pin, so it’s always powered, even when the power supply is in standby mode.

I’ve started writing some code on the PC/Mac side to control the CupCake without using ReplicatorG. Here’s some sample code in Tcl which works when connected directly through USB:

And here’s the corresponding output:

As you can see, it can access all sorts of status info, read the file names on the SD card, and control the machine. This is part of a larger project, the beginnings of which are now in the subversion code repository.

It takes a lot of work to make hookups like these work, because there are so many different bits and pieces (literally) involved. The next step is to see if the JeeNode can indeed communicate with – and control – the JeeCake, and then code needs to be written to replace the current direct-USB connection by a packet-based wireless hookup through a JeeLink + JeeNode.

Oh, and then I need to create some sort of little on-screen control panel to adjust the nozzle temperature, jog the Z axis up and down, pick a file to print, and start the print job! Not to mention making it robust and secure…

I’ve been placing my headphone next to me on my desk for ages. There is of course never enough room on top, but plenty of spare room underneath:

So here’s my home-made headphone bracket:

Here’s the design, made with Sketchup:

I just picked a “2″ in a suitable font, re-sized it, “drilled” some holes in the base, and then “printed” it.

Piece of JeeCake!

PS. Given that CNC and 3D printing is not really the main focus of this weblog, I’ve set up a page on the wiki.

Update – design files added to Thingiverse.

The raft is now very solidly stuck to the base:

This thing really sticks well, with plastic pushed down into the criss-cross grooves of the acrylic base. The trick is to place a plain paper sheet between the extruder head and the base, and to lower the Z axis until the paper slides away with just a tad of friction.

Unfortunately, the next problem comes up – as seen in this first Geneva Wheel trial:

It turns out that the next layer of the raft doesn’t stick well to the first one. I solved this by raising the default 230° setting to 240° for the raft.

Another serious problem was that there is a lot of plastic on the right end of the raft as the print nozzle paused (!) on each turn. And the second layer of the raft doesn’t extend all the way to the end. This was solved by adding three noise-suppressing 0.1 µF caps to the extruder motor and disconnecting all the end-stop optocouplers.

The object itself seems to come out fairly well, though there were some blobs of plastic around the nozzle during printing which clearly interfered with the X-Y motion at times.

Here are over a dozen more parts, printed using black ABS for a change:

These all came out ok, but note that even these small parts take 10..15 minutes to print – each.

The biggest remaining problem is “warping” – it’s causing over half my trials to fail:

This part failed to build (should have been 20 mm high), it slowly came off the base and started interfering more and more with the extruder nozzle. At some point the nozzle got stuck in fact. Note how the thickness of the part is completely uneven. This is caused by the ABS cooling down and shrinking a bit – slowly pulling itself off the raft (with considerable force). A heated baseplate seems to be the hack to solve this – but that will require a lot more tinkering.

Oh well. We’ll get there… eventually :)

Update – upgraded to ReplicatorG 0012 with Extruder firmware v1.8 and switched to Zach Hoeken’s thermistor settings (raft setting reverted to original 230°). The last change was to shine a halogen light on the platform and object, to heat it up a bit – this seems to get rid of just about all the warping, yeay!

Well, the CupCake worked straight out of the box, which is of course fantastic. But printing does seem to have two tricky bits, called “extrusion” and “rafts”.

Here’s the printer making its third part:

What’s about to happen, is that the “raft” (that woven mat laid out on the bottom to hold the rest of the construction) is about to come off the base. In the above picture you can see two other problems: the raft itself coming apart, and a blob of plastic (front right) when the printer decided to pause for a few seconds, while the extruder kept pushing out plastic…

The problem seems to be that when the plastic cools down fully it becomes quite springy and rigid. Which is great for the final object, but causes trouble in keeping it stuck to the acrylic base. I suspect that the heated platform which people are experimenting with is to overcome this problem, by keeping the base slightly sticky for the duration of the build.

Or maybe a few wires extending further out from the raft would help, by “tacking down” the whole thing.

The other purpose of the raft is to even out the surface. In my case there is a slight difference in height across the base. I should probably try to get rid of that first.

Anyway, here are the objects made so far:

The meandering plastic retains its shape – that’s probably part of the magic behind all this.

PS. The stepper motors are noisy. I don’t think the software I’m using is micro-stepping right now.