Clonedel!

Weeeeell, the Darwin died a death ages ago and fixing it wasn't worthwhile - once HSBNE got it's Mendel it was abundantly obvious how high-maintenance the Darwin was. And I was fed up with sanding the rust off the mild-steel bars. So I've decided to cannibalise/convert the Darwin into a Mendel.

Whilst the space's Mendel has already printed 3 children, I was interested in the resin-cast version that Metrix:CreateSpace is selling - it actually works out somewhat cheaper than printing the parts themselves.

The Clonedel (as it's called) parts just arrived an hour ago. And there were a couple of surprises!

It's St Patricks Day themed! Green is my favourite colour, so I'm quite pleased. The resin has clover mixed in, which is a neat trick and looks great.

Unfortunately there was a significant amount of air mixed in with the clover; it probably should have been degassed before it was used. That said, it's not actually a big deal - none of the pieces have large voids in them, so they'll still work perfectly well after I clean them up and drill the holes out.

Not what I thought I'd be posting about

...but it still qualifies as non-reprap related. :D

Earlier tonight Seppo and I built an Epic Workbench. Not one of those weedy things you might put a computer on, but something Indiana Jones could hide underneath to survive a nuclear blast. And we made it IN A CAVE! WITH A BOX OF SCRAPS! Okay, not really, but it was put together with stuff we found around the space.

Jeremy (of City Studios, the guy who leased us the space and will at some point use the rest of the warehouse) had a pile of modular office desks delivered to the warehouse a week or so ago; he'd got them for free from a decommissioned office or something. He also got a huge pile of 'junk' that came as part of the lot and was tossed out the back until it could be disposed of.

He said we could take whatever we wanted from that pile... which is a big deal because it's not junk at all. It's a large number of the modular partitioning frames and panels and such that are standard furniture for offices these days. In the dark, on treacherous ground I pulled out a couple of framework pieces and we discovered that they were each actually two frames bolted together that were *perfect* for making standing height workbenches.

An hour or so of work later, along with a couple of standard lengths of 2x4 and a sheet of ratty MDF that's been taking up space along one wall and we have the first of what will be quite a few brilliant standardised hackerspace workbenches. The MDF work surface is admittedly awful, and we'll probably replace it as soon as we can with a better specimen, but Seppo was eager to get an example finished and usable tonight, and it's perfectly serviceable (if you don't lose something down one of the larger holes :D)

We've found a few other treasures in the 'junk' pile so far, but those are going to be a surprise for later. And we've hardly scratched the surface of what is in there.

Greased Lightbox

→←+-↻

Loading image

Click anywhere to cancel

Image unavailable

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!

Oil - the cause of, and solution to, all of life's problems.

Another week gone and there was not much to show for it. The extruder stopped working again, of course. No amount of fiddling with it would make it go for more than a layer or so of any print, which is really frustrating when one needs just one more print (ok, admittedly a pretty large one) to dump the extruder for good.

However I did solve some other niggling issues with the reprap. I figured out how to get a set square in between the X and Y axes and satisfactorily set them up perpendicular to each other; it worked really well until yesterday when there was a somewhat catastrophic failure and I had to go through the whole mess of disconnecting the X belts and realigning all over again. It *seems* to be robust now that it's back together, but I want to replace the bearing blocks that mount the X carriage onto the Y as they're extremely fiddly and will bind if they're done up too tight... or shed a bolt or two, go loose and bind anyway.

I also figured out a way of having the reprap itself tell me how much backlash there is in each axis. I modified the firmware so that it keeps track of how many steps it takes to move off an endstop - since there only needs to be one step's worth of actual movement away from an endstop to deactivate it, any extra must be backlash. I measured 5 steps of backlash on the X axis and 1 step on the Y axis, which seems to be about right; it comes out to 0.625mm on X and 0.125mm on Y. Plugging those values into Skeinforge's Lash module (well, half those values really) made a marked improvement... in the partial layers I could get out of the extruder, of course.

I noticed that the extruder seemed to have more trouble when the print head was in the middle of the bed as opposed to at the origin, which is closer to the spool and so the filament is pulled to the side less. I used a long bolt and a piece of acrylic with a couple of holes drilled in it to make a filament guide that sat a couple of inches above the extruder and ensured the filament was more vertical as it went into it. I also put some oil into a folded up Subway paper napkin and put it above the guide to oil the filament as it passed by.

Still no good. Gaah! Screw it, I'm just going to squirt heaps of oil (well, a few drops) directly into the top of the extruder. I don't care any more, and I've tried everything else.

Wait a second, that worked?

Two and a half hours later...

:D

Teething problems...

Things have not been all rosy in reprap land (what else is new?) The extruder started playing up again, and all the prints so far have come out elongated. The stretching isn't just in X or Y either, which would point to an easily addressed calibration problem - instead it was along the 45 degree line. There's only one explanation for that - my cartesian bot was a parallelogram ;_;

After some thought I figured out that I could move the belt on one end of the X carriage back by one tooth to change it's angle with respect to Y. This seems to have cured the lean mostly (although I might still move it back one more tooth) however circles are still coming out squished in X. And it's not a calibration issue, because a simple square comes out perfectly, and smaller circles are more strongly affected than larger ones.

