Closed wonderland134 closed 5 years ago
Absolutely sure #define FIL_RUNOUT_INVERTING false
maybe needs to be true
?
@BigIronGuru Yeah I'm sure. I use mk3s filament runout sensor. And I checked it. filament loaded - m119 result will be filament open filament unloaded - m119 result will be filament triggered.
If I change #define FIL_RUNOUT_INVERTING false to true, Then can get inverted result.
So I think that value will be false.
Additionally. I tried change that value to true. As I told above, pronterface m119 result inverted. Also, print posed and filament changing problem will be occured.
The MK3 and to an lesser extent MK3S are known sometimes to have unreliable filament sensors since they're optical/IR and not a physical switch. Have you ruled out its not a hardware problem/the sensor actually giving false runout errors? That seems more far more likely than a marlin bug at this point, until that is ruled out. What you can try is removing filament sensor and shorting/forcing closed the filament sensor input to rule that out.
@talldonkey I know about the prusa mk3 optical sensor error issue. So, mk3s filament sensor is solve undetected problem. right??
If the my problem caused by filament sensor it self, M119 result will be wrong??
I get the result, fine result for pronterface m119 value. open and triggered
MK3S is still not 100% reliable. For example, if you print in a filament invisible to the IR sensor, such as Esun PETG Black which surprisingly happens to be invisible to IR then the MK3S sensor will not be reliable either.
My point is, rule out the filament sensor so you can track it down to a marlin code bug.
On Thu, Jun 20, 2019 at 4:49 PM wonderland134 notifications@github.com wrote:
@talldonkey https://github.com/talldonkey I know about the prusa mk3 optical sensor error issue. So, mk3s filament sensor is solve undetected problem. right??
If the my problem caused by filament sensor it self, M119 result will be wrong??
I get the result, fine result for pronterface m119 value. open and triggered
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/14337?email_source=notifications&email_token=ABTFTN4Z5KUC4FPL74G2TYTP3QJRVA5CNFSM4HZUULMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYHBCAQ#issuecomment-504238338, or mute the thread https://github.com/notifications/unsubscribe-auth/ABTFTN56ECI7EENOM4V5ANTP3QJRVANCNFSM4HZUULMA .
@talldonkey But, Also I have mk3s. By prusa mk3s sensor is operate correctly. effective differences are different board and different firmware. I use same extruder model and color.
The model which have problem use Mks gen 1.4 board.
MK3S is still not 100% reliable. For example, if you print in a filament invisible to the IR sensor, such as Esun PETG Black which surprisingly happens to be invisible to IR then the MK3S sensor will not be reliable either.
That's not correct. MK3S IR sensor doesn't detect anymore the used filament but it detect a extruder moving part (that should be printed with black PETG AFAIK).
Yes, thanks for correcting me - I meant to say print the detection lever in a filament invisible to the IR sensor.
On Fri, Jun 21, 2019 at 3:27 AM Giuliano Zaro notifications@github.com wrote:
MK3S is still not 100% reliable. For example, if you print in a filament invisible to the IR sensor, such as Esun PETG Black which surprisingly happens to be invisible to IR then the MK3S sensor will not be reliable either.
That's not correct. MK3S IR sensor doesn't detect anymore the used filament but it detect a extruder moving part (that should be printed with black PETG AFAIK).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/14337?email_source=notifications&email_token=ABTFTN3PUADFYAVGNWLE7U3P3SUIHA5CNFSM4HZUULMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYIC3RI#issuecomment-504376773, or mute the thread https://github.com/notifications/unsubscribe-auth/ABTFTN5II7E255EAAHWIZELP3SUIHANCNFSM4HZUULMA .
Here's a tip if anyone is having problems with FILAMENT_RUNOUT_SENSOR
:
There is a #define FILAMENT_RUNOUT_SENSOR_DEBUG
which will put out more information.
@BigIronGuru I can't find information about #define FILAMENT_RUNOUT_SENSOR_DEBUG. Can I hear about that?
Just define it. Look at the code runout.h
for details.
/**
* 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 FILAMENT_RUNOUT_SENSOR_DEBUG //§§§§
#define NUM_RUNOUT_SENSORS 1 // Number of sensors, up to one per extruder. Define a FIL_RUNOUT#_PIN for each.
#define FIL_RUNOUT_INVERTING true // set to true to invert the logic of the sensor.
#define FIL_RUNOUT_PULLUP // Use internal pullup for filament runout pins.
//#define FIL_RUNOUT_PULLDOWN // Use internal pulldown for filament runout pins.
// Set one or more commands to execute on filament runout.
// (After 'M412 H' Marlin will ask the host to handle the process.)
#define FILAMENT_RUNOUT_SCRIPT "M600"
// After a runout is detected, continue printing this length of filament
// before executing the runout script. Useful for a sensor at the end of
// a feed tube. Requires 4 bytes SRAM per sensor, plus 4 bytes overhead.
#define FILAMENT_RUNOUT_DISTANCE_MM 35 //§§§§
#ifdef FILAMENT_RUNOUT_DISTANCE_MM
// Enable this option to use an encoder disc that toggles the runout pin
// as the filament moves. (Be sure to set FILAMENT_RUNOUT_DISTANCE_MM
// large enough to avoid false positives.)
//#define FILAMENT_MOTION_SENSOR
#endif
#endif
@wonderland134
I can't find information about #define FILAMENT_RUNOUT_SENSOR_DEBUG.
Where did you look?
This is a open source project. That means you can find all relevant information in the source code. Just grep (a directory wide search following sub-directories) for FILAMENT_RUNOUT_SENSOR_DEBUG
and look up what it does.
Can I hear about that?
No. Most text to speak tools fail miserably when trying to tell you 'c source code'. Reading is the better option.
@AnHardt My marlin2.0 didn't contain about DEBUG. Then this is reason why, filament sensor dosen't works properly?
And I think last one also means Marlin configuration.h configuration_adv.h dictionary is didn't necessity.(Also about comment in programming) I'm just one some simple introduction about that.
Just put the line
#define FILAMENT_RUNOUT_SENSOR_DEBUG
into Configuration.h
where I posted it above.
Unless your Marlin bugfix-2.0.x is very old or you are using some strange fork, I do not believe your version does not contain FILAMENT_RUNOUT_SENSOR_DEBUG
in the source code /src/feature/runout.h
As you can see here. I didn't have it. Maybe I downloaded this version from http://marlinfw.org/meta/download/ few days ago. In this root caused download old version?
But I can find #define FILAMENT_RUNOUT_SENSOR_DEBUG at /src/feature/runout.h .
Yeah!
So, Return about question, I can find reason why M600 present eventhough filament sensor detect filament correctly here? I can't catch key point.
So ADD it in Configuration.adv. And VIEW the debug messages coming It needs to be ADDED. It is normally not there, big secret.
Hello,
I have about the same problem
I have a machine with the MK3S head, I added on the sensor a led for a status indication
But when the machine starts, it starts purging and then stops and asks me to continue. (M600 ?)
Then at each layer change the LED of the sensor is activated and the machine stops, all I have to do is "Resume" then "Continue". (M600 ?)
I switched from a MKS base to an SKR and I tests with activating pullup and pulldown, the result is same
I can also confirm that filament runout is currently broken. I tested SKR 1.3 board with mechanical endstop switches. M119 reports 100% correct, manual print pausing works, but the switch is doing nothing :(
+1 ! I have the same issue here... Using today (latest) 2.0 bugfix and the runout sensor does nothing while printing. M119 can confirm that my two mechanical endstops are working okay.
I have two extruders with two mechanical endstops, PIN config are ok, tested with M119 with success.
During the print runout sensor does nothing.
@govido @mtmello2003 Agree. I change motherboard mks gen 1.4 to skr 1.3 But, same problem was occur. Problem is still continue. I look up the runout.h for filament sensor debug. But it is not thing to help to solve the problem. It just print filament out or in even though, I'm already test by m119 commend correctly.
@thinkyhead Any idea how we could track down the issue? I would guess the sensor/endstop is polled for status change during printing, is that right? And if the state changes (and gets recognized) it will trigger the pause script. Is there a debug function that would help diagnosing this?
The issue can be tracked down by finding the most recent commit that still works and then examining the changes made in the following commit.
Hi, if anyone wants to search with me: I can confirm so far, that it was working on May 1st (9372e26) and is not working on June 1st (e4260a4). Update: May 15 is also working OK (451ea99) May 25 also OK (e1bf34b) May 29 broken (8e8e48f) May 27 broken (5f42d3a)
If someone doesn't know how to download older Marlin versions a quick copy from a different issue from me: Go to the page where all Marlin 2.0 commits are listed: https://github.com/MarlinFirmware/Marlin/commits/bugfix-2.0.x Search for the commit number you want to try (this includes every change including that last change/commit). Copy the number/letter combination and put in this URL: https://github.com/marlinfirmware/marlin/archive/COMMIT-SHA.zip
For example, if you want to get the last commit from July 2nd you need to put 720bc7c in the URL: https://github.com/marlinfirmware/marlin/archive/720bc7c.zip
If you want to test June 1st just put this in: e4260a4 https://github.com/marlinfirmware/marlin/archive/e4260a4.zip
If you compare these two version, you will see that tmc2209 support was added, and many other things. That is the easiest way i could find. Hope this helps everyone searching for older working versions.
After a few hours of testing I narrowed it down to one specific day: May 26 Between 3c179bb and e1bf34b must be the breaking commit. Sadly the worst day to find breaking commit... over 20 to choose from. https://github.com/MarlinFirmware/Marlin/commits/bugfix-2.0.x?after=6a2a10a154c9db39d5b3732e66685953e5f945e7+226 Update: Up to 1c86fbc filament sensor is still working, I haven't tested any further yet. This is where I will end for today.
@govido You means, for instance, If I download via to "https://github.com/marlinfirmware/marlin/archive/e1bf34b.zip", I can get the success to using optical filament sensor which is conclude prusa mk3s filament sensor??
Yes ;)
I found the breaking commit: 49e83dd This adds BLTouch support for 3.1. There are lots of changes inside. Maybe someone with good coding skills can take a look. (fyi: I'm using a BLTouch with default settings in my config)
The most recent version with filament sensor working is currently 14fe41f.: https://github.com/marlinfirmware/marlin/archive/14fe41f.zip Problems with this version: Maxtemp error on SKR 1.3 on start, need to disable temperature checks, dual Z is broken and needs newer stepper_indirection.h file. @thinkyhead This is as far as I can go to provide assistance for this (with my knowledge for now). Hope it helps bringing Marlin 2.0 forward.
@govido What a greatness! @thinkyhead Always I appreciate for your effort to forwarding marlin firmware. I hope this problem fix as soon as possible. I want to use my sensor OTL.
Hi, I had a look into the code to help @AlfiQue with this issue.
If I rely on the assumption of @govido that the breaking commit is https://github.com/MarlinFirmware/Marlin/commit/49e83dd7c81cffef7462a0a53a70a125562de83a and assuming that the BLTouch shouldn't have anything to do with the runout feature, then the only thing I can see so far that can have a side effect on the other features is configuration_store.cpp.
Maybe someone could to do an EEPROM clear to reset all the values to default and give another try.
But once more, this analysis assumes that the previous assumptions were correct.
@wonderland134 Maybe you could try this one: https://github.com/marlinfirmware/marlin/archive/49e83dd.zip And report back if your runout sensor is stil working, on my machine it didn't. That way we could double check my theory. Thanks
@govido Yep, I will check that maybe in 2 days! And... before the 49e83dd, any other problem exist for skr 1.3?
Same problems.
If the eeprom state was setting it to disabled, M412 would report filament sensor off, can you check that state? Also it would likely be reporting an eeprom version mismatch on power up over the serial console. If so M502 followed by M500 would initialize it. Set M412 S1 then M500 and see what happens.
May 25 also OK (e1bf34b) ---> confirmed here: working perfectly.
@wonderland134 and you are using bugfix-2.0.x ?
Yep. I know about that, In progress fixing.
Hello, I have the same issue here with my mk3s sensor and MMU2. But it works on my other printer with a mechanical switch. Both are on the same latest Marlin 2.0 branch.
In fact, anyone who can use the IR sensor with marlin 2.0 recent ver exist?? I guess, No.
@wonderland134 still having issues?
will close this one as it seems to be a problem with hardware and not software
And I checked it. filament loaded - m119 result will be filament open filament unloaded - m119 result will be filament triggered.
we can always reopen if it in fact is a marlin issue
Could we please reopen this issue? there is no fix that I can find for it, I tried all the suggestions I can find but none fixed the issue. I did try to turn on the sensor after the print had started but immediately the printer stopped and asked to load the filament. If someone was able to find a fix please let me know.
Could we please reopen this issue? there is no fix that I can find for it, I tried all the suggestions I can find but none fixed the issue. I did try to turn on the sensor after the print had started but immediately the printer stopped and asked to load the filament. If someone was able to find a fix please let me know.
Are you able to use the runout sensor at all? I ran into this issue because I am looking for a solution to why every time I start a new print, it automatically triggers a warning that there is no filament, insert, and press the button to continue. However, once I press the button, it continues the print. The sensor otherwise works properly, except it always starts with triggering first.
I'm using a Makerbot Mechanical Switch Endstop as the detector, when it has filament, it's very obvious because the LED is lit. I'm also using the SKR Mini E3. I'm wondering if this is the same, or different issue as I am experiencing.
Again, once it starts going, the sensor does function normally, if the filament runs out, the print pauses and resumes properly after load, it just always starts asking for filament to be loaded.
try to invert the value of
the runout code defy a bit the logic :p
try to invert the value of
define FIL_RUNOUT_INVERTING true // Set to true to invert the logic of the sensor.
the runout code defy a bit the logic :p
I see what you mean about defying logic. I assumed that when it runs out, it should "trigger" but it also makes sense that "triggered" will let it know that there is filament present. Also, what was confusing was that it would trigger M600 when the state changed, and work properly. Your suggestion to invert the logic corrected the issue I was having, thank you! I think I understand the filament runout logic a bit more now.
I realise this thread is closed but it didn't seem to get resolved. I had exactly the same problem, M119 would say triggered and open when the mechanical switch was activated and M412 would say Filament runout is on, however the print wouldn't stop when the sensor was activated. The solution I found was to go to the configuration menu on the printer. Runout Sensor was stated as off despite M412 confirming otherwise. As soon as I activated it on the printer it worked perfectly. The board is an SKR mini E3 V1.2.
Just to let you know guys, I was having issues with a mechanical filament runout sensor in a skr 1.3. Read a few threads but nothing fixed it. Finally I simply did a store settings in the LCD and boom! working.
@cederron What is the store settings in the LCD? Maybe, is that LCD control store setting exactly same with M500 command? In that case I did, but I can't get proper result. Now I'm give up and only use other printer.
Try these commands from your favorite host:
M412 ; sensor enabled?
M119 ; sensor triggered?
M412 S1 ; enable the sensor
M412 ; enabled?
M119 ; triggered?
M502 ; restore defaults
M412 ; enabled?
M412 S0 ; disable the sensor
M412 ; enabled?
M119 ; triggered?
M412 S1 ; enable the sensor
M500 ; Save to EEPROM
reboot, and go through the commands again.
I can confirm that in the release version 2.0.5.3 this is a problem. I check M412 and filament detection is 'On' , the GUI confirms it, and M119 confirm the hardware is 100%. I tried both true/false on the xxx_inverting, and Marlin still prints with or without filament ..
Description
I downloaded marlin 2.0.x ver. about one week ago. And I upload it with filament runout sensor function. I check filament runout sensor will be fine via pronterface. I send the m119 command and I check open - triggered sign well. But in the print something, filament runout script, m600 is occured when the printing started. Eventhough, filament loaded into extruder.
I will upload my configuration.h and configuration_adv.h files below. config.zip
rly demonstrate the issue.