Marlin: [FR] Shouldn't firmware retraction ignore max feedrate for E?

[DerSchultze]

Normally I set the max feedrate for my extruder, to match the volumetric limit of my extruder, this way it is possible to slice e.g. infill at insane speed, and have the printer limit the speed to the melt capacity of the hotend.

Problem is that firmware retractions is limited by max feedrate, so until recently I have been running on a modified firmware to overcome this.
But wouldn't it be natural for firmware retractions to ignore the max feedrate?

[Sebastianv650]

I don't think so. The max. Feed rates should always be the mechanical upper limits, everything else should be defined by the slicer. If you break this rule, you may end up with several maximum feed rates that only confuses the users.

[DerSchultze]

I agree that you shouldn't have redundant tuning parameters, and you would still only have one general setting for maximum feedrate. Defining these for ZY and Z is pretty straightforward, but for the extruder it's more imaginary.
You could do it while the extruder is spinning freely, but this probably wouldn't match the maximum obtainable feedrate with filament loaded in the extruder, and it would be nowhere near your extrusion rate. So what is actually the maximum feedrate for the extruder? It's a bit up th the user's preference.

My reasoning for suggesting to keep retraction feedrates separate from the general maximum extruder feedrates, is that you tune your retraction settings anyway, and you are likely to get away with faster retracts than your normal feedrates, because you have tension on the filamant when retracting.
And you would be able to limit the maximum extrusion rate on the fly, without having to reslice, just as you can fiddle with G10/G11 parameters, steps/mm, etc. while the print is running.

[magnuspub]

I would like to have this feature!
My e3dv6 don't run over 7mm/s during long extrusion and if i could retract very fast my extruder won't ooze

[shb]

How is this proceeding, if it is at all? Anyway I also totally subscribe to the suggestion. Retraction feedrate can usually be much higher than printing (sustained extrusion) feedrate, and the higher the better.

The firmware could:

• Have additional "Vmax E (retraction)" for the extruder(s)
• When a retraction is done the retraction Vmax is applied
• Keep track of the total negative extrusion
• When positive extrusion is done keep the retraction Vmax until the positive movement compensates for the negative extrusion
• Revert back to standard Vmax

This should integrate equally well with slicer-based retraction and firmware-based retraction.

[thinkyhead]

How is this proceeding, if it is at all?

No one has submitted a PR yet. We're focused on bug-fixes at this time in preparation for the final 1.1.x release, and we'll invest some time in this idea once that is behind us.

[TopiRinkinen]

Hi,

I made a quick mod for this.

Took baseline 1.1.9.
Modified files are at:
https://drive.google.com/open?id=1-qKJ13rEQI1FSH5uSXY8RZfdtYJDiKaG
and:
TEST_E_RETRACT.zip

At Configuration.h, adjust parameter TEST_E_RETACT_MAX_NEG_E_FEEDRATE for max retract speed.

// Testing different VMax for E when speed is negative (retract) =>
#define TEST_E_RETRACT
// Define one value for each extruder:
#define TEST_E_RETACT_MAX_NEG_E_FEEDRATE {10}
// <= Testing different VMax for E when speed is negative (retract).

makes max speed for negative E-axes speed to obey this value, instead of DEFAULT_MAX_FEEDRATE.

Worked with my quick test.

Mod is still needed to allow faster speed during de-retract, up to close to the point when the extruder starts extruding again.

Br, -Topi

[DerSchultze]

I actually have a working mod that I have been using for the past year or so.

My plan was to get my repo updated and submit a pull request, within a couple of weeks.

[TopiRinkinen]

Hi,

Here is another.

If G10/G11 are enabled, then M207 & M208 F-rates override M203 max speeds.
Actually, to make sense, the M207 & M208 should have separate speeds for E and Z, but this seems to work if properly set.

fwretract.zip

Br, -Topi

[boelle]

@DerSchultze so with the pr merged on 17/9-2018 is this one "fixed"?

[DerSchultze]

Unfortunately not.. the code had changed too much, and in my effort to get my repo up to date, I ran out of git foo. And I never got back to make a new fix.

[boelle]

@DerSchultze what i was wonder are if the PR merged has fixed things or if this "issue" is still relavant

[MoellerDi]

IMHO this "issue" is about separate configurable limits for the extruder for when it's actually pushing filament through the hot end and when it's not. During normal extrusion, Marlin would enforce the first limit (which is presumably lower), and would enforce the second when doing things like retraction and loading/unloading filament, which can be faster due to the lack of back pressure on the filament.

For example, I have set max extruder speed (max E feedrate) to 50mm/s, but I know there's no way it could achieve that while actually pushing filament though the hot end. I just hope/assume the slicing process will result in reasonably (limited) feedrates.

[thinkyhead]

The max feedrate is related to the physical limit of the extruder when not pushing filament. It's unlikely we will add a separate limit for active extrusion. There doesn't seem to be a pressing demand to apply lower limit during active printing, and the risk seems to be exceedingly small.

[ctmakro]

when tuning print speed on-the-fly, the material extrusion rate sometimes exceeds the maximum allowed by the extruder, generating a slip (a crack sound from the extruder motor) and leave an under extruded line on the print, which decreases the strength of the finished print.

my extruder can extrude at a maximum speed of 4mm/s. but if I M203 that value, then i'm left with a slow and ineffective retraction speed. the optimal retraction speed is around 50mm/s.

i'd like love die to have such a feature, as that saves me a lot of trouble of estimating maximum extrusion rate mid-print to prevent under extrusions while maximizing print speed.

[boelle]

@DerSchultze so this is now more a feature request?

[DerSchultze]

Initially It was more a design question, but yes it basically is a feature request.

Firmware retracts shouldn't be subject to limits set by M203, as this effectively prevent you from limiting your extrusion on the fly as @ctmakro describes, while still maintaining a functional firmware retract.

There is no reason to have a separate limit for retracts, as this would be redundant to the retraction speed itself specified by M207 and M208 which you dial in anyway.

On my printer I run a rather old firmware which I have hacked to temporally raise the max E speed, when retract/recover is happening, but the code has evolved a lot since then, and I haven't had the time/knowledge to make a updated fix/pull request. And it most likely shouldn't be done in the G-Code parsing section, where I have implemented my hack.

[MoellerDi]

@DerSchultze I was working on PR #17017 to implement such or similar feature. That PR got merged yesterday. So once enabled in configurations file, you can use M200 Lx.xx to set volumetric limits of your extruders, max feedrate should match the mechanical upper limits. Limits set via M200won't affect any retraction moves.
Please kindly check if it resolves your FR.