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…
