[Solved] G92 E0 causes a lot of extrusion.

[AlanKilian]

I'm getting a big blob at the end of each layer caused by the G92 E0 command and I'm confused.

I've attached a .gcode file for a 20mm flat plate and I get a blob.
If I comment out the G92 E0 at the end, I do not get the blob.

Can someone help me understand this?

Rostock Max V3
FW Version 0.92.2
Octoprint

Square.gcode

(8.15 KiB) Downloaded 232 times

Square.stl

(1.63 KiB) Downloaded 211 times

[geneb]

G92 doesn't do anything that would result in the issue you're seeing. It's simply setting the position of "E" (the extruder "axis") to zero without commanding any moves whatsoever.

See here for more info: http://reprap.org/wiki/G-code#G92:_Set_Position

g.

[AlanKilian]

OK, I found out it's the G92 E0 combined with a G28 X0 that causes the extrusion.

Could you try this?

Set your extruder temp to whatever filament you have and wait for it to heat up.

g0 x0 y0 z50 ; Move near the bed.
g1 x100 e10 f1000 ; Move to the right and extrude some filament
g92 e0 ; Set Extruder current position to zero
g28 x0 ; Home the "x" axis

I see a slow move towards X==0 with the extruder running!

If I remove the g92 e0 from the above test, I see a slow move towards X==0 without the extruder running

[Jrjones]

Why are you homing just the X axis on a delta machine?
I would remove the X0 from the G28 command.

[IMBoring25]

That does sound like the issue. A single-axis home operation is likely something not really considered in the firmware development.

[Eric]

OK, I found out it's the G92 E0 combined with a G28 X0 that causes the extrusion.

Could you try this?

Set your extruder temp to whatever filament you have and wait for it to heat up.

g0 x0 y0 z50 ; Move near the bed.
g1 x100 e10 f1000 ; Move to the right and extrude some filament
g92 e0 ; Set Extruder current position to zero
g28 x0 ; Home the "x" axis

I see a slow move towards X==0 with the extruder running!

If I remove the g92 e0 from the above test, I see a slow move towards X==0 without the extruder running

You're running into move queue processing vs instant processing issues. You need either a G4 P0 or M400 (wait for queued moves to finish before processing more gcode) in front of the G92 command if you want it to behave as you expect.

Here, I'll go through your example to illustrate, red is the gcode being processed, green is what's actually happening:

g0 x0 y0 z50 ; Interpret Gcode, queue move command Printer gets move from queue and starts moving
g1 x100 e10 f1000 ; Interpret Gcode, queue move command Printer is still doing first move
*** You want G4 P0 here! ***
g92 e0 ; Interpret Gcode, not a move command, so immediate execution. CURRENT extruder position set as 0 Printer is still doing first move
g28 x0 ; Interpret Gcode, queue move command Printer is still doing first move
No more Gcode Continue processing moves until move queue is empty

Does the behavior make sense now?

[AlanKilian]

I'll try your test by adding a G4 P0 and post my results.

If a G1 followed by a G92 requires a G4 p0 in between them, the Slic3r is producing incorrect G code.
Here's a slice of G code produced by Slic3r. Is it really incorrect?

G1 X30.000 Y26.654 E36.69181
G1 X-30.000 Y26.654 E41.58977
G1 X-32.190 Y26.270 E41.77129
G1 E39.77129 F2400.00000
G92 E0
G1 X-29.205 Y19.205 F7800.000
G1 E2.00000 F2400.00000
G1 F1440
G1 X-29.205 Y-19.205 E5.13550
G1 X29.205 Y-19.205 E9.90365
G1 X29.205 Y19.205 E13.03915

[AlanKilian]

Why are you homing just the X axis on a delta machine?
I would remove the X0 from the G28 command.

Yes, this is the default end G code for the Slic3r slicer.
I changed it to a G28 Z0 and the problem went away.

[AlanKilian]

Here, I'll go through your example to illustrate, red is the gcode being processed, green is what's actually happening:

g0 x0 y0 z50 ; Interpret Gcode, queue move command Printer gets move from queue and starts moving
g1 x100 e10 f1000 ; Interpret Gcode, queue move command Printer is still doing first move
*** You want G4 P0 here! ***
g92 e0 ; Interpret Gcode, not a move command, so immediate execution. CURRENT extruder position set as 0 Printer is still doing first move
g28 x0 ; Interpret Gcode, queue move command Printer is still doing first move
No more Gcode Continue processing moves until move queue is empty

