Printer does not pause when running out of filament

Get Help
1

What is the problem?

Print is not paused when running out of filament (but Message on the Display) and printing via octoprint (printing via usb stick and pausing when running out of filament works).

What did you already try to solve it?

Checked HOST_ACTION_COMMANDS and HOST_PROMPT_SUPPORT in firmware „Configuration_adv.h“ and checked Setting is enabled in tft Display Settings.

Have you tried running in safe mode?

No

Did running in safe mode solve the problem?

/

Systeminfo Bundle

You can download this in OctoPrint's System Information dialog ... no bundle, no support!)
octoprint-systeminfo-20250216195804.zip (131.2 KB)

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible

Printer is an Artillery Genius (old version)

Send: M115
Recv: FIRMWARE_NAME:Marlin 2.1.2.1 - DIGA-Tech ASWX1 v1.0 (Mar  3 2024 13:42:52) SOURCE_CODE_URL:github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:Artillery Genius (lethuer) EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
Recv: Cap:SERIAL_XON_XOFF:0
Recv: Cap:BINARY_FILE_TRANSFER:0
Recv: Cap:EEPROM:1
Recv: Cap:VOLUMETRIC:1
Recv: Cap:AUTOREPORT_POS:1
Recv: Cap:AUTOREPORT_TEMP:1
Recv: Cap:PROGRESS:0
Recv: Cap:PRINT_JOB:1
Recv: Cap:AUTOLEVEL:0
Recv: Cap:RUNOUT:0
Recv: Cap:Z_PROBE:1
Recv: Cap:LEVELING_DATA:1
Recv: Cap:BUILD_PERCENT:1
Recv: Cap:SOFTWARE_POWER:0
Recv: Cap:TOGGLE_LIGHTS:0
Recv: Cap:CASE_LIGHT_BRIGHTNESS:0
Recv: Cap:EMERGENCY_PARSER:1
Recv: Cap:HOST_ACTION_COMMANDS:1
Recv: Cap:PROMPT_SUPPORT:1
Recv: Cap:SDCARD:0
Recv: Cap:REPEAT:0
Recv: Cap:SD_WRITE:0
Recv: Cap:AUTOREPORT_SD_STATUS:0
Recv: Cap:LONG_FILENAME:0
Recv: Cap:LFN_WRITE:0
Recv: Cap:CUSTOM_FIRMWARE_UPLOAD:0
Recv: Cap:EXTENDED_M20:0
Recv: Cap:THERMAL_PROTECTION:1
Recv: Cap:MOTION_MODES:0
Recv: Cap:ARCS:1
Recv: Cap:BABYSTEPPING:1
Recv: Cap:CHAMBER_TEMPERATURE:0
Recv: Cap:COOLER_TEMPERATURE:0
Recv: Cap:MEATPACK:0
Recv: Cap:CONFIG_EXPORT:0
Recv: area:{full:{min:{x:-3.0000,y:-3.0000,z:0.0000},max:{x:220.0000,y:220.0000,z:250.0000}},work:{min:{x:0.0000,y:0.0000,z:0.0000},max:{x:220.0000,y:220.0000,z:250.0000}}}
2

It appears, the printer (Marlin) does not report filament runout to OctoPrint.

3

Print is paused when printing via usb stick.

IMG_1366
IMG_13662268×4032 1.93 MB

What I have to do that OctoPrint does also pause ?

4

You will need to find a version of the printer firmware that supports it or you will need to compile your own version of Marlin. In theory, this should be relatively straight forward because the Marlin license requires that the printer manufacturer make the source files available. In practice, it is (too) often very difficult to obtain the sources for existing firmware.

Once you have firmware in the printer that supports reporting filament runout, OctoPrint should just work.

5

Taht's why I checked HOST_ACTION_COMMANDS and HOST_PROMPT_SUPPORT what you have mentioned in another thread.
What else is needed in Marlin ? I already have compiled my own version, just need to know which defines are required...

6

I'd start with Configuration.h:

