How to limit extruder feedrate without limiting retraction speed

[Phaedrux]

This sheet will help you figure out your max print speed to stay within your volumetric limit.

https://docs.google.com/spreadsheets/d/1ZHSRzTm2AR_sXnLSSOq2NSmx0UYtF5bJKHUSFWiDscA/edit#gid=0

I wish all slicers were volumetrically aware. Far as I know, only Slic3r/PrusaSlicer allow you to set a volumetric limit which will limit print speed automatically. For other slicers you must be aware of the print speed limit yourself.

[mildw4ve]

Limiting X and Y axis speeds is a solution, but its not perfect. As stated before, machines are sometimes used by less advanced users and there are many scenarios in which limiting XY speeds instead of limiting extruder speed will not prevent mishaps. I don't want to prevent users from experimenting with the profiles, with unlimited max extruder speed a simple layer height increase will break the profile as the extruder will not be able to keep up with the higher material flow. Increasing print speed during printing could break a print as well. In my eyes finding a way to limit max extrusion speed to a safe value without limiting retraction should should be a nice solution. I'm just unsure what is the best way of achieving this.

[Adrian52]

@Phaedrux kisslicer has a volumetric limit

[Phaedrux]

@mildw4ve said in How to limit extruder feedrate without limiting retraction speed:

machines are sometimes used by less advanced users

They won't become more advanced if the limitations are hidden from them. If the extruder speed is limited as you suggest, then printing speed will have to reduce to maintain it.

@mildw4ve said in How to limit extruder feedrate without limiting retraction speed:

I'm just unsure what is the best way of achieving this.

Use a slicer with a volumetric limit function?

[Danal]

We are not communicating somewhere here.

