[BUG] Filament Runout Sensor state not checked prior to start of print

[benebrady]

Description

Steps to Reproduce

1. Remove filament from printer and make sure the filament runout sensor is clear. Do an M119 in Pronterface or Octoprint terminal window and make sure the filament runout sensor is not triggered.

2. Slice an STL file and copy the gcode file to the SD card of the printer and start the print.

Expected behavior: [What you expect to happen]

I would expect the printer to immediately execute a filament change at the start of the print when the bed and hot end have reached temperature.

Actual behavior: [What actually happens]
No filament change is started and the print proceeds as though there is filament already in the printer. No check for the filament runout sensor is performed and the printer just thinks it's A-OK.

Additional Information

I'm running a Crealikty CR10S with the stock controller board and a functional filament runout sensor.
Ben_E_Brady_CR10S_filament_runout_bug.zip

• Include a ZIP file containing your Configuration.h and Configuration_adv.h files.
• Provide pictures or links to videos that clearly demonstrate the issue.
• See How Can I Contribute for additional guidelines.

[hussainsail2002]

Hi, If you have an LCD you can go to the configuration tab and check whether filament Runout sensor is on or off ,

To turn it off via pronterface you can use M412 S0
You can read about it here http://marlinfw.org/docs/gcode/M412.html

Also check if your trigger switch is inverted

#define FIL_RUNOUT_INVERTING true

You can change true to false here

[benebrady]

My filament runout sensor works fine... That's not the issue. The issue is, if you don't have filament in the printer at the time you start the print, the state of the filament sensor should be checked so that you can be prompted to insert the filament. Currently, the print job starts and no prompting is done, which means the printer starts the print job without filament.

[boelle]

@benebrady i assume this is still an issue?

[benebrady]

Yes, it is as far as I know--Ben E. BradyMartindale, Texas

[InsanityAutomation]

This is a feature request. When starting a print via SD, check the runout state prior to actually starting the print. If runout is tripped, trigger M600 or simply alert prior to starting.

[shitcreek]

I've been poking at the filament runout code and it needs to be rewritten because as it stands, if the user sets a FILAMENT_RUNOUT_DISTANCE_MM it goes through the whole sequence of printing out the the set amount even though there may be nothing in the line.

[InsanityAutomation]

@shitcreek thats intentional. It is intended as 1. a debounce with small numbers or 2. if the sensor is mounted 200mm from the extruder (see taz workhorse) it will allow you to use the bulk of the material between the sensor and the extruder. For a closely mounted setup that is left disabled and is therefore 0.

[shitcreek]

@InsanityAutomation, yes, however in case where there is nothing (at all) in the line at the start of the print, it should not attempt to extrude. This isn't a concern if the user were paying attention, however we should always aim to make it fool proof.

[benebrady]

That may be true for Bowden extruders where the sensor is mounted on the input of the extruder mechanism, but it would certainly not be true for direct drive systems where the usual practice is to mount the sensor near the spool at the top of the machine. It's been my experience that if the filament is going to break, it's going to do it between the sensor and the direct drive, in which case the sensor never gets triggered and the print fails. Ideally, the sensor should be mounted as close to the input of the direct drive as possible. It would really be nice if extruder manufacturers would think about their designs in a practical manner and incorporate a true filament motion sensor into their extruders.

[InsanityAutomation]

@shitcreek Right, thats why I called this a FR. The issue will come in with the motion sensor though as we dont know which state it will be in from the encoder wheel.

Those are still uncommon though.

[tpruvot]

I also noticed something strange (and recent)... As i have a custom icon to display the sensor state...

If the sensor was triggered, on resume and on the next print the variable runout.filament_ran_out remains set.. even with a filament...

[benebrady]

This issue is NOT a feature request... This is a logical bug in the firmware. The filament sensor should be checked prior to the print... period. If there isn't any filament in the sensor, the user should at least be prompted prior to the print starting at worst... at best, trigger the M600 and cause a filament change to happen.

[InsanityAutomation]

Id consider it a bug if it was there but broken at some point. It was never there. That makes it a new function. By that logic almost every new feature would be a bug because somebody thought it should have been there.

Regardless, there's no argument it should get done and now its tagged as such when somebody has time.