/**
 * @section filament runout sensors
 *
 * Filament Runout Sensors
 * Mechanical or opto endstops are used to check for the presence of filament.
 *
 * IMPORTANT: Runout will only trigger if Marlin is aware that a print job is running.
 * Marlin knows a print job is running when:
 *  1. Running a print job from media started with M24.
 *  2. The Print Job Timer has been started with M75.
 *  3. The heaters were turned on and PRINTJOB_TIMER_AUTOSTART is enabled.
 *
 * RAMPS-based boards use SERVO3_PIN for the first runout sensor.
 * For other boards you may need to define FIL_RUNOUT_PIN, FIL_RUNOUT2_PIN, etc.
 */
//#define FILAMENT_RUNOUT_SENSOR

You will have to determine the rest of the values.

7

Yes I saw that section but because filament runout is working when printing from usb stick I did not change…
Sure this is needed only when printing via octoprint ?

8

I got this Feedback on Github:

The rounout sensor is connected to the display
With it connected like this the display can only stop printing if the printing is coming from the display usb or sdcard slot.

Marlin does not even know the runnout sensor exists!

Remember this is not actually just a screen, its a small computer with a screen, that is running things.
It probably does not send anything back to marlin about the run out sensor, it just handles it in the tft firmware.

With octoprint your bypassing the lcd/controller and the runout sensor

So is there really no way to let OctoPrint know that there is no filament and that Print has to be paused ?

9

You may try one of this: Filament Sensor Simplified

But you have to connect the filament sensor to the Raspberry Pi

10

As we have already stated, the way to let OctoPrint know is to change the firmware.

As you have stated, you have already compiled your own firmware with HOST_ACTION_COMMANDS and HOST_PROMPT_SUPPORT defined so define FILAMENT_RUNOUT_SENSOR and compile again.

I am a little surprised that Recv: Cap:RUNOUT:0 is reported by M115 but the runout sensor works when printing from the USB stick but that is a mystery that I don't need to solve. You will, of course, have to test that it still works when printing from the USB stick after you flash the firmware with the capabilities needed for OctoPrint to work as well.

11

Yep I have, here is my Configuration.h and Configuration_adv.h
Configuration.zip (90.8 KB)

FILAMENT_RUNOUT_SENSOR isn‘t defined yet because print pauses via usb stick.

So did I understsnd correct that you are pretty sure that FILAMENT_RUNOUT_SENSOR is needed for pausing via OctoPrint or is that just „trial and error“ ?

I‘m a bit wondering because it makes sense to me what was said in Marlin GitHub page

The rounout sensor is connected to the display
With it connected like this the display can only stop printing if the printing is coming from the display usb or sdcard slot.

Marlin does not even know the runnout sensor exists!

So why should a firmware change should have any impact regarding this if the runout sensor is connected to the display ?
Is there somewhere documented what defining FILAMENT_RUNOUT_SENSOR should have for an impact or what it is intended for ?

Or is defining FILAMENT_RUNOUT_SENSOR intended for the case the runout Sensor is connected to the board and not the tft ?

12

Why don't you just try it?

1 Like
13

It is "trial and error" on my part because I don't have a 3D printer with a filament runout sensor.

You have done all the hard work necessary to build custom firmware for your printer so I don't understand your reluctance to "Just try it". If it doesn't work, you can just flash the old version.

1 Like
14

I'm fairly sure that the problem here is because luether has his filament runout sensor connected to the touchscreen, not to the printer mainboard, and that when he says he's printing from a USB stick, he means the USB port on the display. He'd have the same issue if using the SD card slot on the display.

Luether, can you confirm that's what your setup is? This is quite a common setup with touchscreens, but unfortunately not what's need to work with Octoprint, or anything else that communicates directly with the printer.

Since his TFT display is actually a little computer in its own right, and when in touchscreen mode it's controlling the printer (not the other way round) that explains why the filament runout is detected when printing in that way. It also explains why his Configuration.h file has //#define FILAMENT_RUNOUT_SENSOR commented out. Marlin can know nothing of the sensor, and uncommenting that line will not help unless he also connects the sensor to the printer mainboard instead of the TFT.

OctoPrint is communicating with Marlin, not the TFT, and because Marlin can't see the sensor, it can't report filament runout to Octoprint.

15

Hi !

I just followed the filament sensor and opened the printer...
Runout sensor is connected to a small sepearate board and not the mainboard.
I measured with a multimeter and can confirm that the 3 wires from the runout sensor are connected to the tft...

