Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add volumetric extrusion limit option #17017

Conversation

MoellerDi
Copy link
Contributor

@MoellerDi MoellerDi commented Feb 28, 2020

I'm having very little coding experience, so please be patiently with me if the quality is not at the expected level.

Description
This PR will add an option (M200 Ln) to allows to configure volumetric based extrusion limits in cubic millimeter per second (mm^3/sec) for the extruders.

Please note, this PR was tested and works fine on my CoreXY w/ single extruder (non mixing). IMHO this PR needs more testing especially on mixing extruder as well as on printers with more extruders.

Requirements
Sadly there is still an issue that E axis is moving very very slow sometimes (due to configured volumetric based extrusion limits and in case of joined segments). I have no idea how to resolve it properly, therefore I use a workaround in my local config by setting MIN_STEPS_PER_SEGMENT 1

Benefits
Someone was asking for an option to set extruder volumetric limit w/o limiting given feedrate of E axis only moves (e.g. retraction). So this PR is just an (my) idea on how this could be implemented ;-)

It might help to prevent print failures and especially print jams, we need to be able to set a volumetric based extrusion limit. It's a value, measured in cubic millimeters per second (mm³/s), of exactly how much plastic can be extruded per second from your extruder and based on how fast the filament can physically melt in your hotend. If you exceed that limit, your printer will skip, and then likely jam. 

IMHO using the printing speed settings of your slicer could be a misleading way to adjust print speed for 3D printers. How fast your print completes a 10 cubic millimeter print is entirely dependent on the how fast filament can be pushed through the nozzle.

Use of the head movement speed for adjusting print speed is based on CNC machines, where movement speed is everything, because nothing is extruding, you are cutting things. For 3D printing, you're most concerned with feeding filament for extrusion. You cannot exceed your printer's optimal extrusion rate for a particular filament or it will skip and likely jam your printer.

The volumetric based extrusion limit for a particular filament on a particular printer/extruder is a constant value. Being able to set a volumetric based limit for the extrusion rate is something you only need to do 1 time for a given filament, and a given printer configuration. It doesn't change, unless you change filament type, or change your printer configuration (e.g. replacing the nozzle by a bigger/smaller one).

Wouldn't it be great if one could adjust the layer height, extruder width, print speed or other slicer settings and not have to worry about a printer jam from exceeding the extruder's extrusion limit? No one likes to deal with a jammed printer/hotend. By having such settings, we greatly limit the possibility of jamming our printers when we fiddle with settings.

Related Issues / feature request:
I found some open issues / feature request ; see #6295 #16927

@MoellerDi MoellerDi force-pushed the bugfix-2.0.x-PR-volumetric_extrusion_limit branch 2 times, most recently from d6fe340 to b4e5d46 Compare February 28, 2020 22:22
@MoellerDi
Copy link
Contributor Author

@thinkyhead thanks for the cleanup; it's much better that way ;-)
Btw, I have not yet touched the EEPROM_VERSION; shall I ?

@MoellerDi MoellerDi force-pushed the bugfix-2.0.x-PR-volumetric_extrusion_limit branch from d61029b to 0aff434 Compare March 6, 2020 09:50
@MoellerDi
Copy link
Contributor Author

rebased on bugfix-2.0.x; still no idea how to avoid MIN_STEPS_PER_SEGMENT 1 as workaround

@MoellerDi MoellerDi force-pushed the bugfix-2.0.x-PR-volumetric_extrusion_limit branch from b052e90 to 1507c3f Compare April 13, 2020 09:28
@MoellerDi
Copy link
Contributor Author

Still no idea how to avoid MIN_STEPS_PER_SEGMENT 1 as workaround, therefore I have added a sanity check to ensure MIN_STEPS_PER_SEGMENT is set to 1 if VOLUMETRIC_EXTRUDER_LIMIT is enabled.

@MoellerDi
Copy link
Contributor Author

I'm printing (single extruder) for several weeks with this PR (including MIN_STEPS_PER_SEGMENT 1) w/o issues. Next I will add a spare feeder and migrate to dual extruder (single nozzle) as it's on my list for long time anyway.

@thinkyhead
Copy link
Member

Sorry this has taken so long. There have been an unusual number of things ongoing lately. Re-reviewing…

@thinkyhead thinkyhead force-pushed the bugfix-2.0.x-PR-volumetric_extrusion_limit branch from cec172f to cfad3d0 Compare June 8, 2020 06:19
@thinkyhead
Copy link
Member

The only change I added was to retain compatibility with previous D behavior. If you send D0 it works like S0 (and doesn't actually set the diameter to 0). If you send D<number> then it will enable volumetric extrusion. If you only want to set the D value but keep volumetric off, also include S0.

Backward-compatibility is always a concern, so this seems the best way to keep that behavior while also being able to use S to turn it on and off when needed.

@thinkyhead thinkyhead merged commit bac7602 into MarlinFirmware:bugfix-2.0.x Jun 8, 2020
@thinkyhead thinkyhead changed the title Add option to allow volumetric based extrusion limits Add volumetric extrusion limit option Jun 8, 2020
@Evg33
Copy link
Contributor

Evg33 commented Jun 8, 2020

Bug with EEPROM.
SKR1.4T

SENDING:M502
echo:Hardcoded Default Settings Loaded

SENDING:M500
echo:Settings Stored (751 bytes; crc 10471)

SENDING:M501
Error:EEPROM datasize error.
[ERROR] Error:EEPROM datasize error.

echo:Index: 731 Size: 751
echo:Hardcoded Default Settings Loaded
echo:Settings Stored (751 bytes; crc 10471)
echo:EEPROM Initialized

@Evg33
Copy link
Contributor

Evg33 commented Jun 8, 2020

#18229

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants