Thing-O-Matic: Broken G0 Semantics in RepG 25

I upgraded to ReplicatorG 25 and the Thing-O-Matic promptly got weird: the initialization code slowed to a crawl. The motors ran fine, the motion was properly coordinated, but the thing moved at a minute fraction of its normal 100 mm/s.

This was most obvious on the first move to the center of the stage after homing the axes. If you peer into the source code, that instruction looks like this:

G0 X0 Y0 Z10	    (pause at center to build confidence)

The comment tells you exactly why I put that move in there when I first started tinkering with start.gcode: I long ago discovered that automation doesn’t always do what you want, so having a simple verification at the first opportunity sometimes pays off big.


A bit of rummaging showed that RepG 25 has changed the semantics of G0, which is supposed to be a fast move to the programmed coordinates. Now G0 moves at the feed rate set by the most recent G1 and also accepts an F parameter, which it shouldn’t. I suspect somebody refactored the code and didn’t notice that G0 isn’t supposed to work exactly like G1.

There’s a RepG ticket for that.

The current start.gcode, just for future reference…

(---- start.gcode begins ----)
(MakerBot Thing-O-Matic with aluminum HBP and Z-min platform switch)
(Tweaked for TOM 286 - Ruttmeister MK5 stepper extruder mod)
(Ed Nisley - KE4ZNU - May 2011)
(- set initial conditions -)
G21		(set units to mm)
G90		(set positioning to absolute)
(- begin heating -)
M104 S210 T0	(extruder head)
M109 S110 T0	(HBP)
(- coarse home axes -)
G162 Z F1000	(home Z to get nozzle out of danger zone)
G161 Y F4000	(retract Y to get X out of front opening)
G161 X F4000	(now safe to home X)
G92 X-53.0 Y-59.0 Z117.0	(set XYZ coordinate zeros)
(- fine home axes)
G0 X-51 Y-57 Z115 F400	(back off switches)
G161 Y F200
G161 X F200
G162 Z F200
G92 X-53.0 Y-59.0 Z117.0	(re-set XYZ coordinate zeros)
(- manual nozzle wipe)
G0 X0 Y0 Z10	    (pause at center to build confidence)
G4 P500
G0 X40 Y-57.0 Z10	(move to front, avoid wiper blade)
G0 X56            (to wipe station)
G0 Z6.0           (down to wipe level)
M6 T0			        (wait for temperature settling)
G1 Y-45	F1000		  (slowly wipe nozzle)
(- Make sure the XY position matches the G92    )
(- home Z downward to platform switch)
G0 X56.4 Y7.6 Z3	    (get over build platform switch)
G161 Z0 F50	          (home downward very slowly)
G92 X56.4 Y7.6 Z1.50   (set Z height)
G0 Z6.0			          (back off switch to wipe level)
(- start extruder and re-wipe)
G0 X56 Y-45     (set up for wipe from rear)
G1 Y-57.0 F1000 (wipe to front)
M108 R2.0	      (set stepper extruder speed)
M101		        (Extruder on, forward)
G4 P4000  	    (take up slack, get pressure)
M103		        (Extruder off)
G4 P4000  	    (Wait for filament to stop oozing)
G1 Y-45	F1000		(slowly wipe nozzle again)
G0 X0           (get away from wiper blade)
(- manual splodge)
(G0 X0 Y-58)		  (to front center)
(G0 Z0.5) 		    (just over surface)
(M108 R2.0)	    (set stepper extruder speed)
(M101)           (start extruder)
(G4 P1500)       (build up a turd)
(- inhale filament blob)
(M108 R25)	      (set reversal extruder speed)
(M102)           (Extruder on, reverse)
(G4 P50)
(M103)		        (Extruder off)
(- build some pressure)
M108 R2.0	    (set stepper extruder speed)
M101           (start extruder)
G4 P50       (run for a bit)
(---- start.gcode ends ----)

I suppose I must add a feedrate parameter to each G0 as a workaround. Drat.

8 thoughts on “Thing-O-Matic: Broken G0 Semantics in RepG 25

  1. Thanks Ed for blogging this. I was just wondering if I should muddle through the problems with an upgrade to Rep 25. Now, I won’t. Because I can print today and I want to print tomorrow. Not debug workarounds (grin).

    1. Yeah, it seemed like a good idea at the time: RepG 25 has improved shininess!

      I’d installed RepG 25 on my crash test dummy machine and it worked OK, but that one doesn’t actually drive the printer.

      Skeinforge seems to emit G1 for everything, but a few instances of G0 crop up here and there, mostly in the Makerbot start & end gcode files for Cupcakes. I suspect nobody’s hit those cases yet.

  2. 100mm/sec, what!?! That’s crazy fast. I assume the bot isn’t printing at that speed… right?

    1. I actually got up to 80 mm/s, but the results weren’t all that good: too much moving mass, not enough rigidity.

      Moving from point to point at 100 mm/s works just fine, though.

      The Ultimaker prints well over 100 mm/s, with a much lower moving mass and AFAICT better mechanical design.

        1. Having two aluminum plates on the top adds more mass than I’d like, but the fact of the matter is the woodenware’s rigidity really isn’t up to much more than 40-ish mm/s anyway.

          And it looks like we’ve converged on the same first layer speed: something under 20 mm/s seems to be upper limit, particularly for parts with interior holes. That’s on clean, hot Kapton tape, which works just about as well as that horrible ABS coating I’d been using in the Pink era…

Comments are closed.