[3.3-rc2/3] "Change filament" Does not work correctly

Diamondback

@phaedrux Just had time to try again on RC3, same behavior as on RC2.

Phaedrux

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.

Diamondback

@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

Phaedrux

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

Diamondback

@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.

Diamondback

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?

Diamondback

Update, tested the RC3+7 from the linked thread, this does not solve the issue. Still sounds like a ver similar thing.

Phaedrux

@diamondback Now that 3.3 final is available can you test with that?

Diamondback

@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.

Diamondback

@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.

Phaedrux

Thanks. Will investigate.

Diamondback

@phaedrux Any news? This is still bugging my daily

dc42

@diamondback are you running in standalone or SBC mode?

Diamondback

@dc42 Standalone. (Duet 2 Wifi + Duex 5)

Diamondback

Any news about this @dc42 ?

Diamondback

Any news on this? Would love to get the "change" functionality back... @chrishamm @dc42

Diamondback

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.