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?
I think saving to s3g and using the s3g “decompiler” may reveal more than the gcode alone, since replictorg does some additional crap to make RPM work.
The RPM commands are *not* making it to the ‘bot, btw. The firmware is capable of doing proper 5D, btw. You just need to change the machines.xml and skeinforge settings. (Switch to 40, and use Dimension instead of Reversal.)
-Rob
The reversals seem to be straightforward:
Move to (-618,-362,14784,-1,0) in 20595 us (relative: 8)
Move to (0,0,0,75,0) in 125000 us (relative: 1F)
Move to (-626,-253,14784,0,0) in 26042 us (relative: 8)
Move to (0,0,0,-75,0) in 125000 us (relative: 1F)
Move to (-528,-351,14784,-5,0) in 110332 us (relative: 8)
Given that simplicity, I’m not sure where an unexpected delay might hide… although that’s a working definition of unexpected, I suppose.
Turns out I’ve been using SF40 all along, figuring that it would have less (or at least up to date) breakage compared with 35, and have resisted the temptation to fiddle with Dimension while cranking out tchotchkes.
The next few posts will rule out two other possible zit sources, so I’ll have a clear field when I get around to trying Dimension.
Thanks for the nudge; I should have switched to Dimension long ago!