G92 not working for E axis

[dc42]

Did you select the tool with a T command (e.g. T0) before sending the G92 E command?

Please share the modified GCode file which includes the G92 E command.

Btw using relative extrusion would have avoided this issue.

[wcj97]

@dc42 I actually had not thought to make sure the tool was selected, however, upon trying that, the command still does not seem to work. I did not include the G92 command in the edited gcode file, instead I was typing it in the console to set my axes' positions before starting the gcode file. G92 works for setting positions on my other axes (X, Y, and Z), just not my E drive. In the future I will likely change to relative extrusion, but in this case I had to work with a preexisting gcode file which was using absolute positioning.

[dc42]

It would still help to see the GCode file. There may be something in it that is resetting the extruder coordinate. Editing the G92 E command into the GCode file immediately before the first printing move should work.

[Guyaros]

I'm also familiar with a bug that G92 Ennn doesn't change the E-axis coordinate.

As a workaround, I always use relative extrusion moves.
(you should set "Relative extrusion" checkbox in the slicer).

You could try to replace E-axis with W-axis, and this may also be a workaround.

[dc42]

@guyaros said in G92 not working for E axis:

I'm also familiar with a bug that G92 Ennn doesn't change the E-axis coordinate.

I don't recall anyone ever having reported that. G92 E0 certainly works, and the code is written to handle general E-values.

[Guyaros]

Hi David,

How would you explain this behavior?

[dc42]

The extruder values reported by M114 are actual extrusion amounts since the print started. They are not affected by G92 E commands. How they relate to the E values in successive G1 commands depends on the extrusion factor set by M221 and by any tool mixing that is in effect.

[wcj97]

@dc42 said in G92 not working for E axis:

It would still help to see the GCode file. There may be something in it that is resetting the extruder coordinate. Editing the G92 E command into the GCode file immediately before the first printing move should work.

I will try that, and if that does not work I will come back here with a copy of my code.

[Guyaros]

@dc42 said in G92 not working for E axis:

The extruder values reported by M114 are actual extrusion amounts since the print started. They are not affected by G92 E commands. How they relate to the E values in successive G1 commands depends on the extrusion factor set by M221 and by any tool mixing that is in effect.

Thanks for clarifying that, I thought its a bug.

Nevertheless, I don't understand how could I check that G92 Ennn.nn does make an effect.
I thought E is just an Axis that has coordinate, so by typing G92 E1234.5 the E coordinate should be changed accordingly.
So basically E is not treated as a regular axis like X,Y,Z,W?

[dc42]

No, E is not a regular axis, it is a "virtual extruder position", used only when the GCode file uses absolute extruder coordinates. In the early days of 3D printing, absolute extruder coordinates made some sort of sense, because the absolute extruder coordinate multiplied by the E steps/mm was the number of steps the motor had moved since the start of extrusion. Now that we have M221 to adjust the extrusion amount, pressure advance, nonlinear extrusion, and mixing extruders, the firmware has to convert the requested extrusion to relative, adjust it for the M221 correction, adjust it for mixing, adjust it for nonlinear extrusion, adjust it for pressure advance, and convert it to a step profile for that move. So absolute extruder coordinates make no sense now. But they compicate the firmware, because whenever the print stream is interrupted (for a simple pause, power failure etc.), the virtual extruder position has to be saved and then restored at the appropriate moment. This means that the virtual extruder position has to be included in every move descriptor, which increases the memory requirement.

It would be much simpler if everyone used relative extruder coordinates.

We could include the virtual extruder position in the M114 report, but it isn't as useful as reporting the filament actually consumed since the start of the print.

[Guyaros]

@dc42

Thanks for the very informative reply, now it makes sense to me.
Personally, I don't need the extruder position in M114, but it may be useful for others.

When I had the need to control the extrusion absolute position - for example for a "syringe extruder" which has maximum travel (syringe max stroke), I configure W-axis that act as an extruder.

[botanic2000]

Has run into same issue with E-axis today. Was trying to set up print resuming after power loss and found out that RRF is ignoring G92 command in the "resurrect.g" file.
Basically, what happens is when I resume printing after power down the print head goes over the print and then it starts extruding all the way from 0 to the value that has been stored in "resurrect.g".

What am I doing wrong here?

Firmware Version: 2.01(RTOS) (2018-07-26b2)

1_1537273182573_resurrect-prologue.g 0_1537273182573_resurrect.g

[dc42]

@botanic2000 said in G92 not working for E axis:

Has run into same issue with E-axis today. Was trying to set up print resuming after power loss and found out that RRF is ignoring G92 command in the "resurrect.g" file.
Basically, what happens is when I resume printing after power down the print head goes over the print and then it starts extruding all the way from 0 to the value that has been stored in "resurrect.g".

What am I doing wrong here?

Firmware Version: 2.01(RTOS) (2018-07-26b2)

1_1537273182573_resurrect-prologue.g 0_1537273182573_resurrect.g

Please post the ResTest.gcode file too, or put it on a file sharing site so that I can download it.