-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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 Post Processing script to set initial extruder offset #18533
base: main
Are you sure you want to change the base?
Add Post Processing script to set initial extruder offset #18533
Conversation
Add check for early completion to end script faster.
"type": "bool", | ||
"default_value": "CuraApplication.getInstance().getExtruderManager().getInitialExtruderNr() != 1" | ||
}, | ||
"setT2ExtruderOffset": |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how about adding a parameter "enabled" to see if the extruder exist in the printer and then show the parameter to set the offset of extruder?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which Cura variable should I use to get the "enabled" state of an extruder index? I had tried to get the extruder enabled state previously but got an error trying to access the value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
try "machine_extruder_count"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried reading the value during getSettingDataString() in the "enabled" json field like below but it always evaluates to False
"setT1ExtruderOffset":
{
"label": "Set Extruder 2 Offset",
"description": "Set the initial offset of this extruder by Nozzle Switch Retraction Distance.",
"type": "bool",
"default_value": "CuraApplication.getInstance().getExtruderManager().getInitialExtruderNr() != 1",
"enabled": "CuraApplication.getInstance().getGlobalContainerStack().getProperty(\\\"machine_extruder_count\\\", \\\"value\\\") >= 2"
},
When I read the value normally right before the json string in getSettingDataString() it logs the correct values in cura.log
logthis = f'SetInitialSwitchedExtruderOffset machine_extruder_count {CuraApplication.getInstance().getGlobalContainerStack().getProperty("machine_extruder_count", "value")}'
log2= f'machine_extruder_count>=2 {CuraApplication.getInstance().getGlobalContainerStack().getProperty("machine_extruder_count", "value") >= 2}'
Logger.log("d", logthis)
Logger.log("d", log2)
I looked at the other plugins to find any "enabled" examples that call python and they only reference other settings fields. Is there a restriction on running Python in "enabled"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the Cura logs, it seems like "enabled" code is unable to call blacklisted methods that are only blacklisted for the json?
2024-04-24 23:41:39,953 - ERROR - [MainThread] UM.Settings.SettingFunction._safeCompile [77]: Use of illegal method extruderIds in function ("2" in CuraApplication.getInstance().getExtruderManager().extruderIds) for setting
2024-04-24 23:41:39,953 - ERROR - [MainThread] UM.Settings.SettingFunction._safeCompile [77]: Use of illegal method getProperty in function (CuraApplication.getInstance().getGlobalContainerStack().getProperty("machine_extruder_count", "value") >= 4) for setting
Description
This post processing script sets multi-extruder printers' initial extruder positions to the correct value after retracting the filament during start G-code.
Before priming a nozzle at the beginning of the print, the position of the filament in the nozzle is unknown but assumed to be between
switch_extruder_retraction_amount
and0
because the filament may have been retracted the extendedswitch_extruder_retraction_amount
length at the end of the last print (or not). When a print is started and the filament position is assumed to be 0 (at the nozzle already) no/underextrusion occurs forswitch_extruder_retraction_amount
distance of filament because the slicer assumes the printer is extruding filament when the filament is still moving down the heatbreak towards the nozzle.Normally multiple nozzles on a multi-extruder printer are primed by extruding some filament during the start g-code to ensure the filament is at a known position in the extrusion train. E.g. Prime by
switch_extruder_retraction_amount
+ a bit more.When the printer has more than a single nozzle, the extruders that are NOT the
initial_extruder_nr
need to be retracted byswitch_extruder_retraction_amount
after priming to avoid oozing.After start G-code ends and the printing starts, the slicer assumes that each extruder starts from
0
position rather than -switch_extruder_retraction_amount
. When switching to each extruder for the first time, the extruder printing movements start with E position of0
leading to no extrusion for a while until the filament moves down the heatbreak into the nozzle.The slicer remembers the extruder position when it generates code to retract the extruder by
switch_extruder_retraction_amount
when the extruder is switched away from in the toolchange and restores the extruder position by moving the filament forward byswitch_extruder_retraction_amount
distance when the extruder is switched to in a toolchange. So this no/under extrusion problem only happens on the first toolchange until the extruder has extruded at leastswitch_extruder_retraction_amount
mm of filament.I fixed this issue by creating the post processing script to set the correct position for the extruder to -
switch_extruder_retraction_amount
for the first time each extruder is used.G92 E0
is corrected toG92 E-16
(if the printer had aswitch_extruder_retraction_amount
of 16).I drew the below diagram to visually show the extruder position problem.
Another solution for this problem would be if Cura assumes that each extruder has been retracted to
switch_extruder_retraction_amount
distance at the end of the start G-code and starts each extruder's initial position at the start of the print G-code to -switch_extruder_retraction_amount
instead of 0.Type of change
How Has This Been Tested?
I have run this post processing script on multiple prints and extrusion is improved due to setting extruder position to the correct value. No oozing occurs after priming because the extruder retracts filament by
switch_extruder_retraction_amount
in start G-code and extrusion begins immediately when the slicer switches to that extruder.Test Configuration:
Checklist: