5D
So, the time has finally come for us Makerbot folks to catch up with the RepRap crew and put stepper motors on our extruders. (Seriously, has anyone seen a RepRap with a DC motor from that last year?) This is a good thing. It’s spectacularly good, except that the software isn’t ready.
Oh, it’s close. I’m even helping to get it there, but it’s still in need of work. The RepRap project has been using something called “5D GCode” for a while now. (It seems to have started out as “4D,” and was outlined in this post. Some more info on it’s current usage can be seen on this page about Erik de Bruijn’s conversion script.) It’s a simple addition to the GCode that Makerbots use: instead of “start extruding at xxx power” it treats the extruder as a 4th (or 5th) axis, telling it to extrude N mm of filament for this movement. This extra axis is expressed as an E code, like this:
G1 X1.0 Y1.0 E1.4142
This is really slick because the movements will be synchronized with the other axes and the filament will be put down in an even amount.
There’s still a huge problem that’s not covered in this scenario: how much to move? Is a mm of filament before or after the extruder and nozzle? How do you compensate for … well, anything? There’s a lot of factors being ignored here: filament thickness, extruder “pulley” diameter, nozzle size, and plastic expansion/contraction are just the ones I’m aware of that matter. Relative humidity, ambient room temperature, filament manufacturer, and filament color (and the fillers that are required for those colors) may matter as well.
In the various means I’ve seen the solution is to simply scale the E axis by some amount, and the operator is apparently supposed to fiddle with that amount until you end up with something that “looks good.” I don’t think that’s good enough.
I’ve been working on a way to take at least some of the predictable factors into account and eliminate most of the tuning, leaving only fine tuning. The clearest way I can think of would be to include the expected output volume per mm of travel in the gcode, and then determine the correct math and methodology to make the machine provide that expectation as closely as possible.
To determine how much volume we want out is easy: layer height x thread width x mm/s gives us the volume per second in mm3, or uL. I’m hopeful that this will eventually come from Skeinforge. I’m thinking of using the M108 code with an L subcode, like this:
M108 L0.23
The hard part sounds easy: figure the volume of the filament going in per motor rotation (and thus per step of the motor) and that should be how much plastic comes out, right? It turns out that the answer is no. Thanks to Dave Durant providing good, reliable numbers, I’ve been able to determine that that’s not the case. (Dave had come to the same conclusion separately.) I believe it’s due to a phenomenon called “linear mold shrinkage,” which basically means that when you heat the plastic and force it into a small space it breaks down a little and occupies less space afterward.
Whatever the cause, it appears to be linear, meaning if we put in N amount of volume, we will get N * M amount out. M appears to be somewhere around 0.85 for ABS. I haven’t had a chance to test this myself, and am curious to see how PLA does and how other factors effect it. Regardless, we can now figure that for L mm3/second we need R revolutions per minute of the extruder motor.
This should yield extremely higher quality prints with minimal effort, no hardware change (aside from the stepper motor driven extruder), and minimal software change.
Math
D is pre-extruded filament diameter (precisely measured)
C is the circumference of the pulley where it pushes the filament
L is the mm3/mm to extrude P is rotations per minute
R is mm3/rotation
f is the linear mm of travel per second
h is the layer height
w is the thread width
S is the shrinkage factor, which is volume out / volume in
Measurement
I believe, but haven’t tested, that you could make simple gcode that, if given D, C, an the diameter of the extruded filament (which is the nozzle size with die swell, not just the nozzle size) it would move the extruder up 100mm, then extrude enough filament that it should just touch the platform. The amount that it’s wrong could be used to adjust S to the correct value.
Implementation
For now this could be used to calculate the correct RPM for a given feed rate.
If testing proves this to be valid, I’d like to see this implemented in the Makerbot and RepRap firmware along with a Skeinforge plug-in.
