MK3 PAT9125 filament sensor fix to prevent false runouts #3979
Conversation
|
I do not think these changes are correct. An alternative to the new plug with chamfer is actually no plug at all. This is what the sensor sees without a plug:
There are not enough resources for this unfortunately. And even if the value was customizable, with the stock hardware configuration it is not possible to reliably differentiate between no filament and a very IR absorbant filament. |
|
HI
Thank you for so detailed review, it reveals new info, I didn't expect
sensor is capable to see whole picture, this thing is advanced and
it should provide sufficient data to detect filament presence with some
smarty written code
I probably have old design because with no filament my readings
were S=17, B=63 and after vacuuming cleaning I got B=43..50
I should find on the network new design, print and replace to get
low B values.
My experience was not that B values were to low but code was working
buggy and therefrom I got printer stop and do false runouts. When
looking at the code, things did look there are places for buggy behavior.
I designed hall sensor replacement to upgrade MK2S and MK3
as I have to dissasemble most of MK3 extruder just to pass new wire,
I decided to recompile firmware to use old wiring but as I recompiled
I said let's give old sensor a chance. if I can't fix for black PETG I would
dissasemble and put hall.
Recompiled firmware worked for many printed PETG hours and it is stil
able to detect presence/absence of black filament fast enough. White
PETG detects faster.
My change of the code affects logic for presence direction detection in
case of S=17 and keeps old behaviour for S<17. I know I added similar
code like for Jam detection, but adding movement I found as good resort
for difficult case of S=17. For S<17 logic stays the same as before,
just I added more retries. Also I moved code that should not be always
executed inside of if() loop where it belongs, to reduce cpu usage. I have
additional idea to more simplify and additional small cpu saving too
Second change is that for filament jam, code looked "unsymmetrical"
and just added next to filament presence code in a hurry.
I moved the code inside of the 10 ms interval filter in order not to read
sensor too fast and not to possibly init() it too fast or at unpredictably close
intervals in time. Sensors have CPUs RTOSes and polling them too often
may lead to their own bugs exposed, and again we save cpu resources.
Additional change in jam is that filament
jam decsion now has not only 2 states, but 3 states: backwards, no motion,
forward (I have threshold +1 -1 but that could be increased probably). Filament
that is stuck and still being driven by gears on clicking extruder
will surely make
more than +/-1 advance (before it was 0/1). So real filament jam detection
(theoretically, in my opinion just looking at code) is not capable to detect
real jam. Threshold should be increased to something like 4-8, but to
find proper
value I probably need printer with jammed extruder to correctly tune that, maybe
I can experiment with cold hotend but that's not the same.
…On 1/31/23, Alex Voinea ***@***.***> wrote:
I do not think these changes are correct.
For a start, this code has a change in logic where filament motion is
treated as filament being present. That is wrong. The sensor can
unfortunately also "see" sporadic motion on it's own, even if it's looking
at something that is perfectly static. This motions is also not checked for
the correct direction (or any commanded motion for that matter). As such,
filament presence should be relied exclusively on the shutter time (S) and
on the average brightness (B). When there is no filament, the S value is
maximal (S=17) and the brightness value is minimal. Unfortunately, this
minimal value can be influenced by external factors, such as the extruder
plastics.
Below you can see two idler plug pieces. This is the plastic part that is
seen by the sensor if there is no filament. The one on the right is the
original part, while the one on the left is the proposed improved version.
The reason the original part is not working correctly is because the laser
ray is perpendicular to the surface of the part. Because of that (and
because PETG is glossy), the ray is reflected back right into the sensing
array of the sensor. This results in a quite high B value (20-90) even with
no filament inserted. To make matters worse, this B value is almost
identical to what black petg (and other dark/transparent) filaments reflect
back, so differentiating the two is basically impossible. To counteract this
problem, the chamfer that can be seen in the left picture was added. The
purpose of that chamfer is to NOT have a direct reflection from the laser
back into the sensor when there is no filament. This updated design results
in very low B values when no filament is inserted and is much more
reliable.
As I did this testing 2 years ago, I no longer have all the data, but from
what I could easily find:
Printer 1: old plug has B/S=74/17, new plug has B/S=10/17
Printer 2: old plug has B/S=75/17, new plug has B/S=12/17
An alternative to the new plug with chamfer is actually no plug at all. This
is what the sensor sees without a plug:
The downside to this approach is that the filament sensor is no longer
completely covered. As such, external IR sources could interfere with it.
> For further improvment I'd suggest filament presence threshold to be some
> settings parameter stored in eeprom so user can fine tune this for
> particular hardware differences.
There are not enough resources for this unfortunately. And even if the value
was customizable, with the stock hardware configuration it is not possible
to reliably differentiate between no filament and a very IR absorbant
filament.
--
Reply to this email directly or view it on GitHub:
#3979 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
|
your no-reflection idler plug makes big improvement
on unloaded filament old B=43..50, new B=9..10 wonderful!
So I can set back detection threshold to 50.
I increased Jam threshold to +-8, seems a reasonable value,
printed a bit of black PETG without false jam detection.
This threshold could be increased more.
False jams in my case were not based on filament not reflecting
enough light but some unpredictable behavior in combination of
filament code and sensor because even on white PETG filament
printer was stopping and asking for unloading.
A similar code logic, slightly rewritten/reworked so far fixes my problems.
So far all works good but I should print PETG transparent filament
which was problematic for the sensor before.
…On 1/31/23, D EMARD ***@***.***> wrote:
HI
Thank you for so detailed review, it reveals new info, I didn't expect
sensor is capable to see whole picture, this thing is advanced and
it should provide sufficient data to detect filament presence with some
smarty written code
I probably have old design because with no filament my readings
were S=17, B=63 and after vacuuming cleaning I got B=43..50
I should find on the network new design, print and replace to get
low B values.
My experience was not that B values were to low but code was working
buggy and therefrom I got printer stop and do false runouts. When
looking at the code, things did look there are places for buggy behavior.
I designed hall sensor replacement to upgrade MK2S and MK3
as I have to dissasemble most of MK3 extruder just to pass new wire,
I decided to recompile firmware to use old wiring but as I recompiled
I said let's give old sensor a chance. if I can't fix for black PETG I
would
dissasemble and put hall.
Recompiled firmware worked for many printed PETG hours and it is stil
able to detect presence/absence of black filament fast enough. White
PETG detects faster.
My change of the code affects logic for presence direction detection in
case of S=17 and keeps old behaviour for S<17. I know I added similar
code like for Jam detection, but adding movement I found as good resort
for difficult case of S=17. For S<17 logic stays the same as before,
just I added more retries. Also I moved code that should not be always
executed inside of if() loop where it belongs, to reduce cpu usage. I have
additional idea to more simplify and additional small cpu saving too
Second change is that for filament jam, code looked "unsymmetrical"
and just added next to filament presence code in a hurry.
I moved the code inside of the 10 ms interval filter in order not to read
sensor too fast and not to possibly init() it too fast or at unpredictably
close
intervals in time. Sensors have CPUs RTOSes and polling them too often
may lead to their own bugs exposed, and again we save cpu resources.
Additional change in jam is that filament
jam decsion now has not only 2 states, but 3 states: backwards, no motion,
forward (I have threshold +1 -1 but that could be increased probably).
Filament
that is stuck and still being driven by gears on clicking extruder
will surely make
more than +/-1 advance (before it was 0/1). So real filament jam detection
(theoretically, in my opinion just looking at code) is not capable to
detect
real jam. Threshold should be increased to something like 4-8, but to
find proper
value I probably need printer with jammed extruder to correctly tune that,
maybe
I can experiment with cold hotend but that's not the same.
On 1/31/23, Alex Voinea ***@***.***> wrote:
> I do not think these changes are correct.
> For a start, this code has a change in logic where filament motion is
> treated as filament being present. That is wrong. The sensor can
> unfortunately also "see" sporadic motion on it's own, even if it's
> looking
> at something that is perfectly static. This motions is also not checked
> for
> the correct direction (or any commanded motion for that matter). As such,
> filament presence should be relied exclusively on the shutter time (S)
> and
> on the average brightness (B). When there is no filament, the S value is
> maximal (S=17) and the brightness value is minimal. Unfortunately, this
> minimal value can be influenced by external factors, such as the extruder
> plastics.
> Below you can see two idler plug pieces. This is the plastic part that is
> seen by the sensor if there is no filament. The one on the right is the
> original part, while the one on the left is the proposed improved
> version.
> The reason the original part is not working correctly is because the
> laser
> ray is perpendicular to the surface of the part. Because of that (and
> because PETG is glossy), the ray is reflected back right into the sensing
> array of the sensor. This results in a quite high B value (20-90) even
> with
> no filament inserted. To make matters worse, this B value is almost
> identical to what black petg (and other dark/transparent) filaments
> reflect
> back, so differentiating the two is basically impossible. To counteract
> this
> problem, the chamfer that can be seen in the left picture was added. The
> purpose of that chamfer is to NOT have a direct reflection from the laser
> back into the sensor when there is no filament. This updated design
> results
> in very low B values when no filament is inserted and is much more
> reliable.
> 
> As I did this testing 2 years ago, I no longer have all the data, but
> from
> what I could easily find:
> Printer 1: old plug has B/S=74/17, new plug has B/S=10/17
> Printer 2: old plug has B/S=75/17, new plug has B/S=12/17
>
> An alternative to the new plug with chamfer is actually no plug at all.
> This
> is what the sensor sees without a plug:
> 
> The downside to this approach is that the filament sensor is no longer
> completely covered. As such, external IR sources could interfere with it.
>
>> For further improvment I'd suggest filament presence threshold to be
>> some
>> settings parameter stored in eeprom so user can fine tune this for
>> particular hardware differences.
>
> There are not enough resources for this unfortunately. And even if the
> value
> was customizable, with the stock hardware configuration it is not
> possible
> to reliably differentiate between no filament and a very IR absorbant
> filament.
>
> --
> Reply to this email directly or view it on GitHub:
> #3979 (comment)
> You are receiving this because you authored the thread.
>
> Message ID: ***@***.***>
|
The sensor is indeed capable of outputing raw data, however, that is not the intended usage of the sensor. Since the sensors is used with I2C, the bandwidth is very limited, so it is not possible to pull data in realtime. Moreover, processing the data is not an easy task to do, so I don't expect this to be something possible on the atmega2560. The sensor outputs a 18x18 pixel grid with the image when used in the pixel grabbing mode. The motion tracking part of the sensor is disabled when this mode is enabled, so only Brightness and Shutter time can be used while in this mode.
The design you had is the official one. Unfortunately, the no_reflection plug I linked is only a PR of mine and no MK3 printers have it by default. That's why I was proposing using no plug at all if a plug like that can't be printed by the user.
I need to check your changes more carefully about the buggy part. Unfortunately I'm really busy at the moment, so that might take a while. Rest assured, if there are some bugs in the code which this PR fixes, I'll try to get that part merged before 3.13 is released.
I mean, that's exactly how it was added. The primary focus of the new code was to first get filament presence working more reliably and then add jam detection with motion tracking as a bonus.
This is not the case. The sensor is fast enough to be polled continuously. But it is true that we shouldn't poll the sensor too often from the printer side since that takes CPU time that we don't have.
On my printer it worked just fine, so idk what to say.
Yes, the values in the code were chosen for the new plug. It could be even lower with that plug, but I left some margin so that it would still work with the old plug somewhat.
Be careful with these thresholds. You want to be able to detect the jam as soon as possible. For the MMU stuff I also need to detect a jam with not too much motion. The current value seemed to work fine in my case to detect when the printer failed to grab the filament on toolchange.
It's unfortunate that with the current code it is not clear whether a runout event happened or a jam event happened, but I'm not sure this will improve any time soon. So be aware that it could have been either of them, but be displayed the same way on screen.
I'm still quite surprised you have issues with transparent-green petg. In my testing, it seemed to perform quite well actually. This is in contrast to bright petg filaments such as Prusament orange petg which performed the worst. Prusament PETG orange: Just for completeness, this is also what Prusament PLA Galaxy Black looks like (quite good): I'll appologise in advance since I am quite busy for now, so my responses will probably be slow. |
|
HI
Thanx for the review and I agree with your comments.
I kinda noticed the filament runout and jam reported
idendical message, and to find which one is responsible
I separately enabled one of them, fixed code, enabled both.
Currently my code is slow to detect jam but at least it works
reliable on my non-MMU unit. Printed 20+ hours of black and
white PETG no false jam. Made a knot on filament to simulate
jam and it detects it.
Old code couldn't detect knot jam, because printing consists
of extrusion and retraction moves. Jams (optical moving not following
motor steps) count as +1, normal operation count as -1, clamped down to 0
When knot stops filament, jam will increment +1 and let's assume extrusion
is small so 10 errors aren't reached in one extrusion. Then retraction comes,
PETG knot will retract freely so counter decrements -1 and then extrusion
again comes with previously retracted filament now moves freely down to knot,
counter never reaches 10, jam detection never happens
while extruder constantly clicking.
A simple change to increment counter +2 on jam error and decrement -1
on OK operation assured, in my tests, knot-jam to be detected.
If faster response is needed probably counter limit of 10 should first
be reduced, then threshold increased (larger threshold = more sensitive).
Some experimentation should be done to make detection reliable and
prevent annoying false stops.
I recommend to try my changes, currently I'm quite satisfied how it works
no more problems with the MK3 sensor
…On 2/6/23, Alex Voinea ***@***.***> wrote:
> I didn't expect sensor is capable to see whole picture, this thing is
> advanced and it should provide sufficient data to detect filament presence
> with some smarty written code.
The sensor is indeed capable of outputing raw data, however, that is not the
intended usage of the sensor. Since the sensors is used with I2C, the
bandwidth is very limited, so it is not possible to pull data in realtime.
Moreover, processing the data is not an easy task to do, so I don't expect
this to be something possible on the atmega2560. The sensor outputs a 18x18
pixel grid with the image when used in the pixel grabbing mode. The motion
tracking part of the sensor is disabled when this mode is enabled, so only
Brightness and Shutter time can be used while in this mode.
> I probably have old design because with no filament my readings were S=17,
> B=63 and after vacuuming cleaning I got B=43..50. I should find on the
> network new design, print and replace to get low B values.
The design you had is the official one. Unfortunately, the no_reflection
plug I linked is only a PR of mine and no MK3 printers have it by default.
That's why I was proposing using no plug at all if a plug like that can't be
printed by the user.
> My experience was not that B values were to low but code was working buggy
> and therefrom I got printer stop and do false runouts. When looking at the
> code, things did look there are places for buggy behavior.
I need to check your changes more carefully about the buggy part.
Unfortunately I'm really busy at the moment, so that might take a while.
Rest assured, if there are some bugs in the code which this PR fixes, I'll
try to get that part merged before 3.13 is released.
> Second change is that for filament jam, code looked "unsymmetrical" and
> just added next to filament presence code in a hurry.
I mean, that's exactly how it was added. The primary focus of the new code
was to first get filament presence working more reliably and then add jam
detection with motion tracking as a bonus.
> I moved the code inside of the 10 ms interval filter in order not to read
> sensor too fast and not to possibly init() it too fast or at unpredictably
> close intervals in time. Sensors have CPUs RTOSes and polling them too
> often may lead to their own bugs exposed, and again we save cpu
> resources.
This is not the case. The sensor is fast enough to be polled continuously.
But it is true that we shouldn't poll the sensor too often from the printer
side since that takes CPU time that we don't have.
> So real filament jam detection (theoretically, in my opinion just looking
> at code) is not capable to detect real jam
On my printer it worked just fine, so idk what to say.
> your no-reflection idler plug makes big improvement on unloaded filament
> old B=43..50, new B=9..10 wonderful! So I can set back detection threshold
> to 50.
Yes, the values in the code were chosen for the new plug. It could be even
lower with that plug, but I left some margin so that it would still work
with the old plug somewhat.
> I increased Jam threshold to +-8, seems a reasonable value, printed a bit
> of black PETG without false jam detection. This threshold could be
> increased more.
Be careful with these thresholds. You want to be able to detect the jam as
soon as possible. For the MMU stuff I also need to detect a jam with not too
much motion. The current value seemed to work fine in my case to detect when
the printer failed to grab the filament on toolchange.
> False jams in my case were not based on filament not reflecting enough
> light but some unpredictable behavior in combination of filament code and
> sensor because even on white PETG filament printer was stopping and asking
> for unloading.
It's unfortunate that with the current code it is not clear whether a runout
event happened or a jam event happened, but I'm not sure this will improve
any time soon. So be aware that it could have been either of them, but be
displayed the same way on screen.
> A similar code logic, slightly rewritten/reworked so far fixes my
> problems. So far all works good but I should print PETG transparent
> filament which was problematic for the sensor before.
I'm still quite surprised you have issues with transparent-green petg. In my
testing, it seemed to perform quite well actually. This is in contrast to
bright petg filaments such as Prusament orange petg which performed the
worst.
Colorfabb NGEN transparent green:
https://user-images.githubusercontent.com/17808203/217053177-e8b9be0f-e10a-40da-b32b-8d7d7b6328ec.mp4
Prusament PETG orange:
https://user-images.githubusercontent.com/17808203/217053345-a383dae7-6097-458c-b677-2a82e1f76f1d.mp4
Just for completeness, this is also what Prusament PLA Galaxy Black looks
like (quite good):
https://user-images.githubusercontent.com/17808203/217053408-7e8f7130-f9e8-4a25-a63d-1220d5576096.mp4
I'll appologise in advance since I am quite busy for now, so my responses
will probably be slow.
--
Reply to this email directly or view it on GitHub:
#3979 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Yes, I will test these changes soon on a MK2.5 with and without MMU and see how it performs.
I think this test might be out of the scope of "jam detection". The issue you are describing is valid, but I think it's not what most people encounter when the printer jams. They instead get a filament which is grinded by the gears so it moves very little (that includes retractions not moving). Or at least this is how it works with PLA. It might be different with other filaments which don't get grinded so easily by the extruder.
This sounds like a good approach, but it needs to be tested and validated again on a range of filaments... not looking forward to that. |
|
Yes that's good approach, I'd say jam detection should pass
"knot" test and also perform well at real jam events.
Your no-reflection idler plug is a must, it should go to "mainstream"
3D printable model, I wish it was there from the start but it's never too late :)
Plug is easy to print and replace, no screws just pull out old one and insert new.
If someone has a farm of many printers with jammed extruder
it could be good to check. I have only one MK3 with PAT9125
sensor. My other is MK2S upgraded to MK2.5S with hall filament
sensor.
I have another idea for MK3* series jam detection,
Maybe extruder motor is on a same smart stepper driver which
can detect clicks, similar as XY motor sense "endstops" when
they hit obstacle. So I'd suggest motor click detection in parallel
to filament sensing for faster reaction and cover different
cases of jams.
Increasing jam threshold in my jam code
increases sensitivity, but also increases probability for
false jam detection. When I set it to +-20 I get false jams.
Setting to +-12 didn't have false jams. I leave it to +-8 on
the safe side, currently it performs correctly at knot test.
…On 2/6/23, Alex Voinea ***@***.***> wrote:
> I recommend to try my changes, currently I'm quite satisfied how it works
no more problems with the MK3 sensor
Yes, I will test these changes soon on a MK2.5 with and without MMU and see
how it performs.
> Old code couldn't detect knot jam, because printing consists
of extrusion and retraction moves. Jams (optical moving not following
motor steps) count as +1, normal operation count as -1, clamped down to 0
I think this test might be out of the scope of "jam detection". The issue
you are describing is valid, but I think it's not what most people encounter
when the printer jams. They instead get a filament which is grinded by the
gears so it moves very little (that includes retractions not moving). Or at
least this is how it works with PLA. It might be different with other
filaments which don't get grinded so easily by the extruder.
If "knot" jam detection can be brought to a reliable point, then I have no
issue with it. But the thresholds must be chosen carefully such that it
responds in a reasonable time, while also not causing false detections on
filaments that track incredibly poorly such as (older no longer sold
versions of) this one:
https://www.prusa3d.com/product/prusament-pla-ms-pink-blend-970g/
> A simple change to increment counter +2 on jam error and decrement -1
on OK operation assured, in my tests, knot-jam to be detected.
This sounds like a good approach, but it needs to be tested and validated
again on a range of filaments... not looking forward to that.
--
Reply to this email directly or view it on GitHub:
#3979 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
|
I have tested sensor code printing 10 hours with And I have real extruder jam now. End of filament IMHO filament sensor should not be in the extruder |
|
I've rebased the PR on top of the latest MK3 branch. I'll probably rebase it again soon after #4132 is merged. |
with black or transparent PETG.
Updated R3 extruder idler plug with no IR reflection prusa3d/Original-Prusa-i3#173
It is assumed (but not tested in practice) that clicking extruder with jammed filament moves below the jam threshold so it triggers jam alert, while normal extrusion moves above the threshold and should not trigger jam alert.
by filter=0 counter instead of filter--. Remove condition of moving filament for detection, assumed no-reflection plug is used. Less code saves flash by cca 100 bytes.
cut 30 cm black PETG, Make a tight knot, turn off printer, push filament into extruder, print something. Knot will simulate jam and after 10-20 extruder clicks printer should stop.
value reduced because after few hours of black PETG priting, false runout occured with 50
one false runout occured after few hours printing with transparent PETG
again false runout occured after few hours printing with transparent PETG
30->50 transparent PETG still causes false runouts
tuning: increase filament jam error count threshold 10->20
For me it solves issues with black or transparent PETG,
filament runout and jam enabled and it keeps printing.
For further improvment I'd suggest filament presence
threshold to be some settings parameter stored in eeprom
so user can fine tune this for particular hardware differences.