As it turned out, though, that part wasn’t the first attempt.
Even switching to red filament didn’t help:
That, in fact, was when the light dawned: it always failed at exactly the same point for a given set of G-Code.
Come to find out that, for some parts printed with certain options, the Skeinforge Reversal plugin dependably produces huge blobs of plastic after a move. The extruder reverses properly, the XY stages move, then the extruder starts running forward at the Reversal speed while the XY stages move at whatever rate they’re supposed to for the next thread, producing a prodigious blob.
Most parts have much more interior than they do exterior and, with any luck, the blobs vanish inside. However, this little bitty thing has no room to hide a blob. Several parts went down the drain, but at least it had a countable number of layers!
Here’s a sample of the failure:
G1 X0.0 Y2.11 Z3.3 F708.318 M108 R25.0 <--- Reversal speed M101 <--- Extruder on forward G04 P125.0 <--- Reversal pause M108 R0.3778 <--- Normal speed (continues forward) G1 X0.0 Y2.19 Z3.3 F354.159 G1 X-0.66 Y2.11 Z3.3 F354.159 G1 X-0.66 Y2.29 Z3.3 F354.159 G1 X-1.32 Y2.29 Z3.3 F354.159 G1 X-1.32 Y2.11 Z3.3 F354.159 G1 X-1.98 Y2.29 Z3.3 F354.159 G1 X-2.64 Y2.29 Z3.3 F354.159 G1 X-2.64 Y-3.4 Z3.3 F354.159 G1 X-1.98 Y-3.4 Z3.3 F354.159 M108 R25.0 <--- Reversal speed M102 <--- Extruder on reverse G04 P125.0 <--- Reversal pause M103 <--- Extruder off G1 X-3.3 Y2.11 Z3.3 F708.318 <--- move to next thread M101 <--- Extruder on forward G1 X-3.3 Y2.29 Z3.3 F354.159 <--- BLOB FAIL G1 X-3.96 Y2.28 Z3.3 F354.159 G1 X-3.96 Y2.11 Z3.3 F354.159 M103 <--- Extruder off
The pcregrep progam (do a sudo apt-get install pcregrep on Ubuntu) can find the blob-causing sequences after you generate the G-Code:
pcregrep -n -M 'G04.*\nM103\nG1.*\nM101\nG1' Caliper.gcode
You need that program, because ordinary grep only searches within a single line. In this case, the G-Code pattern extends over several lines. The pcre stands for Perl Compatible Regular Expressions and the -M turns on multi-line matching.
The results look like this:
905:G04 P125.0 M103 G1 X-3.3 Y2.11 Z3.3 F708.318 M101 G1 X-3.3 Y2.29 Z3.3 F354.159 1101:G04 P125.0 M103 G1 X-3.3 Y2.13 Z3.96 F651.721 M101 G1 X-3.3 Y2.29 Z3.96 F325.861
You can count the number of blobs with the -cl options.
Having found the blobs, edit the file, jump to the indicated lines, copy the nearest preceding forward extruder move, including the speed setting, and paste it in front of the M101 that starts the extruder. If my sed-fu were stronger, I could automate that process.
Unleashing pcregrep on my collection of G-Code files shows a bunch of ’em with blobs and a few without. Note that this has nothing to do with the firmware running on the printer, because the G-Code has the error.
What happens, I think, is that Reversal emits a correct reverse at the end of a thread, does a fast move to the start of the next thread, notices that (at least) the first G1 of the new thread falls below the length threshold that would activate the un-reversal action, and incorrectly assumes that it need not run the extruder forward to restore working pressure. The to-be-printed G1 commands all seem to be very short in the failing G-Code files I’ve examined.
Setting the reversal threshold to 0.0 should avoid triggering this error. I’ve verified that it produces correct G-Code for two parts that didn’t work before, but that’s not conclusive proof.
I’ve looked into reversal.py and fixing (heck, finding) this error lies beyond my abilities.
This is now Issue 175 on the ReplicatorG tracker…
The Smell of Molten Projects in the Morning 
Fantastic find! I was wondering why it did that move to some odd spot then ooze out a huge blob…
I am just printing the X Rod mount for my cupcake, a piece I use to testing settings changes as it has many features and doesn’t take too long to print.
So far the blobs are gone entirely!
Once again, what a fantastic bit of advice. Too bad the response to your issue was, no fix, use it as a workaround :(
Now that is good news, indeed!
I’ve never been quite sure what the Threshold setting was good for and had been gradually decreasing it. Perhaps it was to avoid inserting Reversal delays between threads that were so close you’d never notice the ooze?
Setting it to zero doesn’t seem to inject many more Reversals, perhaps because the (few) objects I’ve tested it on aren’t very big and don’t have much fill. In any event, eliminating the blobs counts for more than a few more seconds of print time!
Perhaps they’ll change the default to 0.0?