Author: Ed

The Pink Panther Woman provided a clear view of the Reversal zit problem. With Clip = 0.1, she has what looks like a horrible surgical scar on her left side that extends from groin to, uh, bosom, with the defect punching inward:

From bosom to collarbone, however, the scar consists of the usual Reversal zits extending outward:

This microscope shot shows the outie zits in grisly detail:

And another on her right side that’s nicely isolated:

Skeinlayer shows the nozzle motions around that zit:

The corresponding G-Code:

G1 X-13.14 Y-7.69 Z73.92 F1607.344
M108 R25.0
M102
G04 P125.0
M103
(</perimeter>)
(</boundaryPerimeter>)
G1 X-13.3 Y-5.37 Z73.92 F5357.814
M108 R25.0
M101
G04 P125.0
M108 R1.786
G1 X-11.21 Y-7.46 Z73.92 F1607.344
M108 R25.0
M102
G04 P125.0
M103
G1 X-0.81 Y16.67 Z73.92 F5357.814
M108 R25.0
M101
G04 P125.0
M108 R1.786
G1 X-0.1 Y16.9 Z73.92 F1607.344

The three highlighted lines correspond to the last Perimeter thread, the gray move to the Infill, and the first Infill thread. This was printed at 30 mm/s with 100 mm/s moves, so the Cool plugin has reduced the speeds from 1800 mm/min and 6000 mm/min to what appears in the code.

Reversal is doing exactly what it should: inhaling the thread at the end of the Perimeter, moving, then exhaling before starting the Infill. The result isn’t nearly as good as you’d (well, I’d) expect, though.

However, here’s what Skeinlayer shows for an innie zit at her waist:

The corresponding G-Code:

G1 X6.1 Y-12.63 Z49.5 F582.649
M108 R25.0
M102
G04 P125.0
M103
(</perimeter>)
(</boundaryPerimeter>)
(</nestedRing>)
M104 S190.0
M108 R2.0
(</layer>)
(<layer> 49.83 )
M104 S188.654
(<nestedRing>)
(<boundaryPerimeter>)
... snippage of XML baggage ...
(<loop> outer )
M108 R0.654
G1 X5.81 Y-11.93 Z49.83 F1962.126
M108 R25.0
M101
G04 P125.0
M108 R0.654
G1 X7.09 Y-11.11 Z49.83 F588.638

The first highlighted line is the last Perimeter thread on the previous layer, the second is the gray highlighted move to this layer’s Loop, and the third is the first Loop thread. The speeds here are even lower than you saw above; she has a rather slender waist.

As before, Reversal properly inhales the filament at the end of the previous layer. What’s new & different, though, is that the nozzle moves upward 0.33 mm immediately after finishing the Reversal motion. The result is a very small outward zit, plus the gap (probably) caused by the Clip setting.

What I don’t yet understand is why an in-plane motion causes such a large blob of ABS. It seems that there’s not much left, if a 0.33 mm upward motion can thin it to nearly nothing, but the outie zits seem to have plenty of plastic hanging out.

One obvious cause would be an inordinate delay between the end of the thread and the start of the Reversal action. The Arduino must (receive and) decode and execute the M108 G25.0 (or, more precisely, the S3G binary equivalent) before decoding and executing the M102 that starts the extruder motor, which could account for at least some of the problem. I want to blink an LED during the dead time between each command, slap that trace on a scope, and eyeball the command latency; given the number of I/O pins on an Arduino Mega, there should be plenty available.

Another possibility is mechanical backlash caused by the extruder’s 7:51 gear train. I’m not convinced that’s an issue, as herringbone gears do a good job of eliminating backlash and it feels eminently tight. I need a testcase that puts the backlash on a visible thread.

More study is obviously needed, huh?

The Skeinforge Clip plugin trims the ends of closed loops to eliminate the overlap. I’ve found that setting Clip > 0.1 causes openings in small circles that shows up in the Polyholes testpiece, so I generally run with Clip = 0.0.

Here’s a pair with Clip = 0.1 and Clip = 0.0:

As before, pretty much no difference.

Whenever what might possibly be a timing problem crops up, the first suggestion seems to be “Print from the SD Card!” because the communication USB link between the PC and printer is so fragile it can’t keep the printer fed properly. This seems odd to me and some recent findings indicate that the latency problem is largely due to a weapons-grade blunder in the Java stack, but I figured I’d try it to see what happens.

This rather garishly contrast-stretched image shows the zits along the left side of the right-hand critter’s dome, plus an assortment below their eyes. The one on the left was from the SD Card, the one on the right was through the USB link:

The zits may be a bit hard to see in the image, but I can’t see any difference in person, either.

For what it’s worth, I have never personally seen a problem that was resolved by printing from the SD Card. I think Linux does a better job of keeping the USB pipeline fed, despite Java’s baked-in RXTX delay, than Windows, but I really don’t have any data to support that. Other than that most of the complaints about USB latency seem to come from Windows users, that is.

Of late, the Thing-O-Matic has been producing very nice results with one annoyance: zits at the end of threads that seem to be caused by the Skeinforge Reversal plugin. That may be unjustly tarring it, so I’ve been running parameter variations while cranking out tchotchkes for an upcoming presentation.

This stack of Chalk Men shows the problem.

The bottom and top have my standard 25 rev/min, 125 ms Reversal settings and don’t look all that bad. The middle two have Oozebane turned on: lower = 1.0 and upper = 0.25.

Fairly obviously, 1 mm of Oozebane early start produces dangling strands and the corresponding 1 mm of early shutdown leaves just less than 1 mm of gap. Not useful.

Reducing Oozebane to 0.25 mm produces results only slightly worse than no Oozebane at all.

The rest of the thinly documented Oozebane parameter space doesn’t seem helpful. I think it was intended more for DC motor extruders than steppers, although it didn’t seem useful even then.

So Oozebane doesn’t seem to help.