Incorrect extrusion amount on slow and/or small axis moves

ardenpm

@deckingman Yes I understand your description but my understanding was that is what you were assuming what is happening rather than what is intended to happen. To me it is surprising that the extruder limits are overridden by the axis limits, to me that is a fundamental property of G1 that should be describe somewhere (if it isn't already).

Testing just now I think what I am definitely seeing is the extruder racing up to its limits in order to try and match the movement axes, exactly as @deckingman describes. To me this seems counterintuitive and I would have expected the slowest axis to dictate the movement regardless of whether it is the extruder.

On review I am also seeing some skipping at 480mm/m which I didn't notice before so I'll probably cap that at 300mm/m, though even at that speed the axes are two far out of sync to stop the extruder racing away.

One option might be to reduce the maximum speed on the B axis temporarily in my prime Gcode to prevent this, I guess I can work out how much time the extruder needs to properly extrude the amount of filament I want then work out the fastest I can allow that axis to move while covering the distance needed.

@tfjield looks like you are correct, I just dropped minimum down with M203 I1 and did a move of 1mm and that now takes around a minute as expected instead of 2 seconds. So if G1 was working how I originally though (which it seems it is not) then it would have only been able to slow the axis to 30mm/m at the most, which is still pretty slow but no where near slow enough to extrude 50mm of filament.

gloomyandy

@ardenpm The way that fedrate is applied to moves that include extrusion is not very obvious (and a little confusing), see https://3dprinting.stackexchange.com/questions/14668/details-of-marlins-feedrate-calculation for another description of what is probably going on...

ardenpm

@gloomyandy Mmm, this adds to the confusion for me since that description matches what my original assumption was:

Moves with a nonzero X, Y, or Z component: the feedrate is an ideal, desired speed in 3 dimensions, possibly limited by the max feedrates of each axis (including E) individually, as well as their acceleration profiles.

Specifically they say it is limited by the max feedrates of each axis, including the extruder. Though I guess since I am commanding it to move at a feedrate that is below all axes limits the moves are not limited at all, so the extruder is running up to its 3600mm/m limit. That lines up with what @deckingman was assuming as well.

In some testing now I can see if I artificially limit my movement axis speed limit the extruder can then keep up then I'm able to get a smooth axis movement over the length of the extrusion. However I need to calculate the expected time of the extrusion move, determine how slow to limit the movement axis to to make it take the same time and then limit its feedrate (then restore it afterwards). This does seem to work though.

deckingman

@ardenpm
To understand it fully, you need to be able to comprehend the concept of 4 (or more) dimensional space (something that I find hard to do).

...........my understanding was that is what you were assuming what is happening rather than what is intended to happen.

No, I'm not assuming anything. I had a similar query regarding the speeds of my UVA and B axis which run concurrently with X and Y but not necessarily over the same distances. This is how it was explained to me by @DC42 and he writes the firmware so he should know.

However I need to calculate the expected time of the extrusion move, determine how slow to limit the movement axis to to make it take the same time and then limit its feedrate (then restore it afterwards).

I've already told you how to that.

But hey, if you don't want to believe what I say, that's fine. I just wish I hadn't wasted so much of my time trying to help....

ardenpm

No, I'm not assuming anything. I had a similar query regarding the speeds of my UVA and B axis which run concurrently with X and Y but not necessarily over the same distances. This is how it was explained to me by @DC42 and he writes the firmware so he should know.

Great, that is what I was trying to ask (perhaps clumsily), I wasn't sure if this was known expected behaviour of the firmware or what you were trying to deduce from my explanation of what I was seeing (which could have meant a bug). Obviously if David says that's how it works, then that's how it works.

However I need to calculate the expected time of the extrusion move, determine how slow to limit the movement axis to to make it take the same time and then limit its feedrate (then restore it afterwards).

I've already told you how to that.

Yes, and that's exactly what I used to do it, which was a very helpful idea (I just threw together a spreadsheet to do it by hand but should be able to put that into Gcode pretty easily as well). I only now had the opportunity to test it out. It also took me a few read throughs to fully grasp what was being proposed. I was just reiterating that what is needed is possible but requires some of the juggling you mentioned.

But hey, if you don't want to believe what I say, that's fine. I just wish I hadn't wasted so much of my time trying to help....

I'm not sure what gave that impression, your explanation and idea were definitely of help and appreciated.

ardenpm

So putting this together now that it is clear what's going on, I'm using a small macro which takes the same B, E and F parameters as my G1 calls but computes the feedrate limit for me, changes it then sets it back to the original value. This seems to be working well and I can now do a nice smooth drop of my priming platform while extruding at the needed rate. Obviously fairly specific to my use case but in case it's helpful to anyone else here it is.

var defaultSpeed = move.axes[4].speed
var extrusionTimeMinutes = param.E / param.F
var newSpeed = abs(param.B - move.axes[4].userPosition) / var.extrusionTimeMinutes
echo {var.newSpeed},{move.axes[4].userPosition},{param.B}
if var.newSpeed < var.defaultSpeed
  M203 B{var.newSpeed}
  G1 B{param.B} E{param.E} F{param.F}
  M203 B{var.defaultSpeed}
else
  G1 B{param.B} E{param.E} F{param.F}

Thanks all for the lively discussion.

gloomyandy

@ardenpm Wouldn't it be easier just to compute a new feedrate and use it directly (as an F parameter) rather than setting a limit and relying on the firmware to apply it?

ardenpm

@gloomyandy No, because I don't want to limit the E axis to that feedrate, I want it to run at the specified rate but the B axis much slower than normal. Without this the E axis will run up to its limit to try and sync with the short B axis move time. Without doing this I need to slow down the E axis too much.

deckingman

@ardenpm I see what you are doing but why not keep it simple and just set M203 E300 (to set say 5mm/sec), then do the G1 move and use M203 E3600 (to restore the feedrate value)?

ardenpm

@deckingman Yes, that’s true I could also do that. I’ll need to use the object model to find the current tool to apply it to the right extruder motor so that should be possible. I haven’t confirmed that limiting the extruder instead of the movement axis has the same affect but I would assume it must. I would still set the limit of the extruder though to the feedrate I actually want since otherwise it would just always run at 300 (I have multiple steps at different feedrates in my case). But limiting the extruder is simpler and shouldn’t hit the other minimum speed issue. I’ll definitely give that a go.

deckingman

@ardenpm You could by-pass using the object model by setting the maximum extrusion rate for all extruders. So for example M203 E300:300:300:300 and then put them all back with M203 E3600:3600:3600:3600.

ardenpm

@deckingman I prefer to restore the feedrates to their previous value rather than a hard coded value when done so if I change my configuration I don't need to hunt for values in my different macros. However that should be pretty straight forward, something like this.

var defaultSpeed0 = move.extruders[0].speed
var defaultSpeed1 = move.extruders[1].speed
var defaultSpeed2 = move.extruders[2].speed
var defaultSpeed3 = move.extruders[3].speed

M203 E{param.F}
G1 B{param.B} E{param.B} F{param.F}
M203 E{var.defaultSpeed0}:{var.defaultSpeed1}:{var.defaultSpeed2}:{var.defaultSpeed3}

Which is definitely still simpler than the first macro I had there. Definitely lots of ways to skin this particular cat.

fcwilt

@ardenpm said in Incorrect extrusion amount on slow and/or small axis moves:

@gloomyandy No, because I don't want to limit the E axis to that feedrate, I want it to run at the specified rate but the B axis much slower than normal. Without this the E axis will run up to its limit to try and sync with the short B axis move time. Without doing this I need to slow down the E axis too much.

If B and E are not kept in sync how do you see that working? Would E just continue to run after B is done?

Thanks.

Frederick

ardenpm

If B and E are not kept in sync how do you see that working? Would E just continue to run after B is done?

@fcwilt That's actually the issue, it does attempt to keep them in sync and it thinks on the extruder side it has enough headroom to run it all the way up to my configured maximum speed of 3600mm/m for extruders, where as my extruders can handle more like only 300mm/m without skipping.

The reason the extruders are configured to allow a speed much higher than they can actually extrude is because of retractions, which happen at a much faster speed than extrusions. So by limiting the extruder temporarily to the limit for practical extrusion it should force the movement axis to slow down further to say in sync.

fcwilt

@ardenpm said in Incorrect extrusion amount on slow and/or small axis moves:

If B and E are not kept in sync how do you see that working? Would E just continue to run after B is done?

@fcwilt That's actually the issue, it does attempt to keep them in sync and it thinks on the extruder side it has enough headroom to run it all the way up to my configured maximum speed of 3600mm/m for extruders, where as my extruders can handle more like only 300mm/m without skipping.

The reason the extruders are configured to allow a speed much higher than they can actually extrude is because of retractions, which happen at a much faster speed than extrusions. So by limiting the extruder temporarily to the limit for practical extrusion it should force the movement axis to slow down further to say in sync.

Does your slicer have a place you can enter code during a retraction? Some of them do.

That would solve the speed problem as you could set the extruder speed to the max for extrusion and in the retraction handler up the speed during retraction and then put it back to normal.

Frederick

tfjield

@fcwilt Or he could use firmware retraction.

fcwilt

@tfjield said in Incorrect extrusion amount on slow and/or small axis moves:

@fcwilt Or he could use firmware retraction.

How does that handle the speed issue?

Thanks.

Frederick

tfjield

@fcwilt Oh, you're right, I was thinking backwards. I forgot that he wants to limit extrusion to below the max, not retraction.

ardenpm

Does your slicer have a place you can enter code during a retraction? Some of them do.

@fcwilt I don't believe PrusaSlicer has custom G-code for retraction.

That would solve the speed problem as you could set the extruder speed to the max for extrusion and in the retraction handler up the speed during retraction and then put it back to normal.

I don't really see doing the above as too big a problem in any case since it's only for these specific priming moves which already have a fairly large amount of Gcode scripting around them, so it's just a few extra lines.