FILAMENT_RUNOUT_SENSOR not working?

[lavato]

I am trying to use the FILAMENT_RUNOUT_SENSOR option for printer to pause when there is no filament however, it does not seam to work.

I use RC6 latest DEV with RAMPS EEB config and filament sensor which is HIGH (4.9v) on the signal side when the filament is not available. Regardless if I supply HIGH to Signal or not (which I do manually when testing) nothing happens, printer does not pause.

I have tried two pins D4 (servo) & D2 (X_MAX) both don't work.

When trying D4, I did below updates to config:

#define FILAMENT_RUNOUT_SENSOR
#if ENABLED(FILAMENT_RUNOUT_SENSOR)
  const bool FIL_RUNOUT_INVERTING = true;
  //#define ENDSTOPPULLUP_FIL_RUNOUT  **<--Commented out**
  #define FILAMENT_RUNOUT_SCRIPT "M600"
#endif

When trying D2, I did the same as for D4 put also did update the "pins_RAMPS_14.h" with below:

#if ENABLED(FILAMENT_RUNOUT_SENSOR)
  #define FILRUNOUT_PIN     2
#endif

Is there something else which needs to be set or this is a bug?

[thinkyhead]

I presume you are testing with SD printing? (It only interrupts the print when SD printing.)

[lavato]

Yes

[thinkyhead]

I've made some tweaks to this feature, but probably not anything that will affect your results. Still, start with the latest code and try also changing FIL_RUNOUT_INVERTING to false, both with and without ENDSTOPPULLUP_FIL_RUNOUT, to see if the results change.

[lavato]

I tried all combinations but it did not work, since the TRIGGER is on HIGH. If something, it should be a pull down.

To prove a point I un-commented #define USE_XMAX_PLUG and I get a following output. For first M119 the signal is LOW and for the second one the signal is HIGH.

SENDING:M119
Reporting endstop status
x_min: open
x_max: TRIGGERED
y_min: open
z_min: TRIGGERED
>>>m119
SENDING:M119
Reporting endstop status
x_min: open
x_max: open
y_min: open
z_min: TRIGGERED

This proves that the wiring is correct at least.

Note, that it does not mater what I do, ether setting the signal pin to HIGH or LOW, the printer will not pause.

Because this never worked for me, can you tell me when does Marlin start checking for the status of the pin, e.g. Is it from the moment the print start or during the warm-up?

In any case, I waited for the printer to actually start printing and then supplied the HIGH/LOW signal but still no luck.

[thinkyhead]

It's pretty straightforward…

  #if ENABLED(FILAMENT_RUNOUT_SENSOR)
    if (IS_SD_PRINTING && !(READ(FIL_RUNOUT_PIN) ^ FIL_RUNOUT_INVERTING))
      handle_filament_runout(); // Send "M600" command
  #endif

If you have FILAMENTCHANGEENABLE enabled then when SD printing it should run the M600 command soon after receiving the signal from the runout sensor.

[lavato]

I did some digging myself and want to point out couple of things:

• handle_filament_runout() is called but the M600 is not executed - nothing happens.
• When I send the M600 command via Pronterface, again nothing happens.
• When I send the signal to Pin 2, I can see a message echo:enqueueing "M600" but nothing happens.
• if I replace M600 with M25 in FILAMENT_RUNOUT_SCRIPT, printer does pause but only once. (I guess because of the static bool filament_ran_out in Marlin_main.cpp not being reset somewhere. Subsequent signals sent to Pin 2 will not pause the printer again.

Serial output, when pin set to HIGH, from :

//Serial output commands removed
  #if ENABLED(FILAMENT_RUNOUT_SENSOR)
    if (IS_SD_PRINTING && !(READ(FIL_RUNOUT_PIN) ^ FIL_RUNOUT_INVERTING))
      handle_filament_runout(); // Send "M600" command
  #endif

is:

IS_SD_PRINTING: 1
READ(FILRUNOUT_PIN): 1
FIL_RUNOUT_INVERTING: 1
IS_SD_PRINTING && !(READ(FILRUNOUT_PIN) ^ FIL_RUNOUT_INVERTING): 1

[thinkyhead]

M600 command via Pronterface, again nothing happens

So you definitely have FILAMENTCHANGEENABLE enabled too…? Hmm, strange behavior.

filament_ran_out in Marlin_main.cpp not being reset

Right. Actually the M600 handler resets it, so it's the only supported command for the runout script.

[lavato]

If you have FILAMENTCHANGEENABLEenabled then when SD printing it should run the M600 command soon after receiving the signal from the runout sensor.

and

So you definitely have FILAMENTCHANGEENABLEenabled too…? Hmm, strange behavior

Oh, I missed this earlier. I don't actually. However I noticed below code which would prevent FILAMENTCHANGEENABLE be set as I have REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

#if ENABLED(ULTIPANEL)
  //#define FILAMENTCHANGEENABLE
  #if ENABLED(FILAMENTCHANGEENABLE)

Any suggestions?

[thinkyhead]

code which would prevent FILAMENTCHANGEENABLE

Simply enable the option. ULTIPANEL is set in Conditionals.h when you select REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER…

#if ENABLED(REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER)
  #define DOGLCD
  #define U8GLIB_ST7920
  #define REPRAP_DISCOUNT_SMART_CONTROLLER
#endif

#if ENABLED(ULTIMAKERCONTROLLER) || ENABLED(REPRAP_DISCOUNT_SMART_CONTROLLER) || ENABLED(G3D_PANEL) || ENABLED(RIGIDBOT_PANEL)
  #define ULTIPANEL
  #define NEWPANEL
#endif

[lavato]

OK, that worked - Thank you!

May I suggest couple of points:

1) Can comments be updated in the 'Configuration.h' next to section for FILAMENT_RUNOUT_SENSOR, as it is not apparent at all that this has to be done.

2) The FILAMENT_RUNOUT_SENSOR process starts polling during the warm-up and auto level, shouldn't it start polling when the printing actually starts printing, as if you have a sensor which detects blockages, it will trigger during the warm-up since the filament is not moving?

3) The "Change Filament" message does not disappear from the LCD screen once print is resumed.

[thinkyhead]

shouldn't it start polling when the printing actually starts printing

I suppose so. There's no concept in Marlin of "currently printing" but it can do things like monitor the sensor whenever there has been a recent movement command.

[thinkyhead]

The "Change Filament" message does not disappear from the LCD screen once print is resumed.

The current M600 feature is going to be replaced pretty soon. But this sounds like something we could fix up in advance of that.

[lavato]

I suppose so. There's no concept in Marlin of "currently printing" but it can do things like monitor the sensor whenever there has been a recent movement command.

and

But this sounds like something we could fix up in advance of that.`

Is it best to raise the above two as separate issues?

[jbrazio]

The big question is what do we should consider "printing", is it moving the tower ? Is it extruding plastic ? We don't have a "start" and a "stop" command, we do some eyeballing and guessing for the print timers but that's not accurate enough to detect a printing state.

[lavato]

I know what you mean... but isn't it better to start polling when extruding plastic then during the heat-up sequence, would't you say?

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.