Inconsistent results with optical encoder wheel filament sensor
-
@arhi said in Inconsistent results with optical encoder wheel filament sensor:
@JohnOCFII said in Inconsistent results with optical encoder wheel filament sensor:
minimum 91%, maximum 109%
awesome
so would be cool if @dc42 can implement sometimes in future Schottky input on the MCU for endstop inputs as it is supported from what I see in the datasheet.
Yeah, it would be. And based on my testing so far, I wish I had known that the CONN_LCD input apparently does have the same input filter (or something) as the e0 and e1stop. I certainly got less wacky results once I switched from CONN_LCD to e1stop.
-
@JohnOCFII said in Inconsistent results with optical encoder wheel filament sensor:
The LED on the optical sensor now is behaving opposite to the sensor on the DUET e1stop.
Yes, it's inverted, but it makes ZERO difference since you are not using it as an endstop, but rather as a pulse for the filament monitor.
If you care to have the lights be the same, just wire two of the inverters in series and it will invert twice and make it not-inverted anymore!
Pin 1 input from sensor
Pin 2 connect to pin 3
Pin 4 connect to Duet. -
@alankilian said in Inconsistent results with optical encoder wheel filament sensor:
If you care to have the lights be the same, just wire two of the inverters in series and it will invert twice and make it not-inverted anymore!
Pin 1 input from sensor
Pin 2 connect to pin 3
Pin 4 connect to Duet.Oooh! I might try that. Thanks!
-
@JohnOCFII said in Inconsistent results with optical encoder wheel filament sensor:
Spacing seems somewhat different too, but I can't imagine that matters in this case.
The timing difference between the Saleae edge and the Schmitt trigger inverter edge is all caused by the difference in "threshold" voltages between the two and the VVVVEEEERRRRYYY SSSSLLLLOOOOOOOOWWWWLLLLYYY changing signal from your optical interruptor.
The Saleae trace you posted shows the Schmitt trigger working PERFECTLY!!!
You're only getting one transition for each fuzzy/mushy/multiple-edge-bouncing-ball transition you see in the optical-interrupter output Saleae signal.
-
@alankilian said in Inconsistent results with optical encoder wheel filament sensor:
The Saleae trace you posted shows the Schmitt trigger working PERFECTLY!!!
That is fantastic to hear!
I went ahead and passed the signal through the adjacent inverter. I don't know why, but it makes me smile.
-
Another test before I swap encoder wheels. Very consistent results. This was a 3D Benchy.
Pulse-type filament monitor on pin !e1stop, disabled, sensitivity 4.000mm/pulse, allowed movement 30% to 1500%, check every 5.0mm, measured sensitivity 4.034mm/pulse, measured minimum 91%, maximum 109% over 871.3mm -
@JohnOCFII said in Inconsistent results with optical encoder wheel filament sensor:
Very consistent results.
That looks really great!
The pulse-type monitor already has some filtering in the code, so I really should learn how to build the code and see if I can implement a delay-based debouncer in there with a setting so it can be configured for zero to a LOT of debouncing.
-
@JohnOCFII said in Inconsistent results with optical encoder wheel filament sensor:
check every 5.0mm, measured sensitivity 4.034mm/pulse
I wonder if you should be checking less often.
Checking every 5mm when you only get one pulse every 4mm means the checking mechanism basically gets 0 or 1 pulse to go by.
Maybe check every 20mm? Would that make too big a mess when you DO run out of filament?
Hey, can you do some tests where you cut the filament mid-print a few times and show how nice the restart looks?
(I can do that also, but I'm in the middle of a paid job that will keep my printer running 24/7 through mid December)
-
@alankilian said in Inconsistent results with optical encoder wheel filament sensor:
@JohnOCFII said in Inconsistent results with optical encoder wheel filament sensor:
check every 5.0mm, measured sensitivity 4.034mm/pulse
I wonder if you should be checking less often.
Checking every 5mm when you only get one pulse every 4mm means the checking mechanism basically gets 0 or 1 pulse to go by.
One thing I plan to do is try the encoder wheel with more "spokes." This should give me a pulse closer to every 2.4mm. I can then also increase the distance. I know that @fractalengineer was checking at a much longer distance.
Maybe check every 20mm? Would that make too big a mess when you DO run out of filament?
Hey, can you do some tests where you cut the filament mid-print a few times and show how nice the restart looks?
Oh yes, once I try the other wheel, my next plan is to actually test what happens by both cutting the filament before it gets to the wheel and then changing/restarting to see then impact, as well as to cut the filament after it has passed through the encoder wheel (to replicate a non-moving, or jammed state), and then to restart from that.
John
-
Today I swapped in the encoder wheel with more narrower "spokes."
First run (fairly short) looked pretty good:
Pulse-type filament monitor on pin e1stop, disabled, sensitivity 2.400mm/pulse, allowed movement 30% to 900%, check every 10.0mm, measured sensitivity 1.720mm/pulse, measured minimum 132%, maximum 143% over 282.0mmI realized the pulse wasn't every 2.4mm, so I reset for closer to the 1.72 I was seeing here, and got these consistent results across a number of prints:
Pulse-type filament monitor on pin e1stop, disabled, sensitivity 1.710mm/pulse, allowed movement 30% to 900%, check every 6.0mm, measured sensitivity 1.713mm/pulse, measured minimum 82%, maximum 118% over 2541.8mmI also modified the check to be every 6.0mm which should allow 3 pulses. The percentage "window" seems a bit larger, but I assume that is because the actual distance is allowed is shorter due to the narrow spokes and the 6mm distance.
Either way, this continues to be very repeatable!
Next tests (maybe tomorrow, but sadly my vacation is over) will be to cut the filament and see how it responds.
-
Today I tested cutting the filament both ahead of the optical filament sensor (to replicate an extruder jam) and behind the sensor (to replicate running out of filament.
Both tests were successful, in that the sensor noted the problem, and called pause.g. With my current settings, the restart was quick enough that the problems were not terribly noticeable, except on one pause/restart on the top surface of a model.
All was not peaches and cream, though. After I did those two tests (about 3 minutes apart), the optical sensor caused 4 false alarms, requiring me to restart the print. The logic analyzer was operating, and the optical sensor was truly not seeing movement during these issues, so this must have been a physical issue -- not sure what would have caused it.
Tomorrow I'll try to run Benchy (without causing filament issues) to see if this magically goes away after a restart. It did appear that RRF properly resets the filament sensor after each restart, in that I would check after the pause, and see results such as:
Pulse-type filament monitor on pin e1stop, enabled, sensitivity 1.710mm/pulse, allowed movement 30% to 900%, check every 6.0mm, measured sensitivity 1.696mm/pulse, measured minimum 0%, maximum 214% over 305.3mmAnd after restarting, I'd see:
Pulse-type filament monitor on pin e1stop, enabled, sensitivity 1.710mm/pulse, allowed movement 30% to 900%, check every 6.0mm, measured sensitivity 1.729mm/pulse, measured minimum 96%, maximum 102% over 62.2mmSo -- looking good, if I can figure out these false issues. Maybe my wheel slipped?
-
@JohnOCFII interesting.
This sensor design I designed to be optimized for cost and printability; the grip on the wheel is set by the TPU/TPE preload and friction only
The idea being that there is virtually no resistance on the axle; it should roll freely with the only friction being in the bearings.
So really there shouldn't be any concern for wheel slipping...unless your wheel is so undersized or your PTFE ID so oversized/worn out
I had an idea for a "pro" version with an extruder cog and spring-loaded bearing to remove these issues from the equation at the expense of more parts and larger packaging, but in the meantime I could get you a revision with the axle popping out of the housing to check the grip
-
@fractalengineer said in Inconsistent results with optical encoder wheel filament sensor:
but in the meantime I could get you a revision with the axle popping out of the housing to check the gripI like the current design. I was thinking of cutting a whole in the top case to be able to visually check the encoder wheel to confirm it was moving.
I wonder if the multiple filament loading and unloading during the session somehow messed things up. What I'll do today is look things over closely, then start a print and see if it completes, and if it doesn't, maybe I'll get more clues to the situation. I'm also not sure if increasing beyond 6mm would help this situation or not. Ideally, I'd note the filament problem as quickly as I can, so I have the least amount of lost print area to cover.
-
I made a version that uses bondtech’s hobbed gears to spin the optical wheel, since it has positive engagement. You may want to try that. I can also share the design. It otherwise uses the same/similar parts.
-
I figured out my issue with non-movement related false alarms:
(The PTFE fell out in my repeated replacement of filament...)
-
@JohnOCFII said in Inconsistent results with optical encoder wheel filament sensor:
I figured out my issue with non-movement related false alarms
Gravity sucks!
I'ts been a really fun ride watching you build/diagnose/deal-with-it and then show success with this project.
Thanks for sharing your journey with us housebound folks.
-
@alankilian said in Inconsistent results with optical encoder wheel filament sensor:
@JohnOCFII said in Inconsistent results with optical encoder wheel filament sensor:
I figured out my issue with non-movement related false alarms
Gravity sucks!
Indeed!
I'ts been a really fun ride watching you build/diagnose/deal-with-it and then show success with this project.
Happy to share. I figure someone out there might benefit, so why not share?
Thanks for sharing your journey with us housebound folks.
I'd be nowhere without you and @arhi and of course, the great design from @fractalengineer!
-
Just a quick update.
The sensor continues to work well:
Pulse-type filament monitor on pin e1stop, enabled, sensitivity 1.710mm/pulse, allowed movement 30% to 900%, check every 6.0mm, measured sensitivity 1.748mm/pulse, measured minimum 95%, maximum 102% over 255.9mmI hadn't been printing on this printer for a few weeks, and had left some PLA mounted. I started a print today, and on the first layer, I heard the print pause, and the print carriage start to move out of the way. My first thought was, "Oh oh -- a false alarm." Looking more closely, I saw it had triggered on a real filament failure. The filament in the feed tube had broken after the filament sensor, so the filament wasn't moving!
Filament swapped, and print continues!
And as @fractalengineer and I started to think about how to put the ST in the sensor package, he found a board on Ali Express that already had the ST as part of the optical sensor! He and I each ordered a few, and some day -- they will arrive.
I'll report back when that happens.
John
-
@JohnOCFII wow very nice and did that leave a mark on the print?
or does it resume from the beginning of the layer/layer before?
I'm thinking that with such tight measured error we could reduce the measurement distance to improve the reactivity
-
@fractalengineer said in Inconsistent results with optical encoder wheel filament sensor:
@JohnOCFII wow very nice and did that leave a mark on the print?
or does it resume from the beginning of the layer/layer before?
It resumes from where it senses the error, so with my configuration, that could be up to 6mm after the break. I don't know that I'd want to get any shorter than that, for fear of false alarms. I think I'd have to test with something like a vase-mode print to see what the possible imperfection could be.
Many times you'll get lucky, and a failure will happen on infill, and not an exterior perimeter. In that case, you shouldn't see anything. In this case, it was on a first layer and there was a tiny hole, but not something I'd be likely to see.
John
