benebrady commented 5 years ago

Description

Steps to Reproduce

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.
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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@benebrady i assume this is still an issue?

benebrady commented 5 years ago

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

InsanityAutomation commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@benebrady do you know what is wrong and where?

benebrady commented 5 years ago

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 commented 5 years ago

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 :)

Beast

boelle commented 5 years ago

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

paulluby commented 5 years ago

@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 commented 5 years ago

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 commented 4 years ago

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

paulluby commented 4 years ago

@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 commented 4 years ago

so when it runs out during a print what happens?

paulluby commented 4 years ago

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 commented 4 years ago

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

paulluby commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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.