[FR] Smart Runout Sensor compatibility with Mixing Extruder

[mjfsch]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

I have tested this with the latest bugfix (7/02/2022)

I have a modified Geeetech A20M, the board has been replaced with a BTT Octopus Pro, and the filament sensors have been replaced with BTT smart sensors.

I have the board connected to a BTT TFT and Octoprint. the BTT Smart sensors are connected to the main board, and i have host actions enabled.

This is a dual extruder single hotend "mixing" printer

If i print just using the first extruder the smart sensor correctly triggers when needed and goes through the correct filament change procedure.

However if i print using the second extruder, the sensor triggers when there is no runout or blockage.
The strange behaviour however is that it reports that the issue is with the first extruder not the second, and starts to unload the first extruder.

I think the issue is that the count down of remaining length is been applied to the wrong extruder count.

To test this out, i have enabled FILAMENT_RUNOUT_SENSOR_DEBUG
This reports
Recv: Motion detected: 0
Recv: Remaining mm: 7.0000, 7.0000

i have some gcode loaded that starts a print on T0, and i can see the first count reduce as expected.
Recv: Motion detected: 1
Recv: Remaining mm: 6.6518, 7.0000

The gcode then changes over to use T1,
Before changing colour, the gcode runs through a purge routene, while this is going i get the report
Recv: Motion detected: 0
Recv: Remaining mm: 7.0000, 7.0000

Following this and the print resuming the count continues to reduce on the first counter
Recv: Motion detected: 1
Recv: Remaining mm: 4.5341, 7.0000

Interestingly when this debug mode is enabled the printer crashes when the count hits 0, however with this mode not enabled, it triggers M600 against T0 rather than T1, as far as i can tell however this line should ensure it triggers for the correct extruder
#define FILAMENT_RUNOUT_SCRIPT "M600 T%c"

I have also tested this with
#define FILAMENT_RUNOUT_SCRIPT "M600 T%t"
as suggested by a previous bug report, this fails with the unknown extruder message.

I have tested the second run out sensor using M43 and monitoring the pin, so im happy enough that the sensor is working and the wiring is ok.

Unless my assumption is wrong that the debug line is reporting the status of both sensors, i can only guess that the issue is around the count down not following the active tool.

Bug Timeline

No response

Expected behavior

I would expect the remaining distance count sensor associated with the extruder to count down

Actual behavior

The remaining distance count always reduces against the count associated with T0 regardless of the active tool

Steps to Reproduce

No response

Version of Marlin Firmware

Bugfix 07/02/2022

Printer model

GeeeTech A20M Modifled

Electronics

BTT Octopus Pro + BTT Smart Sensors (x2) + BTT TFT35

Add-ons

Octoprint

Bed Leveling

ABL Bilinear mesh

Your Slicer

Cura

Host Software

OctoPrint

Additional information & file uploads

Configuration.zip

[mjfsch]

Out of idle curiosity I have re compiled the firmware disabling mixing extruder and changing my extruder number to 2 and setting single nozzle, so I still have the same hardware setup just lose the ability to mix.(I have disabled runout sensor debugging as that seemed to cause issues of its own.

Using the same gcode as tested previously, the print this time continues further than the first 7mm.

After a while I cut the filament and the sensor correct triggerd, paused the print and unloaded from the second extruder as expected.

In summery this means the problem does not exist in a dual extruder single nozzle setup, it is only present when configured as a mixing extruder.

[mjfsch]

I will edit this or delete it later, but this is one of those sudden thoughts that I don't want to forget.
Before making the previously mentioned change, I did have a look over the runout code and my untrained eye couldn't sport anything that stood out......

However I've just had the thought that the runout code uses number of extruders , in a mixing extruder setup in the config file the number of extruders has to be set to 1 and the mixing extruders set to the number. If this is somehow not carried across, then the runout code will only ever do anything with the first extruder

[thinkyhead]

I see where RunoutResponseDelayed::block_completed gets the extruder index from the planner block for use with runout_mm_countdown, and that will always be 0 with a mixing extruder. For now I think we have to consider FILAMENT_RUNOUT_DISTANCE_MM incompatible with the MIXING_EXTRUDER because block_completed is a crude hook based on clearly separated extruders.

[FinziNeto]

I have a SKR 1.4 Turbo, a Diamond 2 in 1 out nozzle, TFT35 and a BTT Smart Filament sensor on each channel of the extruder. In the past, I have posted an issue about this exact problem but with no luck on obtaining a solution. Either I end up with no mixing gcodes or with the filament sensors disabled. I am available to help testing any possible so we can find a solution.

[colindawson]

I've noticed the same issue. 2 Extruders, 2 Smart run out sensors.
When using E0, the E1 run out sensor will trigger, even though E1 isn't supposed to be moving! It will trigger repeatedly.

[mjfsch]

I've noticed the same issue. 2 Extruders, 2 Smart run out sensors. When using E0, the E1 run out sensor will trigger, even though E1 isn't supposed to be moving! It will trigger repeatedly.

Strange, I have 2 extruders and 2 smart sensors and it works fine, I do have shared nozzle selected and watch both sensors, so that might be something, does your set up have separate nozzles?

[FinziNeto]

I've noticed the same issue. 2 Extruders, 2 Smart run out sensors. When using E0, the E1 run out sensor will trigger, even though E1 isn't supposed to be moving! It will trigger repeatedly.

Strange, I have 2 extruders and 2 smart sensors and it works fine, I do have shared nozzle selected and watch both sensors, so that might be something, does your set up have separate nozzles?
The problem only happens when the directive MIXING_EXTRUDER is enabled. I have tested it it as you mentioned it and it really works without MIXING_EXTRUDER .

[colindawson]

I've noticed the same issue. 2 Extruders, 2 Smart run out sensors. When using E0, the E1 run out sensor will trigger, even though E1 isn't supposed to be moving! It will trigger repeatedly.

Strange, I have 2 extruders and 2 smart sensors and it works fine, I do have shared nozzle selected and watch both sensors, so that might be something, does your set up have separate nozzles?
The problem only happens when the directive MIXING_EXTRUDER is enabled. I have tested it it as you mentioned it and it really works without MIXING_EXTRUDER .

Nope, I was using a BTT 2 in 1 out nozzle. I'm wondering if the firmware was confused as to which sensor was which.... i.e. the hardware for sensor 1 and 0 were switched. Maybe I'll try that again later, but right now, it's working with as single extruder without any issues, so I'm happy for now. I'll put it down to a ID10T error and do some more extensive testing next time I try duel colour. (which will be with a mixing hotend)