This morning I found the following inside the tft firmwares "config.ini" file, so this is the next hint that the tft firmware is handling the runout and tells the board what to do in case a runout happens.

image
image997×885 56.4 KB

Nevertheless I just changed the firmware this morning with #define FILAMENT_RUNOUT_SENSOR and now get following after M115.

Send: M115
Recv: FIRMWARE_NAME:Marlin 2.1.2.1 - DIGA-Tech ASWX1 v1.0 (Feb 23 2025 11:46:12) SOURCE_CODE_URL:github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:Artillery Genius (No Pro) EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
Recv: Cap:SERIAL_XON_XOFF:0
Recv: Cap:BINARY_FILE_TRANSFER:0
Recv: Cap:EEPROM:1
Recv: Cap:VOLUMETRIC:1
Recv: Cap:AUTOREPORT_POS:1
Recv: Cap:AUTOREPORT_TEMP:1
Recv: Cap:PROGRESS:0
Recv: Cap:PRINT_JOB:1
Recv: Cap:AUTOLEVEL:0
Recv: Cap:RUNOUT:1
Recv: Cap:Z_PROBE:1
Recv: Cap:LEVELING_DATA:1
Recv: Cap:BUILD_PERCENT:1
Recv: Cap:SOFTWARE_POWER:0
Recv: Cap:TOGGLE_LIGHTS:0
Recv: Cap:CASE_LIGHT_BRIGHTNESS:0
Recv: Cap:EMERGENCY_PARSER:1
Recv: Cap:HOST_ACTION_COMMANDS:1
Recv: Cap:PROMPT_SUPPORT:1
Recv: Cap:SDCARD:0
Recv: Cap:REPEAT:0
Recv: Cap:SD_WRITE:0
Recv: Cap:AUTOREPORT_SD_STATUS:0
Recv: Cap:LONG_FILENAME:0
Recv: Cap:LFN_WRITE:0
Recv: Cap:CUSTOM_FIRMWARE_UPLOAD:0
Recv: Cap:EXTENDED_M20:0
Recv: Cap:THERMAL_PROTECTION:1
Recv: Cap:MOTION_MODES:0
Recv: Cap:ARCS:1
Recv: Cap:BABYSTEPPING:1
Recv: Cap:CHAMBER_TEMPERATURE:0
Recv: Cap:COOLER_TEMPERATURE:0
Recv: Cap:MEATPACK:0
Recv: Cap:CONFIG_EXPORT:0
Recv: area:{full:{min:{x:-3.0000,y:-3.0000,z:0.0000},max:{x:220.0000,y:220.0000,z:250.0000}},work:{min:{x:0.0000,y:0.0000,z:0.0000},max:{x:220.0000,y:220.0000,z:250.0000}}}

With that I first checked if print does still pause when filament runout happens and printing from USB (located next to and connected to the TFT) and this still works.

Afterwards I again inserted filament and now checked printing via OctoPrint.
If I try to start a print I get this message even if filament is present in the sensor !
image

Print is then directly paused
image
and after a few seconds then complete filament was withdrawn out of the hotend.
image

I inserted filament in the hotend again and I think it is now waiting for filament in the sensor in that position. Because detection does not work I disabled the Runout here and print just starts.
image

Then I made a test to start a print via OctoPrint with no filament inserted in the sensor.
Again I got the same messages, so I think there is no sensor attached or at least the allready installed one which is connected to the tft is not used from Marlin.

So in the end I think this statement is absolutely correct !

So only option is to install a seperate runout sensor to the board or unplug the existing one and connect it directly to the board ? In that case the #define FILAMENT_RUNOUT_SENSOR should be activated in Marlin and then runout should be considered in both cases (Printing from USB Stick / Sd Card or via OctoPrint) ?!

The board is: MKS Gen L V1.0
Where the sensor should be connected ?

16

That confirms what I suspected. After you reconfigured the firmware with #define FILAMENT_RUNOUT_SENSOR you see Cap:RUNOUT:1 in the M115 report because the code to look for a sensor and check its state has been activated. Yet because the sensor is not actually connected to the mainboard, it appears as an open circuit, which Marlin interprets as being triggered, and it passes the "error" message on to Octoprint.