Does the behavior make sense now?

I added your suggested G4 P0 and it made no difference.

The extruder still runs when I issue the G28 X0

By the way, I'm typing these commands into a terminal window, so the moved are complete way way before I type the next one is.

[IMBoring25]

Why are you homing just the X axis on a delta machine?
I would remove the X0 from the G28 command.

Yes, this is the default end G code for the Slic3r slicer.
I changed it to a G28 Z0 and the problem went away.

It doesn't need a parameter at all. On a delta it's normally rendered as just G28.

[AlanKilian]

Cool. Just a G28 does not exhibit the problem.

I'll debug the Arduino code and see if I can push a fix to GitHub.

[joe]

So, what exactly is the bug you are going to decode?

[AlanKilian]

G28 X0 under certain circumstances causes the extruder to run and pump filament out the nozzle.
It should not run the extruder.

[Jrjones]

IMO you should never home just one tower on a delta.
If I tried that on my machine with the print head near the bed, I would expect that the X carriage would move up while the other 2 stay where they are, causing the print head to eventually hit a tower and cause the belt to start skipping.

A better fix would be to have G28 X##/Y##/Z## be interpreted as a normal G28 if the machine is configured as a delta.

[AlanKilian]

OK, I've got a one-line fix to Printer.cpp so there will be no extruder operation on homing.
G28 X0 first moves to X=0 and then homes in Z
G28 Y0 first moves to Y=0 and then homes in Z
G28 Z0 (or G28) moves directly vertical as it homes in Z

None of these extrude filament now.

