G92 E<number> doesn't update DWC or OM

ChrisP

I'm using D3+SBC 3.01-RC11 | DSF 2.1.3 | DWC 2.1.6 and as the title says, issuing G92 E0 for example, doesn't seem to update the current position on either DWC or in the OM (M409 K"move.extruders[0].position").

I'm currently tying to figure out why I can't get volumetric extrusion to behave properly (his is another story) and have been trying to track down the problem by writing some manual g-code. As part of this I'm using G92 E0 to monitor the extruder position at various points. However, I've discovered that the only way to get the E position to update is to use G1 commands.

The count is clearly working in the background as using absolute extrusion mode can be used to check that the extruder position is being set correctly, I just don't see that it's being updated correctly elsewhere.

gtj0

@ChrisP Confirmed. G92 E<anything> appears to no to update the OM. I'd add this to the RRF 3.01RC11 thread.

ChrisP

@gtj0 Thanks for confirming I'm not going mad. While I still believe this is a bug, interestingly if you issue an M114, there are two E values - one simply labelled "E" and one labelled "E0" that tracks the OM and DWC. Therefore, I'm not sure is what we're seeing is intentional somehow...?

bot

I think this is intentional. Otherwise, with relative extrusion, the value would basically always be zero with perhaps a flash of an extrusion value if your refresh rate caught it right.

ChrisP

@bot
That's be interesting as I've only every used relative extrusion and I've never noticed this behaviour before and the behaviour remains in absolute extrusion mode too. You've got me questioning myself now though... gona go try it on a D2 Wifi and Duet 0.6....

ChrisP

@bot said in G92 E<number> doesn't update DWC or OM:

I think this is intentional. Otherwise, with relative extrusion, the value would basically always be zero with perhaps a flash of an extrusion value if your refresh rate caught it right.

Hmm, so looks like you're absolutely right and that I've just never noticed this - I've just check on a D3 with 3.01-RC11 and a v0.6 running 1.26.1 and they all act the same.

I'm not sure I follow though regarding the value always being zero. Why would you expect the E axis to behave differently to X, Y or Z if they were running in relative mode? Indeed with any of X,Y,Z or E, you can move using absolute or relative commands, so I'm a little confused as to why the current E displacement/counter would behave differently and why it should be correct that if I tell the E axis that its at 0 mm but it displays that it's at 150 mm (for example).

bot

Maybe I'm just totally involved with the way IceSL generates extrusion values, but basically relative extrusion resets the e axis to 0 immediately after every commanded move.

It's like setting G92 E0 after every single G1 XYZE command.

So, only for that brief instant where the G1 xyzE value is in memory the axis will be "at" that value.

So, presumably, for that same reasoning, people may just want to see the actual extrusion movement that has taken place, ignoring any coordinate resets, either per-layer or per-move.

dc42

@ChrisP said in G92 E<number> doesn't update DWC or OM:

I'm using D3+SBC 3.01-RC11 | DSF 2.1.3 | DWC 2.1.6 and as the title says, issuing G92 E0 for example, doesn't seem to update the current position on either DWC or in the OM (M409 K"move.extruders[0].position").

I'm currently tying to figure out why I can't get volumetric extrusion to behave properly (his is another story) and have been trying to track down the problem by writing some manual g-code. As part of this I'm using G92 E0 to monitor the extruder position at various points. However, I've discovered that the only way to get the E position to update is to use G1 commands.

The count is clearly working in the background as using absolute extrusion mode can be used to check that the extruder position is being set correctly, I just don't see that it's being updated correctly elsewhere.

The figure you are looking for (the one that G92 E0 resets, and is reported as just "E" by M114) is what RRF calls the "virtual extruder position". It's not currently reported in the OM, but I will add it in RRF 3.01 stable.

ChrisP

@dc42 said in G92 E<number> doesn't update DWC or OM:

The figure you are looking for (the one that G92 E0 resets, and is reported as just "E" by M114) is what RRF calls the "virtual extruder position". It's not currently reported in the OM, but I will add it in RRF 3.01 stable.

I spent yesterday evening looking through the RRF source to try to understand what the intended behaviour was and saw this - though thanks for confirming.

Looking at the code I see that absolute moves affect the "virtualExtruderPosition" and that relative ones don't (here). I then see (here) that a G92 E<value> affects only this "virtualExtruderPosition". At first I assumed that this was so that RRF could keep a track so that the required displacement could be calculated if an absolute extrusion is provided... but then I realised that the motion planner does that anyway since the M114 manages to keep a track irrespective of whether absolute of relative extrusions are used (here), it also tracked in "rawExtruderTotalByDrive[]" too.

So I guess the few questions I have, out of interest as much as anything, are:

what is the virtualExtruderPosition actually used for? RE your comment, I'm not sure this would be figure I'm looking for as I rarely (if ever) use absolute extrusion and relative extrusion doesn't seem to touch this variable.
why doesn't G92 act on the actual extruder position of the currently selected extruder(s)? I'm probably missing something, but it seems really odd to instruct the extruder of it's absolute position (using G92) and not have that reflected on DWC.
is there some other way to reset the Extruder Drives count that I'm missing?

I guess at the end of the day the printer still operates as expected so it's not a bug, it's just got me scratching my head a bit

dc42

@ChrisP said in G92 E<number> doesn't update DWC or OM:

At first I assumed that this was so that RRF could keep a track so that the required displacement could be calculated if an absolute extrusion is provided

Correct, that's what it is for.

... but then I realised that the motion planner does that anyway since the M114 manages to keep a track irrespective of whether absolute of relative extrusions are used (here),

No, because the actual extruder movement is not the same as the virtual extruder movement except in simple cases. It gets modified by the extrusion factor (M221), mixing ratio (M567) and volumetric extrusion (M200).

it also tracked in "rawExtruderTotalByDrive[]" too.

No, because those values are not reset by G92 E0. They can't be, because they are used to track print progress.

dc42

I have put new internal builds of RRF at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0 that report the virtual extruder posiion in 'move.virtualEPos'.