The most likely reason that the filament is withdrawn, is that Marlin's code for runout detection invokes a script to take some action about that. The default script performs an M600 filament change command, and the first part of that unloads the remaining old filament. That script is in Configuration.h, around line 1850 in the config file you posted earlier, if you want to change it. The way the M600 command itself, ie the "Filament Change" works is defined in Configuration_adv.h, starting around line 2625 in the file you posted.

Of course it still works as before when printing from the TFT's USB port because you haven't changed anything there, but if you did move the sensor to the MKS board, you'd need to comment out the line for it in the TFT config file.

There's more than one way to connect a runout sensor to an MKS Gen L V1, so I suggest you check Google, which will find you a few short YouTube videos. For example, I found one from Teaching Tech for a Tevo Tornado, which uses the same mainboard. Michael explains most of the configuration choices that you might want, which not all others do, and how to test it. Although he was using ArduinoIDE for a much older version of Marlin, all the things you need are just the same in 2.1.2.1 or later, and you can compile the firmware with ArduinoIDE or VSCode/PlatformIO just the same. It is very straightforward.

1 Like
17

I‘m thinking about creating a connection to the Board in parallel to tft. In this way I could later simply change back in case I want to. Is there anything why I shouldn’t do in that way ?

18

I wouldn't do that. I don't know if the electronic configuration of the input on the MKS Gen L board is the same as the one on the TFT. If one operates at 5v (which I suspect the MKS does) and the other at 3.3V (which I suspect the TFT might), Bad Things™ could happen to one of the inputs. Anyway, that might not be necessary. If Marlin emits a suitable message, which the TFT can understand, it might react appropriately anyway. I've never tried that, though.

2 Likes
19

Again a good hint :slight_smile:
When connected to the tft I measured 3.3V at the sensor with pinning order like this:
V+ | GND | SIGNAL
SIGNAL is +3.3V if filament is inserted and 0V when empty.

Schematic of MKS Gen L V1.0 shows that the pins there have +5V, so I would mix up +5V from the board with +3.3V from the tft if would create a parallel connection.
So I have to disconnect the cable from TFT.
Another notice: In this video you mentioned from Teaching Tech he uses "SERVO3" which is D4 (marked black).
Unfortunately all inputs there (D4, D5, D6, D11) are already in use on my board, also +5V and GND are switched at these pins compared to the order I just measured at TFT, so I would need to switch GND / V+ in the wiring.

image
image1207×739 111 KB

But instead "X+" or "Y+" on my board are free, good thing there is also that the pin order is just the same like at the tft so I can simply use the same cable only extended to reach the Y+ socket (marked blue).

image
image1716×1200 286 KB

Because I now use another pin I made the following changes in the firmware:

in "pins_RAMPS.h" I changed line 286: #define FIL_RUNOUT_PIN 4 to #define FIL_RUNOUT_PIN 15 and commented out line 123: //#define Y_MAX_PIN 15 // Y+

also I prefer manual unloading for the moment so in Configuration_adv.h I changed line 2647 from #define FILAMENT_CHANGE_UNLOAD_LENGTH 100 to #define FILAMENT_CHANGE_UNLOAD_LENGTH 0.
I could not find the other two mentioned defines from the video: #define FILAMENT_CHANGE_SLOW_LOAD_LENGTH and #define FILAMENT_CHANGE_FAST_LOAD_LENGTH

After flashing that firmware I got following with pronterface:

