Catchup post!

Things have been a little busy of late, so I've been woefully behind on updates. Hackerspace Brisbane moved into new digs at Fortitude Valley; the new space is much larger than the old one and is starting to feel like home. Sadly for me I used to live 30 seconds walk away from here, but I moved away only a few months ago. ;_;

Anyway, moving in and getting everything set up (walls, internet, electricity, killingscaring off pigeons, reworking the rfid access) has taken a bunch of time away from the reprap. But not entirely!

The new stepper extruder has successfully replaced the old one, so no more griping about having to pull it apart every five minutes. It had consequences right the way down the line, however.

I threw together a temporary stepper driver using one of my easydrivers from my McWire mill. It can only supply a maximum of 750mA to the motor, which is borderline insufficient when running on 12V. When I mentioned this to Matt at one of the meetings, he dashed out to his car and pulled out a bunch of stepper control boards from some industrial printers he had recently dumpster dived. The chips (STK672-080) are through hole, properly documented online, and really beefy - up to 2.8A without a heatsink! I've built up a new driver board using one, but it is yet to be tested - the driver chip is unipolar, requiring me to run another two wires over the loom to the extruder. Makes me glad I didn't completely cut off those wires on the motor!

Initially I'd skipped putting springs on the bearing assembly, but the motor would get stuck unless I constantly supplied some extra torque with my fingers. Springs appear to be exorbitantly priced around here, so I went the DIY route and wound my own using music wire for pennies. The results aren't brilliantly pretty, but they work really well! The motor now only skips occasionally. Unfortunately it isn't a full solution, because the slightest extra friction on the filament stops it, so I need to monitor the filament feed. Hopefully the new driver will sort that out.

On the software side, the original reprap firmware has support for a stepper extruder, but there's a bug in it somewhere that causes the arduino to reset as soon as it is activated. That pretty much forced me over to the newer 5D firmware sooner than I'd expected, and 5D supposedly requires the Arduino to be replaced with a Atmega644-based Sanguino. They lie! 5D will run happily on a 328-based Duemilanove if you remove the directives preventing it from compiling; the *only* issue is that the compiled binary is larger than the older 168-based Arduinos can hold (about 20k) but the 328 has plenty of space left over.

I don't know if this is deliberate or just not given sufficient thought; the code blocks compilation for anything other than a 644, when it should just be blocking compilation for the 168 instead.

Once I moved over to the 5D firmware, I had to modify the g-code generation on the PC side to support the new 5D syntax. That was 'simply' a matter of enabling the Dimension plugin in Skeinforge. However, the result wasn't great; the subsequent prints all seemed to drive the Z axis WAY too fast even though Skeinforge was configured to allow only a maximum of 180mm/min in Z. Even the g-code output looked fine, as it correctly lowered the feed rate for the Z moves.

The culprit was finally apprehended - in this case the 5D firmware. By default, the firmware is configured with a "Swish! Ultra-cool!" feature to accelerate the extruder head from it's current speed to each new speed that is supplied in the G-code - this allows the use of smaller motors like in the Mendel. Unfortunately, the acceleration includes moves on the Z axis! What would happen is the reprap would be moving the extruder head fast in XY and then try to decelerate *during* the Z move - starting at 2000mm/min and dropping to 180 at the end. But since 180 is the fastest that Z can do, almost the entire move was made far too fast. Obviously acceleration shouldn't be applied in this case!

I'm guessing that the reprap host software inserts explicit feedrate changes around Z moves that disables acceleration temporarily. Skeinforge doesn't. Disabling acceleration in the firmware and recompiling it fixed the problem.

I've now got the reprap printing ridiculously quickly - 40mm/s feed rates when doing infill (which makes the machine shake madly), and half that when doing outlines. That adds up to a massive win when printing objects that have large internal volumes, but not so much when it is all thin walls and details.

Now with a (mostly) working reprap, I was 'strongarmed' by Arjen into bringing it in to last week's Barcamp. I'd never been to one before, and I was looking forward to some of the talks that were scheduled. Alas! The machine proved so popular with attendees that I spent the entire day with the reprap in the common area printing and distributing nifty little HSBNE keyring tchotchkes. Maybe I'll just bring a video of it to the next one. ("No you don't!" I am told by multiple people :P) As the day progressed the print quality declined until the keyrings were no longer any good; the extruder wasn't laying down enough plastic, probably due to the weak extruder driver. But it will live again!

Sorry for the lack of photos; I've misplaced my camera's memory card. Will update when I find it. Coming up next - something not reprap related for the first time in a while!