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.
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
#define FIL_RUNOUT_INVERTING true // Set to true to invert the logic of the sensor.
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 ..
I too am having this issue on 2.0.4.4 As above, M119 is detecting correctly the filament sensor state, So too does the "Change Filament" process, as if i try to bypass the sensor, i get an option to deactivate the sensor. when i dont bypass the sensor, this menu does not appear when changing filament. However when printing from SD card (i'm eliminating the USB for now, and i trigger the Sensor, printer continues with no issue. Checked the code and i have the #define FILAMENT_RUNOUT_SCRIPT "M600"
I have the same problem:
All the above checks out good and as expected, however Marlin fails to run my FILAMENT_RUNOUT_SCRIPT
My FILAMENT_RUNOUT_SCRIPT is set to "#define FILAMENT_RUNOUT_SCRIPT "M118 A1 action:paused". But that shouldn't matter as it never gets run.
How do we go about reopening this issue? It’s obviously a software issue. Someone has even traced it back to which commit it got broken in. Marlin just doesn’t seem to trigger the action.
I re-flashed my system with 1.1.9.. works fine, must be software..
Is this problem solved? I can't get the filament sensors to work, for a printer with mix and vtool, if M600 T0 is placed in the scrip, it works well for printers of an extruder, but not for mix printers
I have an SKR 1.4T with Mk3s IR sensor (Marlin 2.0.5.3 build):
M119 with no filament: 'open' status (this is a good thing)
M119 with filament: 'TRIGGERED status (this is a good thing)
M412 S1: filament sensor enabled
so, it appears that the filament sensor state is being read correctly; however, it does not cause Marlin to go and execute M600 (which I have defined in config.h as #define FILAMENT_RUNOUT_SCRIPT "M600")
So, my sensor works properly but the script is not getting executed ... that is a problem.
The same thing happens to me, but with the original board of my Geeetech A10M printer.
If you send the command via pronterface "M600", it will return that the tool "T" is missing, then in the scrip put like this:
then it works, but for printers with more than 1 extruder like mine it cannot be placed in the "T0" script since it will never change the second extruder.
check this, it may be a partial solution for you.
same problem
well finally the 2 filament sensors work in my A10M, I have changed the code of the files runout.h and runout.cpp
I leave the files here to help with the topic.
replace directly from the base of the Marlin and its sensors work.
note:
1_My printer is a Geeetech A10M with color mixer, and virtual tools activated, and you need to replace the 2 files to run the 2 sensors
2_If your printer fails to activate the filament sensor and it is 1 extruder only, my recommendation is to use the #define FILAMENT_RUNOUT_SCRIPT "M600 T0" directly
@andreslopez93
@cskozlowski
Hi, I try #define FILAMENT_RUNOUT_SCRIPT "M600 T0" but ist not working for me on Ender 3.
Wenn ich make:
Confiiguration/ Filament sensor on= stops immediately the print.
Wenn i change to off: doesn't work.
M119 with no filament: 'open' status (this is a good thing)
M119 with filament: 'TRIGGERED status (this is a good thing)
my sensor works properly but the script is not getting executed ... that is a problem for me too
I changed runout.h and runout.cpp but no working
Try sending the command m600 from pronterface, and see what returns to you, then send m600 t0 and see what returns you.
also share your config.h and adv
It Works on ender 3 with SRK Mini V 1.2!!!
but only with the latest Marlin Version (see below)
@andreslopez93
Load the Last Marlin for SRK Mini here:
https://github.com/bigtreetech/BIGTREETECH-SKR-mini-E3
Change in SRC/PINS/stm32f1/pins_BTT_SKR_MINI_E3.h
to
in configuration.h:
enjoy
Perfect!
that ist my firmware for ender 3 with BL Touch and Filament sensor with SRK mini V1.2
Try at your OWN RISK!!!!!!!
Using Marlin 2.0.5.3 release.
On the Ender 3 I have the filament sensor connected to PIN 27. That PIN is also used by the Speaker. I get douzends of alternating "FILAMENT ON" AND "FILAMENT OFF" lines in Pronterface once I pull the filament out. (You will see these outputs only if you add #define FILAMENT_RUNOUT_SENSOR_DEBUG to your Configuration.h).
I read a comment above that going into the printer configuration menu and turning off and on the filament runout followed by a store settings triggered the filament runout. That is caused by the fact that store settings also sends a beep to the speaker and that triggers PIN27 by definition on the Ender 3.
I tried to #undef BEEPER_PIN, which should have solved it but didn't. I think I am close to the reason.
Will try bugfix branch to see if this resolves it.
On the Ender 3 I have the filament sensor connected to PIN 27
And there are zero other free pins on the board?
Correct, an ender 3 melzi has absolutely zero spare pins without stealing something... Pin 27 from the buzzer is the most common to steal.
I believe that TH3D makes a break-out board to work around the limitation.
Pin 27 is the one it breaks out
Yes, PIN27 is available at the display adapter, which is also the buzzer. Usually undeffing the beeper_pin foxes that but seems not working in 2.0.5.3 anymore.
The Creality boards also have another pin that can be soldered in, PIN29 but a lot of people use pin27 for bltouch and PIN29 for filament runout.
I would like to use PIN27 as this is the easiest way.
Holen Sie sich Outlook für Androidhttps://aka.ms/ghei36
From: InsanityAutomation notifications@github.com
Sent: Saturday, June 27, 2020 1:30:05 AM
To: MarlinFirmware/Marlin Marlin@noreply.github.com
Cc: Daniel Kreuzhofer daniel@kreuzhofer.de; Comment comment@noreply.github.com
Subject: Re: [MarlinFirmware/Marlin] [BUG] Marlin 2.0 filament runout sensor error (#14337)
Pin 27 is the one it breaks out
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/MarlinFirmware/Marlin/issues/14337#issuecomment-650449234, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AANORC2VFWLFRUBVDKPVIR3RYUVP3ANCNFSM4HZUULMA.
If you do not already use the 3Pin connector on the board you populate it
and use 'analogue 2' as input, just use it as discrete. Creality use these
pins to 'Fix' the analogue temperature problem on some boards, so they
solder a cap on 5V and ground on the connector pins. This give you one
extra input pin.
On Sat, Jun 27, 2020 at 1:22 AM Scott Lahteine notifications@github.com
wrote:
I believe that TH3D makes a break-out board to work around the limitation.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/14337#issuecomment-650447244,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD6CXSTT5E7FTYTMXQEYQLLRYUUUFANCNFSM4HZUULMA
.
--
Gerrie de Jager
(Quite people have the loudest minds.
Whether you think you can or you think you can't -- your'ed right.
Don't confuse having less with being less, having more with being more.
Who you are is far more important than what you have.
Ask busy people, others are 'busy')
Cell 072 198 1678
www.creatron.co.za http://www.creatron.co.za
This e-mail, its contents and any file attachments transmitted with it are
intended solely for the addressee(s) and may contain confidential
proprietary information. Access by any other party without the express
written permission of the sender is unauthorised. If you have received this
e-mail in error you may not copy, distribute or use the contents,
attachments or information in any way. Please destroy it and contact the
sender.
Yes, that's PIN29. However, it should be possible to disable the use of the beeper in Marlin, shouldn't it be? Why is the beeper pin still firing when for example store settings is triggered from the menu although I did #undef BEEPER_PIN?
Holen Sie sich Outlook für Androidhttps://aka.ms/ghei36
From: creatron notifications@github.com
Sent: Saturday, June 27, 2020 5:51:32 PM
To: MarlinFirmware/Marlin Marlin@noreply.github.com
Cc: Daniel Kreuzhofer daniel@kreuzhofer.de; Comment comment@noreply.github.com
Subject: Re: [MarlinFirmware/Marlin] [BUG] Marlin 2.0 filament runout sensor error (#14337)
If you do not already use the 3Pin connector on the board you populate it
and use 'analogue 2' as input, just use it as discrete. Creality use these
pins to 'Fix' the analogue temperature problem on some boards, so they
solder a cap on 5V and ground on the connector pins. This give you one
extra input pin.
On Sat, Jun 27, 2020 at 1:22 AM Scott Lahteine notifications@github.com
wrote:
I believe that TH3D makes a break-out board to work around the limitation.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/14337#issuecomment-650447244,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD6CXSTT5E7FTYTMXQEYQLLRYUUUFANCNFSM4HZUULMA
.
--
Gerrie de Jager
(Quite people have the loudest minds.
Whether you think you can or you think you can't -- your'ed right.
Don't confuse having less with being less, having more with being more.
Who you are is far more important than what you have.
Ask busy people, others are 'busy')
Cell 072 198 1678
www.creatron.co.za http://www.creatron.co.za
This e-mail, its contents and any file attachments transmitted with it are
intended solely for the addressee(s) and may contain confidential
proprietary information. Access by any other party without the express
written permission of the sender is unauthorised. If you have received this
e-mail in error you may not copy, distribute or use the contents,
attachments or information in any way. Please destroy it and contact the
sender.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/MarlinFirmware/Marlin/issues/14337#issuecomment-650577787, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AANORC6YXI5YG3U7F4DFPITRYYIQJANCNFSM4HZUULMA.
Hello, feature also not work for me on Marlin 2.0 if #define FILAMENT_RUNOUT_DISTANCE_MM enabled.
with commented #define FILAMENT_RUNOUT_DISTANCE_MM feature works fine.
I can confirm it’s fixed in the bugfix branch
I did
#undef BEEPER_PIN
If you add that line to the end of pins/pins.h
it will have the desired effect.
Preemptively defining BEEPER_PIN
as -1 in the configurations should also prevent it being defined with another value.
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.