My Experience with Relative extrusion (Problem and Solution)

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 !

bot

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

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.

Can you elaborate on what behaviour was intended, what was actually happening, and how the behaviour will be now that it's fixed?

Thanks!

Iamturbo1978

@MegaAndy, Thank you for bringing this up, I have been trying for months to remove an issue with blobbing(or zitz). I've tried everything I could think of, and I tried everything others suggested. But I could not get rid of my problem. Then I changed my microstepping from 16 to 128, and the problem went almost away. I still have to do some tuning, but so far I am liking the results.

DeltaCon

I read on the https://reprap.org/wiki/Duet the following: "Microstepping is locked to 1/16. Board throughput is always sufficient to handle it, including on 0.9° steppers.". So, I guess upping microsteps is not possible for "us" who are using 0.6 and 0.85 boards. Changing to 0.9 degree stepper could work, but I understand that they have less torque. So changing to a geared extruder might be advisable?

wilriker

@deltacon The question is: how much torque do you need? Torque primarily has an influence on maximum acceleration. And even then it might surprise you how few of a torque is required for certain accelerations.

You could use my Maximum Acceleration Calculator to find out.

P.S.: On the other hand 0.9° steppers have higher back EMF so you would probably get lower maximum speed.

fundix

@MegaAndy thank you! This is great idea! Today I will test it.