[benebrady]

Semantics... If you look at the printing process logically, with regard to what is necessary to successfully print something, since filament is absolutely necessary to successfully print something, AND if a filament sensor is present, then the print should not proceed without first checking to see if the filament sensor is triggered. I was a software developer for nearly 50 years. This would surely be classified as a software defect (euphemistically called a bug) of omission. If I knew more about C++ I would be much more involved with Marlin firmware than I already am. Unfortunately, I spent 30+ years in 4GL languages.--Ben E. BradyMartindale, Texas

[boelle]

@benebrady do you know what is wrong and where?

[benebrady]

What is wrong is that the filament sensor state is not tested before the print is started.My explanation is pretty clear as to what the problem is... And the steps on how to recreate the problem.If I knew where the problem is in the code I would have offered a solution.--Ben E. BradyMartindale, Texas

[paulluby]

Hi Guys.

Not often I post but I may have some extra info regards this issue.

My own design 410mm x 410mm x 410mm capacity printer (picture below) initially used an Arduino Mega and Ramps 1.4, then 1.5 and now 1.6. Initially it was running Marlin 1.1.8 but later went on to 1.1.9.

When I incorporated the Run-Out sensor I noticed that if you powered it on with no filament in the "sensor" and tried to print it would quite happily print but obviously lay down no filament.

If you powered on the printer with filament in the sensor and unloaded it prior to starting a print. If you then started a print it would detect the fact that no filament was present.

Irrespective of whether you had filament loaded on power up if filament was present when you started a print it would detect a run-out condition satisfactorily.

In January 2019 I changed the electronics to a Re-Arm board with a Viki2 controller running Marlin 2.0. Note the Ramps 1.6 is connected exactly the same for both Re-Arm and Mega and I can swap between them in about 5 minutes for fault diagnosis purposes.

With Re-Arm and Marlin 2 it matters not whether filament is loaded on power up, the run-out sensor always detects the lack of filament when starting a print.

Interestingly with the Mega fitted running Marlin 2.0 it behaves the same as when running 1.1.8 and 1.1.9.

Don't know if that helps narrow down the problem but for me it sounds like a condition on power up type of problem.

BTW I have 2 printers that have been running Marlin 2 on Re-Arms since January doing prints that take from 10 minutes to prints that take 80 plus hours. They have never missed a beat and I've never had a failed print.

So please keep up the good work :)

[boelle]

@paulluby so with 2.0 it will work on 32 bit, but not on 8 bit?

[paulluby]

@boelle Yep, that's what I observed on my printers when experimenting.

It was something I noticed but then managed to reproduce.

Am busy with work this week but can swap out boards and firmware again this weekend to confirm.

Have you managed to reproduce?

[Vertabreak]

testing this on my GT2560 i did as the OP suggested i unloaded the filament ran M119 it stated triggered and octoprint also stated T0 empty then i waited to see if it tried to print.
it preheated and went right in to filament change after homing at this point the filament change screen went away and the filament change didn't happen beyond this point. its now sitting at the info screen with the bed heated only doing nothing. the printer still thought it was going to print i selected stop print from menu.

[boelle]

a lot of updates and fixing has happend in the last week, is the problem still there?

[paulluby]

@boelle

Checked it today and all appears fine.

It detected lack of filament when starting print with no filament loaded on power on.

It detected lack of filament when starting print with filament loaded on power on and filament unloaded prior to starting print.

It detected lack of filament when filament ran out during print on all occasions.

The only thing different is that the Extruder Stepper is now locked during filament change. However I have changed the board in The Beast from a Re-Arm board with Ramp 1.6 to a Bigtreetech SKR V1.1 Pro. This occurs with both version 2.0.1 and 2.0.3. Note still using 4988 on Extruder Stepper. Have got more testing to do regards this.

[boelle]

so when it runs out during a print what happens?

[paulluby]

It initiated a filament change when the filament ran out during a print.

The only thing different is that the Extruder Stepper is now locked during filament change.

[boelle]

i would not see that as a problem as long it unloads and loads

[paulluby]

@boelle

Agreed, but it is curious.

