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?
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.
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
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.
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.
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 FILAMENT_RUNOUT_SENSOR
#if ENABLED(FILAMENT_RUNOUT_SENSOR)
#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.
#define FILAMENT_RUNOUT_SCRIPT "M600"
#endif
So it seems like low was the correct configuration. They also use the pullup. No idea why it didn't work
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.
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.
