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

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.