Previously if no filament was loaded at the time the print was started it would start the print then detect the filament runout and initiate the filament change routine.

Now it detects the filament runout as soon as you confirm that the print is to start.

So I'm assuming that when the filament present check is carried out has been changed and am wondering if that could cause the different E Stepper behaviour?

Sorry, I'm and aircraft avionics engineer by trade and noticing system behaviour is my job.

[paulluby]

@boelle

Just checked and once the E stepper has been moved by Marlin including LCD menu even issuing a general M84 command via Pronteface doesn't disable the E Stepper but disables all other axis. Selecting Stepper Disable from LCD Menu doesn't disable it either.

Issuing individual M84 X, Y or Z disables the relevant axis but issuing a M84 E doesn't disable E stepper.

Curious as to what has changed.

[boelle]

@paulluby in regard to extruder locked issue could you create a new issue for that?

will close this one as it seems no one has the problem anymore

if people have the filament sensor problem please test the bugfix-2.0.x branch to see where it stands.se

[paulluby]

@paulluby in regard to extruder locked issue could you create a new issue for that?

will close this one as it seems no one has the problem anymore

if people have the filament sensor problem please test the bugfix-2.0.x branch to see where it stands.se

Sorry for not answering, was working late.

Honestly haven't looked at this recently as I've been a little busy printing Faceshields for local NHS Hospitals so this sort of thing wasn't even on the list of things to do.

Will look at it this weekend and if E Stepper locking is still occuring during filament change I'll raise a new issue.

[qwewer0]

The issue is still present with the latest bugfix.
If there is no filament in the sensor when a print starts, the printer does not triggers filament change.
I suspect that this feature was inside marlin 1.1.x, see in Chris Riley's video, and maybe it is in 2.0.x for some boards, but not for mine.

• SKR Mini E3 v1.2
• FIL_RUNOUT_PIN PC14 // "PROBE"
• Endstop filament runout sensor

[thinkyhead]

@qwewer0 — Have you got M412 S1 to enable the runout sensor at the start of your G-code?

[qwewer0]

@thinkyhead I don't have M412 S1 in my start gcode, but isn't it enough that I have Runout Sensor: On in the LCD?

[idjmic]

I can confirm issues as well. Marlin bug fix-2.0.X | CR-10 | SKR mini e3 v1.2 | Tested switch with M119 open / Triggered both detect properly, tried powering on with filament loaded, started print, removed filament, kept on going. Using PC15, E0-STOP. Even tested with M412 S1 in starting script. Not working.

[qwewer0]

Daniel from Crosslink also experienced this issue, and mentioned it in his Filament runout sensor video.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

[qwewer0]

Still an issue.
New info: If no filament is present prior to printing, then I get the next:

READ: echo:Now fresh file: patch_~1.gco
Now fresh file: patch_~1.gco
READ: File opened: patch_~1.gco Size: 51907
READ: File selected
READ: //action:notification patch_bed_leveling_2-6.25.gcode
READ: //action:notification patch_bed_leveling_2-6.25.gcode
READ: //action:resume
READ: //action:notification patch_bed_leveling_2-6.25.gcode
READ: //action:notification patch_bed_leveling_2-6.25.gcode
READ: //action:notification Bed Heating...
READ:  T:72.74 /0.0000 B:44.89 /50.0000 @:0 B@:0 W:?
READ: //action:prompt_end
READ: //action:prompt_begin FilamentRunout T0
READ: //action:prompt_show
READ: //action:paused filament_runout 0
READ:  T:72.65 /0.0000 B:45.07 /50.0000 @:0 B@:43 W:?
...
READ:  T:60.19 /0.0000 B:51.82 /50.0000 @:0 B@:91 W:0
READ: //action:notification patch_bed_leveling_2-6.25.gcode
READ: //action:paused
READ: //action:notification M600: Too Cold
READ: //action:cancel
READ: //action:notification Print Aborted

Configuration.zip

[qwewer0]

In my case, could it have something to do with M25 not working either?

[qwewer0]

I think #19332 is the fix for the problem. At least it worked for me.

[qwewer0]

@benebrady Did you try the latest Bugfix-2.0.x? Did it fix the issue or is it still present?

[github-actions]

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

[github-actions]

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.