A large part of what a G-Code controller does with g-code is coordinating all the axes specified in a given G1 command so they move exactly together. X and Y and E must remain in sync throughout the move. (The controller also 'looks ahead' to the next move(s) to keep things moving smoothly, but that's another whole story).

It is not possible to change the coordination (e.g. ratio) of extruder speed to XY speed and still get a good print. When the nozzle tip covers a certain distance of XY, the amount of plastic that emerges from the nozzle MUST be 'matching', or the little thread that results will be too thick, or too thin.

The other part of your original question: Can I retract faster than I print? Is a resounding "yes". With no firmware changes. Look inside a typical print job. Extrusion looks like this:

G1 F1800 X69.4 Y95.407 E9.49909
G1 X69.391 Y96.013 E0.03024
G1 X69.351 Y96.537 E0.02622

It has XY moves and E moves on the same G1 command line. Small, positive E Moves. In this case, all at a feedrate of 1800 (mm/min) (or 30 mm/sec, if you prefer).

Retracts look like this:

G1 F2400 E-6.5

A large negative move, E only, and a higher feedrate. Placed there by the slicer. (Cura, in this case). Feedrate of 2400mm/min = 40mm/sec, which is exactly what I set for retracts in Cura.

To be super clear:

• What you are asking for regarding retract speed is already implemented and does not involve firmware doing anything special. Firmware honors the speed the slicer puts on the retract move.
• What you seem to be asking for in extruder speed while printing is a non-sequitur.

[mwolter]

What about firmware retract? Does it honor the maximum extruder speed set by the firmware?

[deckingman]

@mwolter said in How to limit extruder feedrate without limiting retraction speed:

What about firmware retract? Does it honor the maximum extruder speed set by the firmware?

Yes. To elaborate, firmware retraction can use any extruder feed rate up to the maximum limit that has been set in config.g

[mildw4ve]

@Phaedrux said in How to limit extruder feedrate without limiting retraction speed:

They won't become more advanced if the limitations are hidden from them. If the extruder speed is limited as you suggest, then printing speed will have to reduce to maintain it.

I'm perfectly fine with max extruder speed imposing a limit on XY axis speeds. Car manufacturers often electronically limit max car speed to a specific value above which tires could break apart. Another example could be a combustion engine rev limiter which also in theory limits performance but also prevents mishaps.
I want to do something similar by limiting max extruder speed to a value above which the extruder will not work properly anyway by either skipping steps or losing traction on the filament.

@Phaedrux said in How to limit extruder feedrate without limiting retraction speed:

Use a slicer with a volumetric limit function?

The feature is not worth enough to warrant a slicer change just for this feature (I would lose other important features to gain this one), which is why I'm looking for a way to limit this in DUET/RRF.

@Danal
Are You saying that if I use M203 E600 to limit extruder speed to 10mm/s, that limit will only work for printing moves and not for retraction moves? That is what I want to achieve but from the tests I run a few months back that wasn't the case with stock firmware at the time and retraction moves were limited to 10mm/s.

[Danal]

@mildw4ve said in How to limit extruder feedrate without limiting retraction speed:

@Danal
Are You saying that if I use M203 E600 to limit extruder speed to 10mm/s, that limit will only work for printing moves and not for retraction moves? That is what I want to achieve but from the tests I run a few months back that wasn't the case with stock firmware at the time and retraction moves were limited to 10mm/s.

No. I'm saying that firmware honors the speed that is set with the F parameter on any given move, up to the limit of whichever axis hits the limit first during a multi-axis move. I'm further saying that that is the very definition of coordinated movement. G-Code cannot work any other way, and still be G-Code.

The fact that you want firmware to limit an axis to one speed when the motor is rotating in one direction and a different speed when rotating the other way sounds very clear when phrased as "print v retraction"... but... when peeled back one layer to how that could be implemented, that simply isn't how coordinated movement works.

It is rather like asking how you smell the color 9.

And... as mentioned, faster retraction than print? Already there.

[deckingman]

@Danal Actually, I think I get what @mildw4ve wants to achieve. I'm not saying that I agree it's the best way to achieve it but there might be some merit in it. But it would need a firmware change. Essentially it's no different from what we already use when we have XYE print moves but use faster speeds for non-print moves which are XY only (no E). We already have M204 which gives us the ability to use different "per axis" accelerations for print and travel moves, so I guess what the OP would like would be separate "per axis" speed limits for print and non print (retraction) moves.

Or alternatively, firmware based volumetric extrusion limit applied only to (XYE) print moves, rather than slicer based. It's not a feature that I would use myself, but then neither are many other features such as bed levelling or flatness compensation. I can see how an OEM might want it.

[Danal]

@deckingman said in How to limit extruder feedrate without limiting retraction speed:

separate "per axis" speeds for print and non print (retraction) moves

Retraction moves already have separate speeds.

Multi-axis moves cannot have different speeds and remain coordinated. Perhaps you meant a separate "upper limit" per axis on a move, so that coordination limits XY if E hits its limit first? And that E only upper limit applies only to extrusions and does not cap retractions?

As you point out, it would seem to be possible to do this, have an E only, forward only, upper limit (separate from other upper limits). And let regular coordination occur, so that if E limits the move, that's OK.

I use the word "seem" because having firmware truly understand "forward only" becomes a bit iffy. Are we implying that positive vs. negative coordinates tell us extrude v retract? What about G-Code that uses absolute coordinates? Would the firmware look for a move to a number less than the prior move? What if the G-Code flips between absolute and relative, or resets the absolute to zero? Both are common in code that I've seen.

Having G-Code specify a feedrate is fundamental to G-Code.

Having the firmware parse things that are 'implied', like negative numbers or 'smaller than prior' (and when is prior reset), and take action in the background... it is certainly possible to code that into the firmware... but... hidden actions are quite opposite of how G-Code is supposed to work, and the full "decision tree" of sensing each direction will become extremely complex.

IMHO, invisible background actions based on complex criteria are bad.

[deckingman]

@Danal I don't think anyone is talking about uncoordinated, multi-axis moves. It's simply a matter of limiting the speed of any coordinated multi axis moves to a maximum extruder speed. But at the same time allowing extruder only moves to have a different speed limit. An extruder only move is simply a G1 Enn Fnn (or G10/G11 when using firmware retraction) without any other axis being involved. Whether that be an absolute or relative E move is irrelevant - from a firmware view point, all extruder moves have to be relative to the last one in any case. I don't get your concern about negative numbers or "smaller than prior". At all times we would respect coordinated G-Code. It's simply a matter of, just as we do now, imposing a firmware speed limit which is currently the lowest of X Y or E for coordinated multi axis moves, but allowing a higher speed limit for extruder only G1 Enn moves. It's not a complex criteria nor is it any more hidden than most other firmware actions.

But I don't personally care one way or the other - I'm just saying that the OP has a point which IMO is valid from an OEM perspective who wants to limit the damage that inexperienced users might be capable of. On that note, I'm out....

[Danal]

@deckingman said in How to limit extruder feedrate without limiting retraction speed:

extruder only G1 Enn moves

Magic words!

Having separate speed caps for SINGLE AXIS (any single axis) moves vs MULTI AXIS moves strikes me as very effective, very implementable, avoids the hidden complexity that was my concern, and would resolve OPs needs. See below for a couple of brainstorms on how to put this in M203.

@deckingman, you've done your usual thing and provided a perspective that leads a larger discussion to a very good place. Thank you for hanging in there.

We should add this to the firmware wishlist.

M203 today has axis letters, and speeds. Potentially speeds with colon seperator if there are multi drives for that axis. Example

M203 X25000 Y25000 Z400 E4000:4000 U10000

We could add... a new config code?

M203 X25000 Y25000 Z400 E4000:4000 U10000 ; Upper limit, multi axis moves.
M20? E8000:8000 ; Upper limit, single axis moves, such as retracts and un-retracts.

We could add... a new separator?

M203 X25000 Y25000 Z400 E4000.8000:4000.8000 U10000 ; Upper limit, multi axis moves (dot) Upper Limit, single axis moves

[deckingman]

@Danal No worries - we were communicating but I think it might have been a case of being "divided by a common language". We were both initially sceptical, but I think that we now agree that the OP has a valid point.

@mildw4ve There is no current way of doing what you want but it's likely that it could be done with a change to firmware. It's now up to @DC42 to decide if and when he can implement it. Suggest you add a request to the firmware wish list along the lines of what @Danal proposes above which would be a separate maximum speed parameter for any single axis move (not just extruder because there might be other usage cases in the future which none of us has as yet thought about).

[Phaedrux]

@deckingman said in How to limit extruder feedrate without limiting retraction speed:

extruder only G1 Enn moves.

This assumes that the slicer retraction moves will be extruder only moves. But what about "wipe on retract"? A small travel move is inserted along with the retraction to wipe the nozzle. Firmware would need to also look for XY moves with a negative E move.

I can see some other unintended consequences due to monkeying with the gcode after the slicer has handed it off. Bridging flow rates come to mind, which are often much higher than normal print flowrates.

Minimum layer time cooling algorithms would also be unintentionally modified.

I understand the feature desire of the OP, but I think philosophically that this belongs in the slicer rather than the firmware. All slicers should be volumetrically aware. It's the slicer that has access to the full print parameters and the algorithms for generating the gcode. If the slicer doesn't have a concept of the volumetric limit it's missing a key piece of information, with the assumption that the user is going to provide a print speed selection within reason.

Besides, if it gets added to the slicer, it's applicable to all firmware and electronics, rather than just a feature of a single firmware.

Just my opinion.

[deckingman]

@Phaedrux I confess that I hadn't considered the wipe-on-retract scenario, nor Z hop that some people use.

But as for "monkeying around with the gcode after the slicer has handed it off" - setting a speed limit is something we already do - or at least we can do, by setting a maximum axis speed in config.g that might be lower than the speed set by the the slicer. There is nothing outlandish being asked for here. It's just having the ability to set two (machine based) speed limits instead of one. One speed limit would be applied as it is now for coordinated multi-axis moves. The second speed limit would apply to single axis moves only. My personal preference would be to have this handled by firmware because these speeds limits are machine based, rather than based on the characteristics of the object being sliced.

Effectively what the OP is asking for is firmware based volumetric flow limiting, rather than slicer based. You say "Besides, if it gets added to the slicer, it's applicable to all firmware and electronics, rather than just a feature of a single firmware.", yet as you have already pointed out, some slicers have that capability already.

If the feature was added to the firmware, it gives him the ability to use whatever slicer he (or his users) chooses, rather than having to pick a slicer that has this capability. Isn't that sort of flexibility one of the main advantages of Duet firmware? To my mind, this is just like firmware retraction. We can choose to use it or rely on the slicer retraction instead. Duet firmware gives us this choice and with the added advantage that if we choose the firmware version, we can tune and adjust it "on the fly" whereas with all slicer settings, the only way to effect any changes is to re-slice and re-print from scratch.

But personally volumetric extrusion limiting, whether slicer based or firmware based, isn't something that I would use, so I'm not going to argue the case any further - I'll leave that up the OP.

Edit. To be clear, volumetric extrusion limiting would be set by using the existing M203 command to set the maximum extrusion feedrate. Any new command would be to allow a different, higher speed to be used for retractions. And on that note, I really am out of here.....

[dc42]

Bear in mind that setting a low limit on positive E moves and a higher one on negative E moves (which I think is what @mildw4ve is asking for) would also make filament loading very slow. Reprime moves are also positive extruding moves, and for those I don't think you would want to apply the low speed limit. So if this were to be implemented, it would have to apply only to moves with positive extrusion and X or Y movement.

[mwolter]

In my option (whatever it's worth), I could see a separate "retraction speed" be beneficial as it would allow faster retraction and reload where filament pressure is not a concern.

I really see two different types of extruder movement that could potentially need different max speeds.

First, extruder movements that generate filament pressure (and are likely to make the extruder skip) such as printing, filament load macros, and filament purge macros. Let's call these "pressure moves".

And the other would be movements that do not generate pressure such as filament retraction and reload. Let's call these "non-pressure moves".

What if the pressure moves remained subject to the speed set in M203. And non-pressure moves could only be made faster if they were done via firmware retraction? This would keep the normal extrusion speed at a lower rate to keep the pressure in the hotend low and help prevent the extruder from skipping but allow quicker retraction where pressure is not typically an issue.

Allowing this new max retraction speed to only be used for firmware retraction would keep filament load/unload or purge macros that do generate filament pressure limited by typical M203 max rates. This would keep all commands that generate filament pressure subject to M203 max rates and firmware retractions could be limited by a new higher max rate.

In short, anything that generates filament pressure is subject to M203, and firmware retraction and reload would have a new max speed since it doesn't generate pressure.

[A Former User]

You could try changing the limits as part of your load/unload code?

[Danal]

@dc42 said in How to limit extruder feedrate without limiting retraction speed:

Bear in mind that setting a low limit on positive E moves and a higher one on negative E moves (which I think is what @mildw4ve is asking for) would also make filament loading very slow. Reprime moves are also positive extruding moves, and for those I don't think you would want to apply the low speed limit. So if this were to be implemented, it would have to apply only to moves with positive extrusion and X or Y movement.

Which is a very good reason to separate "single" vs "multi" axis moves (and not Pos/Neg).