I've got what I consider quite a ways to building a McWire RepStrap. I've got the steppers and the board to power them - scavanged from the dumpster at AE here in fort collins, co. Used to be part of a high power radio frequency power supply for etching microchips, but whatever. I've got a friend (a machinist, actually) helping me with construction of the McWire frame, and that's approaching completion. I've got the schematics for the power board (24volt, supplies +24, +15, and +5) and the arduino is hooked up to the right pins.
I tweaked the makefile (hardware/cores/arduino/Makefile) to get Zach Hoeken's arduino firmware to compile and load, because the "arduino" app wouldn't run. It's java and locks on my machine. I've got at least three different implementations of java, and all of them work to one extent or another. I know I'm not the only one fighting these java install/version/etc issues, somebody mentioned in his blog that he finally got it to work by searching the hard drive for "lib/ext" type subdirectories, and installing the j3d stuff into each and every one (found 16 or so) and still doesn't know which one he's running (see [
ar5in.tumblr.com] )
I had the host software running at one point, but now it segfaults. Dies while trying to determine the number of processors, if I'm reading the "log" file that java-1.5.0-sun left behind correctly. I don't see a way to attach a file to this post, and don't want to clutter things, so I'll leave it at that.
I'd like to see if the modifications I made to Zach's firmware to handle "coil A state" and "coil B state" instead of "direction" and "step" work, but I can't test that without the host software, because nothing else speaks SNAP.
So two things are irritating me right now:
1. SNAP should be G-code - I could use minicom or such to talk to it with a keyboard and at least see if things are working. And then I could use a host of other software to talk to it too. It's unlikely that the first useful tool I'll mount on my McWire will be a extruder - I'll probably mount my rotozip and try carving some wood.
2. The host software should be written in something for which there aren't multiple conflicting (and variously broken and buggy) implementations. People have mentioned python, and that's got my vote. I've only got one implementation of python on my computer, at it works.
Probably the way to manage the transition (from SNAP and java to g-code and python/something else sensible) is to modify the current reprap host software to talk g-code, and the arduino firmware to talk g-code as well. My fellow java-swearer-at above mentions that he has a partial g-code interpreter for arduino, but doesn't supply a like where I could get to it. Maybe he'll read this and point me at the firmware? (sorry, I could search and figure out your name, but it's late and I'm lazy)
I've concluded from this experience that I hate java. And that I'm done swearing at this thing for the day. I'm really not this grumpy in person, I swear. I've spent about 6 hours just trying to get the reprap host software to run, and that'd be enough to make anybody grumpy, I'd think. This project is fascinating, just what I've been looking for, and I look forward to messing around with all sorts of modifications to it. Figuring out obscure errors isn't the fun part though.