Reversal Zits: Analysis

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:

PPW - Clip gaps

PPW - Clip gaps

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

PPW - Reversal zits

PPW - Reversal zits

This microscope shot shows the outie zits in grisly detail:

PPW - outie zits

PPW - outie zits

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

PPW - outie - right

PPW - outie - right

Skeinlayer shows the nozzle motions around that zit:

PPW outie zit - right breast top - skeinlayer

PPW outie zit - right breast top - skeinlayer

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:

PPW inne zit - left waist - skeinlayer

PPW inne zit - left waist - skeinlayer

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?

About these ads

  1. #1 by Rob Giseburt on 2011-08-14 - 01:12

    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

    • #2 by Ed on 2011-08-14 - 09:55

      replictorg does some additional crap to make RPM work.

      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.

      (Switch to 40, and use Dimension instead of Reversal.)

      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!

  1. Reversal Zits: Speed Variations « The Smell of Molten Projects in the Morning
  2. KG-UV3D GPS+Voice: Box Model « The Smell of Molten Projects in the Morning
  3. SJFW: Initial EEPROM Configuration File « The Smell of Molten Projects in the Morning
  4. Reversal Zits: Speed, Acceleration, and a Bestiary « The Smell of Molten Projects in the Morning
  5. Makergear M2: Pink Panther Woman | The Smell of Molten Projects in the Morning