I discovered what I believe to be the answer by watching the reprap doing the crosshatched infill on the large gear pictured at the top of this post. The left pattern in the diagram is what I should be seeing, but I was getting the right pattern instead. The bad pattern is being caused by backlash on the X axis. It might be caused by a loose grub screw on the X stepper drive shaft, or it might be a less easily corrected fault. Skeinforge has a backlash-mitigation option available; if I can't solve the problem mechanically, I'll solve it in software.

Speaking of Skeinforge, I'm slowly coming to grips with more of the obscure functions it provides. It's ridiculously powerful but it's hell trying to understand what each option actually does. Additionally, certain features are hidden in places that one wouldn't normally expect to find them. I finally found the option to shift the starting point of an object in the Multiply section - I just set it up to print one copy of the object, and I configured the other options there to automatically centre the object in the middle of the print bed. That solved the negative-axes problem once and for all.

And the extruder? I got fed up with it and tightened the springs down as far as they can sensibly go. And it stopped misbehaving. But I'm still going to replace it with a Wade's extruder as soon as possible. I've printed out a couple of parts for it already - hence the large gear :)

More prints!

More things printed! I printed a couple more minimugs today, one which failed part-way through, and one which completed essentially perfectly!

I also printed a whistle - which failed quite unexpectedly, squashed over to the left. It turns out that skeinforge happily works with objects that extend into the negative axes, and the whistle has a lanyard loop that extends into negative X. Each time the reprap tries to move into the negative region, it hits the endstops and the origin is reset, pushing subsequent layers to the right. We ended up with a straight lanyard hole and a curved whistle :P

I also attempted to print a classical 3d hypercube projection (two wireframe cubes joined at the corners) but that object started 10mm above the print bed! I need to find out if Skeinforge can recalculate the position of an object to put it's bounding box at (0,0,0), or if I need to write something myself.

(thanks to tj for the photo)

The post you've all been waiting for!

It's a minimug!

I've been completely stymied by the extruder ever since the last post. Everything else has been working fine, but the extruder would jam after less than one layer had been printed. Nothing I did seemed to help.

After many attempts, I gave up on the original extruder and started figuring out how to build a stepper extruder without being able to print it. I spent a couple of days building a version of the Mendel extruder multiple times in various 3d apps, finally trying out OpenSCAD and loving it. It's far better to code the relationship between objects once and then tweak variables to make changes than it is to keep doing the math by hand in a traditional 3D CAD app. I'll be using it from now on - and if you're a programmer, you should too!

Of course, a 3D model is only useful if it can be instantiated, and for this I dug out my McWire mill. Sure, it's never actually milled anything yet, but what better time to try it out? Unfortunately, I hit a problem in converting the model into a g-code toolpath for running the mill. It's a solved problem, so long as you're running windows and have paid for a commercial app... the free linux tools left much to be desired. I can get close to a decent toolpath using Skeinforge (which is supposedly capable of milling as well as printing use) but not close enough to convince me to run the mill with it yet.

Therefore, I put together a version of the crudestruder out of various crap I had lying about. Unfortunately it looks like the small NEMA 17 motors we have lying about the space aren't nearly strong enough to drive the filament without being geared down; so this attempt was a bust too.

I was planning on borrowing the geared mendel extruder parts from Buzz that we received from Adrian a couple of weeks ago, except they require the new smaller bearings I have none of. I raced out at 4pm today to go to Hobbyparts.com.au, which is the best local supplier - they close at 5pm and aren't open on the weekend, so it was a real rush... only to discover the huge traffic jam that already occupied the Pacific Motorway. No bearings (and hence no mendel extruder) for me this week!

I was forced to return to the original extruder - but I had learned a couple of things about it and the hot end this week. Buzz brought in a thermocouple which I was able to stick down into the molten PLA in the heater barrel, and it read around 165 degrees when the barrel thermistor read 190. That makes the PLA far more viscous and hard to extrude. Therefore I increased the temperature of the barrel to '210', making the PLA much more fluid.

I also found a significant amount of friction in the extruder where the filament first enters it - there's a long section that the filament has to pass through before it gets to the drive screw, and it's perfectly straight. Unlike the filament, which has a significant curve to it. Disassembly (aaargh), lots of filing (aaargh) and some oil (eh) helped prevent the filament from jamming in that area. The oil also made the filament path far more transparent, improving visibility in the entire extruder.

Finally, the gearing at the top of the extruder wasn't correct - this being the first version of the rapman extruder, it placed the motor too far away from the drive screw gear, so that the gears would regularly skip teeth when the required force went up. I filed out the holes for the motor, tilted it, and drilled a new bolt hole for the motor at the gear end, which keeps the motor gear much closer to the drive gear. Now it no longer skips, regardless of the drive resistance.

And suddenly the extruder came good!

Now I need to go back into Skeinforge and start tweaking. It placed a ridiculous amount of inter-layer cooling time into the minimug gcode, the cooling movements on the bottom ten layers or so also significantly damaged the outer perimeter of those layers. Fixing that should speed up printing by about 5 times or so. Also, I don't think the minimug completely finished; it got somewhere close and then stopped, oozing a large blob onto the mug and causing the gcode uploader to spazz out a bit. I've heard about spurious serial corruption from other people, so that may be the culprit. Reducing the amount of useless gcode movements, and using one of the newer firmwares with checksumming should help. Finally, the aspect ratio of the minimug is off, as I have yet to properly calibrate the steps/mm values for the three axes.