Inconsistent results with optical encoder wheel filament sensor

[JohnOCFII]

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

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

[Nuramori]

@JohnOCFII

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.

[JohnOCFII]

I figured out my issue with non-movement related false alarms:

(The PTFE fell out in my repeated replacement of filament...)

[alankilian]

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

[JohnOCFII]

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

[JohnOCFII]

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.9mm

I 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

[fractalengineer]

@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

[JohnOCFII]

@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

[JohnOCFII]

FYI -- still loving the results!

Pulse-type filament monitor on pin e1stop, enabled, sensitivity 1.710mm/pulse, allowed movement 30% to 900%, check every 6.0mm, measured sensitivity 1.727mm/pulse, measured minimum 87%, maximum 111% over 3654.4mm

@fractalengineer has received his new optical sensor with ST. Mine are still enroute.

[JohnOCFII]

Yes, maybe I am bragging a bit, but this was a team effort after all:

Longest print to date with the filament sensor:

M591 D0
Pulse-type filament monitor on pin e1stop, enabled, sensitivity 1.710mm/pulse, allowed movement 30% to 900%,
check every 6.0mm, measured sensitivity 1.753mm/pulse, measured minimum 46%, maximum 140% over 52885.0mm

The new optical sensor with Schmitt Trigger has arrived -- now just waiting on the stars to align before I can test it.

John

[dc42]

This thread may be of interest https://forum.duet3d.com/topic/4498/filament-monitor-using-hc-020k-encoder. The issue was that the HC-020K optical sensor used a comparator with no hysteresis. That is an elementary design mistake, that causes the output to bounce between high and low many times whenever the output transitions, instead of providing a clean edge. Adding a resistor to the comparator circuit to provide positive feedback solved that.

[JohnOCFII]

I've got the new optical sensor with the integrated Schmitt Trigger installed and operating. Seems to be working fine, and showing clean signals.

Pulse-type filament monitor on pin e1stop, disabled, sensitivity 2.000mm/pulse, allowed movement 30% to 900%, check every 6.0mm, measured sensitivity 2.002mm/pulse, measured minimum 88%, maximum 123% over 758.9mm

Full Saleae log available on request.

John

[arhi]

@JohnOCFII that is nice, obviously the encoder input is not having Schmitt trigger input so simple analog devices will not work. Not sure why 'cause if I remember correctly these inputs can have ST input turned on in port configuration. One hint - what logic analyzer sees and what duet sees are not identical!!! It is similar as you have a similar input port on the CY in the logic analyzer as is on the SAM in duet but they are not the same.