Thing-O-Matic: Skeinforge Reversal Failure

As it turned out, though, that part wasn’t the first attempt.

Caliper part - heavy blobbing
Caliper part - heavy blobbing

Even switching to red filament didn’t help:

Extrusion blob - top view
Extrusion blob - top view

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.

Extrusion blob - side view
Extrusion blob - side view

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
G1 X-3.3 Y2.11 Z3.3 F708.318
G1 X-3.3 Y2.29 Z3.3 F354.159
1101:G04 P125.0
G1 X-3.3 Y2.13 Z3.96 F651.721
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 and fixing (heck, finding) this error lies beyond my abilities.

This is now Issue 175 on the ReplicatorG tracker…

5 thoughts on “Thing-O-Matic: Skeinforge Reversal Failure

  1. 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 :(

    1. So far the blobs are gone entirely!

      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?

Comments are closed.