The New Hotness

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…