How to limit extruder feedrate without limiting retraction speed
-
@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.
-
@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.
-
@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....
-
@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
-
@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).
-
@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.
-
@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.....
-
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.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
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.
-
You could try changing the limits as part of your load/unload code?
-
@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).