diff --git a/Repetier Firmware/Repetier/Printer.cpp b/Repetier Firmware/Repetier/Printer.cpp
old mode 100644
new mode 100755
index 53e413c..19bced0
--- a/Repetier Firmware/Repetier/Printer.cpp
+++ b/Repetier Firmware/Repetier/Printer.cpp
@@ -1034,6 +1034,10 @@ void Printer::homeAxis(bool xaxis,bool yaxis,bool zaxis) // Delta homing code
// gratuitously fail due to incorrect settings.
// The following movements would be meaningless unless it was zeroed for example.
UI_STATUS_UPD(UI_TEXT_HOME_DELTA);
+
+ // For all homing operations, set the extruder target position to zero to avoid extruder operation
+ Printer::destinationSteps[E_AXIS] = 0;
+
// Homing Z axis means that you must home X and Y
if (homeallaxis || zaxis)
{

[IMBoring25]

Or just ignore all parameters on a G28 command if it's a delta configuration. I see no functional benefit to homing a single tower and it's begging for an eventual crash. If you want to center the effector before homing that would be better accomplished with a G1 X0 Y0.

[Eric]

I added your suggested G4 P0 and it made no difference.

The extruder still runs when I issue the G28 X0

By the way, I'm typing these commands into a terminal window, so the moved are complete way way before I type the next one is.

You're correct that wait commands are meaningless if you're typing commands manually and waiting for completion. I assumed you were executing a script, since that's how you presented it.

However, I see I came to the wrong conclusion now that I stopped and looked at what G92 actually does. All it does is modify offsets for subsequent gcode processing, so immediate execution isn't in conflict with anything after all. Apologies for that false trail, but I have run into situations where it does matter.

Glad you found the real culprit.


@Imboring, while the underlying code is special for delta movement, I'm pretty sure the X/Y/Z parameters on G28 still refer to the cartesian system, not individual towers.

[AlanKilian]

Or just ignore all parameters on a G28 command if it's a delta configuration.

I see no functional benefit to homing a single tower and it's begging for an eventual crash.

I think you're confused a little.

G28 doesn't home towers it homes axes.

So just like G0 and G1 can move along the X axis (and not along the X tower,) G28 can "home" the X axis by moving it to zero so there's no possibility of a crash at all.

That said, you're suggestion to ignore the parameter and force a G28 Z0 is a good one and maybe the software authors will consider it.
I don't actually know who writes this and if it's a fork of something else or what.

Anyway, I have a patch, I submitted a ticket and I'll just reapply the patch whenever I pull a new version from GitHub, so I'm good-to go.

ALSO, I changed slic3r to do a G28 Z0

[IMBoring25]

Axis homing is only even defined when the Cartesian axes are on independent carriages.

The RepRap gcode reference agrees, saying a delta can not home a single axis, so the axis parameters are simply ignored. This is apparently not completely true with the firmware version you are running.

Since all the axes on a Cartesian are independent and coaxial with their respective carriages and endstops, you can establish the coordinate system of a single axis for some reason or use a single-axis home to move a carriage outside the normal printable area. None of that is true on a delta, which needs a fully-established coordinate system for the kinematic equations to accomplish a Cartesian move and can accomplish a Cartesian move all the way to the endstops.

[Eric]

Can't use wikis as an authority. It's a collective documentation of how things actually see to work in various firmwares, after the fact, not before the fact. In other words, various firmwares did their own implementations, and then various individuals in the community tried to document it. The actual authority is the actual code in the firmware, and the intentions of the individuals who implement and maintain each firmware. They may or may not agree with you. And different firmwares may make different choices sometimes.

There is a defining standards document, but it predates delta printers, so delta issues aren't specifically addressed: http://ws680.nist.gov/publication/get_p ... _id=823374

Bottom line, don't get hung up on the software interface matching the actual hardware. Gcode is supposed to be portable, even if actual implementations screw up that ideal in many cases.

[AlanKilian]

I'd like to go back to another discussion about G4 P0 and command queues.

I will test this theory next week, but is Slic3r really generating incorrect G code by not adding a G4 P0 before every G92 E0?

If a G1 followed by a G92 requires a G4 p0 in between them, the Slic3r is producing incorrect G code.
Here's a slice of G code produced by Slic3r. Is it really incorrect?

G1 X30.000 Y26.654 E36.69181
G1 X-30.000 Y26.654 E41.58977
G1 X-32.190 Y26.270 E41.77129
G1 E39.77129 F2400.00000
G92 E0
G1 X-29.205 Y19.205 F7800.000
G1 E2.00000 F2400.00000
G1 F1440
G1 X-29.205 Y-19.205 E5.13550
G1 X29.205 Y-19.205 E9.90365
G1 X29.205 Y19.205 E13.03915

[geneb]

You know what G92 E0 does? It sets the value of the E axis to zero. It doesn't move anything.

The end code should be a G28 all by itself. G28 X0 is for a cartesian printer. (Which makes sense because you're using Prusa's fork of Slic3r, which is pre-configured for the i3 Mk2)

G28 X0 will cause the effector platform to wipe the nozzle across the surface of the part, pulling rapidly cooling filament out of the nozzle as it moves, leaving you with a blob.

g.

[Eric]

I'd like to go back to another discussion about G4 P0 and command queues.

I will test this theory next week, but is Slic3r really generating incorrect G code by not adding a G4 P0 before every G92 E0?

If a G1 followed by a G92 requires a G4 p0 in between them, the Slic3r is producing incorrect G code.
Here's a slice of G code produced by Slic3r. Is it really incorrect?

G1 X30.000 Y26.654 E36.69181
G1 X-30.000 Y26.654 E41.58977
G1 X-32.190 Y26.270 E41.77129
G1 E39.77129 F2400.00000
G92 E0
G1 X-29.205 Y19.205 F7800.000
G1 E2.00000 F2400.00000
G1 F1440
G1 X-29.205 Y-19.205 E5.13550
G1 X29.205 Y-19.205 E9.90365
G1 X29.205 Y19.205 E13.03915

You must have skimmed my previous response where I said I was was wrong about the need for G4 P0 in this case. My processing analysis remains the same, it's just that G92 only affects future gcode processing, so there's no actual conflict. The code above is probably fine. Note how the E parameter on G1's changes from E39.7 (a -2 retract) before the G92 to E2.0 (a +2 unretract) after the G92. Any queued moves are stored as deltas, so they shouldn't be affected by the reference point change.

A case where G4 P0 WAS needed was before servo commands for someone who had added a hobby-type servo-controlled feature to their printer The servo Mcode is immediate execution on a real-world motor, not synced or even part of the motion queue.

[AlanKilian]

G28 X0 will cause the effector platform to wipe the nozzle across the surface of the part, pulling rapidly cooling filament out of the nozzle as it moves, leaving you with a blob.

g.

If it's after a G92 E0, it also causes the extruder to run forwards and actively extrudes a large pile of filament onto the top of the part.
Depending on the length of the previous extrusion, it could be quite a large pile.

I created an issue on GitHub and posted a fix for this issue as well as have changed the Slic3r end G code to do a G28 instead of G28 X0

Thanks everyone, this has been a ton of help to me.

[geneb]

Once again, G92 E0 moves nothing.

g.