Printer pauses immediatly after start only in octoprint

System Information:

I'm using an Artillery Sidewinder X1 printer with an MKS Gen L 1.0 controller board. The firmware on the printer is Marlin version 2.1.2.

Firmware Update:

Recently, I performed a firmware update. I updated the main printer firmware to Marlin version 2.1.2 and upgraded the firmware for the TFT screen as well. GitHub - digant73/BIGTREETECH-TouchScreenFirmware: support TFT35 V1.0/V1.1/V1.2/V2.0/V3.0, TFT28, TFT24 V1.1, TFT43, TFT50, TFT70. I made these updates primarily to ensure compatibility with the filament run-out sensor that's connected to the TFT screen, as the sensor was not functioning properly with earlier versions of the screen firmware.

Normal Operation:

With these updates in place, everything works well under normal circumstances. I simply load my G-code onto the SD card, start the print, and the printer performs without a hitch. The filament run-out sensor behaves as it should, with the indicator light displaying the correct green and red colors.

The Issue:

However, an issue arises when I try to print using OctoPrint. As soon as I initiate the print, it immediately pauses, and the screen begins to beep. No specific error message is displayed, which leaves me unsure of the root cause. It seems like the filament run-out sensor might be sending a false signal or there's a communication issue with OctoPrint that's preventing the sensor from operating correctly.

Its probably just a little thing that messes up the octroprint/printer communication, but has someone come across something similar?

Cheers F. (123.7 KB)

Please enable the serial.log, reproduce the issue and upload another systeminfo bundle so we can see what happens in the communication between OctoPrint and your printer. (132.0 KB)
serial (1).log (24.6 KB)

Yeah the runout sensor causes the printer to pause

2023-05-29 17:31:47,674 - Recv: //action:paused filament_runout 0
2023-05-29 17:31:47,683 - Printer signalled that it paused, switching state...
2023-05-29 17:31:47,699 - Changing monitoring state from "Printing" to "Pausing"

Which sensor are you using?

Thanks for tanking a look.

Its the default runout sensor that comes with the printer.
Besides uncommenting the "#define FILAMENT_RUNOUT_SENSOR" i haven't done anything more to the config of the sensor.

Maybe the advanced pause feature / emergency command parser is behaving differently when using octoprint?

I never used a runout sensor myself (always wanted but never did for some reason lol) so this is just a guess:
I think you just have to invert the sensor logic
change this line

#define FIL_RUNOUT_STATE     LOW  



in Configuration.h

Alright very interesting.

I changed low to high. Which lets me start the print normally. yay
The bed heats up, the nozzle heats up and then it goes into pause mode.

This time the nozzle lifts and moves back, which is i think the defined M600 "advanced park mode" park position.

So the earlier behaviour seems to be something different.
Also I read that the runout sensor only "works" when a print is started. There is the M421 command which for some reason doesnt work in my case but is suppposed to report the status of the runout sensor but its only reporting when a print is started.

So the later behavior makes more sense. The print actually starts and then its gets paused.

need the logs again ^^

I hope that you have a typo and the filament runout command is actually M412. You should be able to enter that command in the OctoPrint terminal tab and see the result both with some filament in the sensor and without.

Note that the RepRap Wiki shows less parameters in its M412 documentation.

Please slice something simple like a 1x1x1mm cube and upload the gcode here.

Right, good point @b-morgan

Send: M412
Recv: echo:Filament runout ON ; Host handling OFF
Recv: ok
Same behavior as before. It pauses right after starting the print.

Log files with "high" / "low" switched (163.5 KB)
serial (2).log (139.9 KB)

When I turn the runout sensor off, i can print normally.

This is how it was configured in the stock firmware (older version - looks slightly different)

 * Filament Runout Sensors
 * Mechanical or opto endstops are used to check for the presence of filament.
 * 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.
 * By default the firmware assumes HIGH=FILAMENT PRESENT.
  #define NUM_RUNOUT_SENSORS   1     // Number of sensors, up to one per extruder. Define a FIL_RUNOUT#_PIN for each.
  #define FIL_RUNOUT_INVERTING false // set to true to invert the logic of the sensor.
  #define FIL_RUNOUT_PULLUP          // Use internal pullup for filament runout pins.

So it seems like low was the correct configuration. They also use the pullup. No idea why it didn't work :person_shrugging:
I would suggest you ask the guys in the marlin discord

yeah, since it works in "stand alone" mode, i dont think either that its the configuration of the sensor.

i have to check on the screens firmware. its a not official firmware from artillery and there were some options for flashing that i have to understand better first.

but very weird behaviour in general :slight_smile:

I only see the output from one M412 which I assume is with filament in the sensor. By sending two M412 commands, one with filament in the sensor and one without filament in the sensor, we can verify that the sensor is working. One possible failure scenario is the pin isn't defined correctly. Another is the sensor is faulty. Yet another is the wiring is faulty.

Since I believe you have tried both high and low with the same results, I think we need to look at other possibilities.

yes i think the sensor itself if ok. it works reliably when printing without octoprint.

also the different behavior between the high and low scenario also leads me to think its not the sensor itself.

M412 only reports if the sensor is enabled, you want M119 to show the live state of the pin. It reports endstops, bltouch and runout sensor states.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.