[3.3-rc2/3] "Change filament" Does not work correctly
-
-
@diamondback Thanks. Far as we know as of RC3 it should be working. @chrishamm will have to take a look at your files.
-
@phaedrux Thank you, I will update to RC3 and see if things persist.
-
@phaedrux Just had time to try again on RC3, same behavior as on RC2.
-
Would you be able to share all of your macros that are called in the filament change load and unload macros? What's actually happening is buried in there.
-
@phaedrux here you go (I replaced macro calls by the actual gcode to makes things easier to read)
unload
M42 P1 S255; lights on M109 S270 M300 S300 P300 G4 P300 M300 S400 P300 G4 P300 M300 S500 P300 M291 P"Pull out filament" R"Filament" S2 M104 S0 M300 S300 P300 G4 P300 M300 S400 P300 G4 P300 M300 S500 P300
config
M207 S0.3 F3000 Z0.0 ;firmware retraction settings for PETG M302 S250 R190 ;Cold extrusion settings
load (this is using the "PebbleWiper" concept with a variable amount of pebbles being extruded depending on if it's a filament load or a toolchange, so don't be surprised by the servo calls etc)
M42 P1 S255; lights on M291 P"Heating for purge" R"Filament" S0 T115 if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed || !move.axes[3].homed M98 P"homeall.g" M109 S270 M302 S250 R190 M300 S300 P300 G4 P300 M300 S400 P300 G4 P300 M300 S500 P300 M291 P"Insert new Nylon filament" R"Filament" S2 M280 P0 S40 if state.currentTool < 0 echo "Can't Prime & Brush, no tool selected!" M99 if heat.heaters[tools[state.currentTool].heaters[0]].current > heat.coldExtrudeTemperature M564 S0 G90 G53 G1 X-148.7 Y70 F25000 ; Move in front of brush at safe Y G53 G1 Y149 F25000 ; Quickly move in ;G53 G1 Y150 F3000 ; Slowly approach final Y position var primeRepeats = 1 if exists(var.R) set var.primeRepeats = var.R while iterations < var.primeRepeats G4 P1000 M280 P0 S40 G4 P100 M83 ;M280 P0 S85 G1 E20 F200 M106 S255 G4 P7000 G1 E-0.8 F2500 G4 P300 M280 P0 S180 M106 S0 G4 P200 G91 G1 Y-40 F20000 ; start of brush G1 Y35 F20000 ; start of brush G1 Y-45 F20000 M280 P0 S40 G1 Y-40 F25000 G1 X10 F25000 G90 M564 S1 else echo "Skipping Prime & Brush due to unheated tool" M104 S0 M300 S300 P300 G4 P300 M300 S400 P300 G4 P300 M300 S500 P300
-
Note that M109/M104 may cause tool changes so it would be better to use G10 S/R + M116 instead, just to be safe
the only reason why M701 could complain about a loaded filament is if M702 somehow deselected the tool -
@phaedrux Thanks for the hint, will change that to be sure.
Just in case it got overlooked, this specific code worked fine on previous versions, as far as I know, RC2 was the first version to break. -
Might have found the cause. As you can see, one of the last things my unload does is to display a blocking message that waits before the tool is allowed to cool down again.
The error appears in the console while the blocking message is still being displayed, ie before I confirmed it.
It reminds me of this issue: https://forum.duet3d.com/topic/23579/3-3rc3-tool-change-don-t-wait-on-m116-p/25
@dc42 is this possibly related?
-
Update, tested the RC3+7 from the linked thread, this does not solve the issue. Still sounds like a ver similar thing.
-
@diamondback Now that 3.3 final is available can you test with that?
-
@phaedrux Same thing as before, here's a screenshot showing the behavior I mentioned (error from load in the console while the dialog from unload is still being displayed)
Will remove the dialog and re-test to confirm.
-
@phaedrux Ok, yea when I remove the M291 S2 from the unload script, it "works", as in it successfully executes unload and then load.
So looks like the blocking M291 is indeed the issue here due to M701 being executed while M702 is still "active" due to the blocking dialog. -
Thanks. Will investigate.
-
@phaedrux Any news? This is still bugging my daily
-
@diamondback are you running in standalone or SBC mode?
-
@dc42 Standalone. (Duet 2 Wifi + Duex 5)
-
Any news about this @dc42 ?
-
Any news on this? Would love to get the "change" functionality back... @chrishamm @dc42
-
I don't know when exactly this got solved, but starting with one of thhe 3.4 beta builds, this is no longer an issue and works fine again.
-