My Experience with Relative extrusion (Problem and Solution)

MegaAndy

Since I got my Duet Maestro a few weeks ago I had been struggling with setup of motors and extrusion.

I was able to print simple square/straight objects fine some curved objects and infill could sometimes be largely under extruded in places.

Just last night I had finally realised what was happening. I had not realised until yesterday that previously with Marlin I had used absolute extrusion and Reprap defaults to relative extrusion, Cura had correctly switched to relative so the gcode was fine.

What I think was happening is that with relative, there were lines of gcode with extremely small extrudes due to tight curves, if they were smaller than the threshold of one microstep no extrusion would occur. So even if within a curve there would be a large amount of these small extrudes none would actually happen as they are all under the amount of one step. On absolute extrusion I expect that even if it misses a few extrudes due to being too small it will catch up when the absolute value reaches the threshold.

Once i had realised what was going on, the solution seems simple, up the microsteps. I was on 16 Interpolated and went straight to 256 microsteps instead. I printed something that was failing constantly and the under extrusion was gone.

alt text

Apologies if this is extremely obvious but it took me a lot of failing and head scratching to work this out. The solution seems perfectly logical but it makes me wonder whether the firmware should really build up extrusions that are too small until they can be handled with your steps per mm (I suppose if this was the case you may as well be using absolute extrusion).

DeltaCon

That actually makes sense, and I think it might be the cause of some problems I am having when printing smaller layerheights. I do not have the luxury of so many microsteps (Duet 0.6) but I makes me think if it is not better to go the absolute extrusion way instead of relative. I have read, long time ago, that relative extrusion was the preferred method, but I lost the "Why?". Maybe someone can shed some light on this.

MegaAndy

That reminds me, this is at 0.12mm layer height so will have smaller extrusions due to this.

Also, my Motor is not geared and 1/8deg. At 16x the steps per mm is 100, other motors will have a higher step per mm value even at 16x microstepping.

bot

I wonder if generating a minimum of a single microstep for the E axis if a too-low or zero value is commanded in gcode would solve this, and not cause other (major) issues.

My thoughts about this would be: Over-extrusion is a better failure mode than under-extrusion, and the resolution of the E axis would dictate how much error is acceptable, whereas with under-extrusion in this case, the print becomes pretty much failed.

burtoogle

This is a very common problem. Even when using absolute extrusion, low extruder resolution (steps/mm) causes serious quality issues. Using 2.85mm filament makes it even worse. People expect to be able to print tiny thin lines using weeny layer heights and wonder why the result is all lumpy or even missing completely.

Actually, RRF/DWC could report when G1 lines are asking for such small extrusions that the quality will be affected. It would be quite nice if the GUI displayed a red symbol when that situation is detected.

deckingman

This is something that I've done a fair bit of research into because when using a mixing hot end such as I do, one can have mixing ratios as low as 1%. So one of the inputs may only be extruding 1% of the filament.

Just be aware that setting the steps per mm too high can lead to problems hitting the maximum step pulse frequency of 200 kHz (200,000 steps per sec). You won't see that during normal printing extruder moves but you will during retract and unretract moves. So for example, using a Bondtech or E3D titan extruder which normally has around 400 steps per mm @ 16X then at 256 X micro stepping, the steps per mm become 6,640 which limits the extruder speed to a maximum of 30mm/sec before you hit the 200 KHz limit.

MegaAndy

@deckingman

Thanks for the info, I presumed I may run into issues by going too high but thought I may as well go very high to see if this was the solution for this particular issue. I'll keep an eye on it. My stepper is 100mm at 16x so is 1,600 at 256x, so I suppose should be ok until about 120mm/s.

deckingman

@megaandy Yes, you should be OK with that. If you hit the limit it'll show as high "hiccups" count when you run M122. So you can run a few retract/unteract cycles then do M122 as a check.

Phaedrux

@megaandy I've noticed this problem with under extrusion due to too small print moves as well, but I hadn't made the connection to absolute/relative extrusion. That deserves some more testing. It makes sense that it would catch up eventually, but if the individual print moves are still too small, won't they still get missed regardless?

The best argument I've seen made for relative extrusion was by @mhackney and can be found here: http://www.sublimelayers.com/2017/10/to-extruder-relative-or-not-to-extrude.html

In your case with such a low e steps per mm would be more susceptible to the problem, as you note, but it's still there even with a Titan Aero and 400 step motor at x16 microstepping (814ish esteps). x256 stepping seemed to work out really well for you, but as @deckingman notes you can quickly hit the step limit on retracts. x64 or x128 microsteps might be a good middle ground in this case. You can use M122 to check for hiccups. A few aren't much of a problem, but you don't want to miss too many steps (that's the problem we're trying to solve in the first place afterall.)

This calculator will be helpful to determine how fast you can retract without hitting the step limit. https://wilriker.github.io/microstep-calculator/ Thanks to @wilriker

deckingman

Just to add that if you think about it, the firmware has convert absolute E moves to relative E moves - so it's dubious whether you actually get any better resolution by choosing absolute.

DeltaCon

@deckingman said in My Experience with Relative extrusion (Problem and Solution):

...the firmware has convert absolute E moves to relative E moves

I don't think firmware converts anything. It just interprets gcode E-values to be relative to the previous value, or absolute. It has to correspond to the uploaded gcode, that's where the real difference is made.

@MegaAndy, That's exactly where I read about it before indeed! There is an interesting comment below Michaels blog, from James Hockney. I tried to invite Michael to respond to that in regard of this thread. I hope he will post here too.

sigxcpu

@deltacon said in My Experience with Relative extrusion (Problem and Solution):

@deckingman said in My Experience with Relative extrusion (Problem and Solution):

...the firmware has convert absolute E moves to relative E moves

I don't think firmware converts anything. It just interprets gcode E-values to be relative to the previous value, or absolute. It has to correspond to the uploaded gcode, that's where the real difference is made.

You are now here and you want to go there (absolute). How can you go from here to there if you don't compute the steps between here and there which means relative?

DeltaCon

@sigxcpu said in My Experience with Relative extrusion (Problem and Solution):

You are now here and you want to go there (absolute). How can you go from here to there if you don't compute the steps between here and there which means relative?

I don't think (firmware-technically) it makes a big difference whether you go from 0 to 10 (relative) or from 123456780 to 123456790 (absolute). Both ways the steps are calculated, aren't they?

dc42

In fact there is some code to keep track of pending extrusion, i.e. the amount of extrusion that remains to be done after the amount of it that corresponds to a whole number of microsteps has been done. But I'll check whether that code is working as intended.

When using an extruder with low steps/mm such as @MegaAndy is using, higher microstepping is advisable anyway, to help combat the poor extruder resolution. Upgrading the motor to 0.9deg would be even better, if you can find a 0.9deg motor with sufficient torque.

RRF converts absolute extrusion commands to relative extrusion. In the very early days of 3D printing, there was some point in using absolute extrusion, to avoid this kind of problem. But now there are several variable modifiers (extrusion factor, mix ratio, pressure advance, nonlinear extrusion) that mean a simplistic approach of converting E values to an absolute number of steps no longer works.

DeltaCon

@dc42 said in My Experience with Relative extrusion (Problem and Solution):

RRF converts absolute extrusion commands to relative extrusion

@sigxcpu I guess I should have kept my keyboard quiet...

deckingman

Just to add that absolute values are still relative. It's just that absolute values are relative to when the extruder was last zeroed (usually at the start of a print), whereas relative values are relative to the last move. In order for the firmware to instruct the extruder to move nnn millimetres of filament, it must subtract the absolute value for the previous move from the absolute value for the current move to calculate what "nnn" is, and therefore it becomes a relative (to the previous move) value - which is what I meant when I said "if you think about it".

brunofporto

Thank you!!!!! this explains a lot of issues I am having with small layers highly detailed prints failing horribly!!!!!!!!

MU current steps/mm for extrusion is around 90 (16x interpolated) I'll change to 256 microstpes and give it a try

MegaAndy

@brunofporto

Great, good luck! This is exactly why I wanted to get this solution online so it may help others

dc42

I can confirm that the code was not working as intended. I have implemented a provisional fix, and subject to testing that will be included in the 2.02 firmware release.

Meanwhile, I suggest choosing extruder microstepping so that the number of microsteps/mm is in the 400 to 1000 range.

MegaAndy

@dc42
Thanks for the info,

Nice to hear my theory was correct and that this post has helped fix a software issue !