>>> M503
SENDING:M503
echo:; Linear Units:
echo:  G21 ; (mm)
echo:; Temperature Units:
echo:  M149 C ; Units in Celsius
echo:; Filament settings (Disabled):
echo:  M200 S0 D1.7500
echo:; Steps per unit:
echo:  M92 X80.4000 Y80.4000 Z404.6500 E467.8900
echo:; Max feedrates (units/s):
echo:  M203 X200.0000 Y200.0000 Z20.0000 E40.0000
echo:; Max Acceleration (units/s2):
echo:  M201 X2000.0000 Y2000.0000 Z100.0000 E10000.0000
echo:; Acceleration (units/s2) (P<print-accel> R<retract-accel> T<travel-accel>):
echo:  M204 P1000.0000 R10000.0000 T2000.0000
echo:; Advanced (B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_jerk> Y<max_jerk> Z<max_jerk> E<max_jerk>):
echo:  M205 B20000.0000 S0.0000 T0.0000 X8.0000 Y8.0000 Z0.3000 E10.0000
echo:; Home offset:
echo:  M206 X0.0000 Y0.0000 Z0.0000
echo:; Mesh Bed Leveling:
echo:  M420 S0 Z10.0000 ; Leveling OFF
echo:; Z Auto-Align:
echo:  M422 S1 X10.0000 Y110.0000
echo:  M422 S2 X210.0000 Y110.0000
echo:; Hotend PID:
echo:  M301 P22.1896 I2.5554 D48.1709
echo:; Bed PID:
echo:  M304 P24.2776 I2.9344 D133.9074
echo:; Z-Probe Offset:
echo:  M851 X0.0000 Y0.0000 Z0.0000 ; (mm)
echo:; Input Shaping:
echo:  M593 X F40.0000 D0.1500
echo:  M593 Y F40.0000 D0.1500
echo:; Linear Advance:
echo:  M900 K0.1300
echo:; Filament load/unload:
echo:  M603 L0.0000 U0.0000 ; (mm)
echo:; Filament runout sensor:
echo:  M412 S1 ; Sensor ON

>>> M115
SENDING:M115
FIRMWARE_NAME:Marlin 2.1.2.1 - DIGA-Tech ASWX1 v1.0 (Feb 24 2025 20:48:24) SOURCE_CODE_URL:github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:Artillery Genius (No Pro) EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
Cap:SERIAL_XON_XOFF:0
Cap:BINARY_FILE_TRANSFER:0
Cap:EEPROM:1
Cap:VOLUMETRIC:1
Cap:AUTOREPORT_POS:1
Cap:AUTOREPORT_TEMP:1
Cap:PROGRESS:0
Cap:PRINT_JOB:1
Cap:AUTOLEVEL:0
Cap:RUNOUT:1
Cap:Z_PROBE:1
Cap:LEVELING_DATA:1
Cap:BUILD_PERCENT:1
Cap:SOFTWARE_POWER:0
Cap:TOGGLE_LIGHTS:0
Cap:CASE_LIGHT_BRIGHTNESS:0
Cap:EMERGENCY_PARSER:1
Cap:HOST_ACTION_COMMANDS:1
Cap:PROMPT_SUPPORT:1
Cap:SDCARD:0
Cap:REPEAT:0
Cap:SD_WRITE:0
Cap:AUTOREPORT_SD_STATUS:0
Cap:LONG_FILENAME:0
Cap:LFN_WRITE:0
Cap:CUSTOM_FIRMWARE_UPLOAD:0
Cap:EXTENDED_M20:0
Cap:THERMAL_PROTECTION:1
Cap:MOTION_MODES:0
Cap:ARCS:1
Cap:BABYSTEPPING:1
Cap:CHAMBER_TEMPERATURE:0
Cap:COOLER_TEMPERATURE:0
Cap:MEATPACK:0
Cap:CONFIG_EXPORT:0
area:{full:{min:{x:-3.0000,y:-3.0000,z:0.0000},max:{x:220.0000,y:220.0000,z:250.0000}},work:{min:{x:0.0000,y:0.0000,z:0.0000},max:{x:220.0000,y:220.0000,z:250.0000}}}

Because I saw

echo:; Filament runout sensor:
echo: M412 S1 ; Sensor ON

and

Cap:RUNOUT:1

I checked "M119":

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

I removed filament from the sensor and now get

>>> M119
SENDING:M119
Reporting endstop status
x_min: open
y_min: open
z_min: open
filament: open
ok P15 B3

So from my perspective this is looking good and I will check a print...

20

Checked printing via USB Stick and it is printing but filament runout is not considered... But I didn't change the tft firmware yet.

Also checked printing via OctoPrint and observe that filament runout is just handled good ! :slight_smile:
It detects the runout and displays it on tft, then moves the hotend up and to the front left corner and showes "Nozzle Parked". There it is waited without retracting the filament (because I configured manual unloading).
On the tft it was shown that I can continue and although tft was in listining mode I was able to continue via tft (didn't expect that, I would guess that I have to continue in OctoPrint).
Then filament was drawn in again and I was asked if I want to purge more or if I want to continue.
If in this step again no filament is detected there is also an option to Deactivate Runout Sensor.
After I selected to continue print was then resumed.