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.

1 Like