Inconsistent results with optical encoder wheel filament sensor

JohnOCFII

@alankilian said in Inconsistent results with optical encoder wheel filament sensor:

Then green-arrow and extrude.
Stop and File->Save Capture and you can post it.

I set up a capture during a vase mode cylinder print. Speed was 15mm/sec doing the vase. This was about the first 1/3rd of a 30 minute print. I know this isn't quite as controlled an example as a pure feed of 1000mm, but I needed to run the print anyway.

I captured this using the new Saleae Logic alpha software, version 2.3.13.

The capture is about 390 MB compressed (on disk). It's got both the digital and analog capture. I suppose I could have turned off the analog and saved some space.

Here's a link to the capture file: https://1drv.ms/u/s!ApuOkxTDmZEzgfznb3Mf2-ULLBN65XQ?e=cKZycH

And here's a timelapse: https://youtu.be/FcXaF9faE70

John

arhi

@JohnOCFII that singnal is uber ugly and need to be debounced

look at your capture here:

https://youtu.be/qrbtWI5o7Ik

question is if duet sees this many impulses but it's seen some of them for sure ... you need to add some debouncing circuit between duet and that encoder

alankilian

I agree that it's the slow rise-time of the signal causing multiple events to be detected.

I didn't realize you were going to get one full pulse every six seconds.

So, how to deal with it?

A good way to do it would be to add a "Schmitt trigger" inverter chip. Would wiring up one IC to power and your signal be too intimidating?

You could also try just doing a resistor-capacitor debounce circuit and it might work until your wheel stops at just EXACTLY the wrong place and then your print will fail.

Here's a beginner explanation on the math you can use to decide resistor and capacitor values:

https://www.allaboutcircuits.com/technical-articles/switch-bounce-how-to-deal-with-it/

Here's one from more of an expert:
http://www.ganssle.com/debouncing.htm
http://www.ganssle.com/debouncing-pt2.htm

It would also be possible to make some firmware changes (As described in Ganssle part 2. Probably listing 1 since we've got a very powerful processor.)

JohnOCFII

@alankilian said in Inconsistent results with optical encoder wheel filament sensor:

A good way to do it would be to add a "Schmitt trigger" inverter chip. Would wiring up one IC to power and your signal be too intimidating?

Fascinating!

Wiring up a solution would be a fun challenge. Finding the "recipe" of correct components, etc., will be the difficult part for me.

I'm curious what others trying to use an optical sensor are seeing? I don't think @fractalengineer ever saw the wild results I'm seeing. Do I just have a particularly bad batch of optical sensors?

Anyway, I'll read through those links in more detail when time permits.

Thanks to you both!

John

arhi

I am not sure ST alone will be a solution with a bounce so long. I think a comparator is something you'd wanna add here with ne555 circuit for proper debouncing ... on the other hand, instead of all that you could use some attiny44 or pic12f508 or something similar and make programmable debouncing circuit that one would embed in the sensor... in that case you could see what's the output of the laser/magnet sensor as they communicate with duet instead of just sending pulses

alankilian

@JohnOCFII I think adding a "sample frequency" parameter to the filament motion sensing code would be useful to the largest number of people.

I'll download the code and see if I can make any suggestions there.

JohnOCFII

@alankilian said in Inconsistent results with optical encoder wheel filament sensor:

@JohnOCFII I think adding a "sample frequency" parameter to the filament motion sensing code would be useful to the largest number of people.

I'll download the code and see if I can make any suggestions there.

As I mentioned WAY up thread, I think all we really need to know is "is the wheel turning?" If yes, assume everything is fine. If no, tell the Duet to pause. Only variable is how long does the state of "not turning" need to be present before pausing?

John

alankilian

@JohnOCFII Can you just set the "Over" amount to a huge value?

JohnOCFII

@alankilian said in Inconsistent results with optical encoder wheel filament sensor:

@JohnOCFII Can you just set the "Over" amount to a huge value?

Hmm... Perhaps.

Here's another odd data point. The two very first runs I did were within 200%. After than, I had days of testing where it would go from 30% to 3000%. But then, I started seeing those crazy high numbers, we'll above 10,000%. I do wonder if I'm chasing multiple issues.

alankilian

@JohnOCFII Is this the wheel that you have applies the sticky copper tape to and cut out windows?

The sharper the windows are, the better results you'll get.

You might also try taping copper tape to both the emitter and receiver and only have a narrow (1/16 inch) slot in the copper cover. That and a narrow (1/16 inch) opening windows in the encoder wheel might help.

JohnOCFII

@alankilian said in Inconsistent results with optical encoder wheel filament sensor:

@JohnOCFII Is this the wheel that you have applies the sticky copper tape to and cut out windows?

The sharper the windows are, the better results you'll get.

You might also try taping copper tape to both the emitter and receiver and only have a narrow (1/16 inch) slot in the copper cover. That and a narrow (1/16 inch) opening windows in the encoder wheel might help.

It is. It seemed that that test didn't change results, leading me to believe the regular printed wheel was doing an acceptable job of breaking the light beam. Perhaps I switch back to an encoder wheel without the copper tape. I could also move back to the wheel with more spokes (the one on the right in this photo).

arhi

@JohnOCFII you can try other wheels, problem is just how the edge is created by that endstop and how it is interpretted by the duet... since there's obviously no signal conditioning from endstop and since it looks like duet is not doing any software debounce easiest thing would be to create a debounce circuit on the input

JohnOCFII

@arhi said in Inconsistent results with optical encoder wheel filament sensor:

@JohnOCFII you can try other wheels, problem is just how the edge is created by that endstop and how it is interpretted by the duet... since there's obviously no signal conditioning from endstop and since it looks like duet is not doing any software debounce easiest thing would be to create a debounce circuit on the input

Yes, creating the debounce circuit seems like a very useful thing to do.

alankilian

@JohnOCFII What version are you running?

I can make a test build with a "Filter-time" parameter in the setup that ignores multiple edges for a minimum time before counting progress again.

I think you could set the time to 0.2 Seconds and you'd then get good results.

How fast were you extruding compared to the range of extrusion speeds you expect to use?

alankilian

@JohnOCFII Or I could make you a test build with a new filament sensor type that says: "Filament is present if I get an edge at least every <Q> millimeters of filament when extruding."

JohnOCFII

@alankilian said in Inconsistent results with optical encoder wheel filament sensor:

@JohnOCFII What version are you running?

Board: Duet 2 Ethernet (2Ethernet)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.1.1 (2020-05-19b2)

I can make a test build with a "Filter-time" parameter in the setup that ignores multiple edges for a minimum time before counting progress again.

I think you could set the time to 0.2 Seconds and you'd then get good results.

How fast were you extruding compared to the range of extrusion speeds you expect to use?

That capture was made at 15mm/sec. My standard profile goes up to 150mm/sec for infill.

JohnOCFII

@alankilian said in Inconsistent results with optical encoder wheel filament sensor:

@JohnOCFII Or I could make you a test build with a new filament sensor type that says: "Filament is present if I get an edge at least every <Q> millimeters of filament when extruding."

Hmm... Yes, that might be the most straightforward thing to try.

arhi

bouncing is 70-100ms .. that's long, but if that analog capture is any good the signal is actually pretty straightforward and just using ST as mentioned by @alankilian might solve 99% of the issues ... it will not solve them all, but if that analog part is true ST will get it to usable state.

74LVT14

power with 3v3, output will be 0/3v3, and input is 5V tolerable (actually survives up to 7V)

arhi

you are using connlcd3 or ENC_B and that's from what I see PC7 pin

from the datasheet

I think PC7 can be configured and Schmitt input directly in the firmware. I can't find here if we can configure pin as Schmitt input by addingt something to the name like we can for invert and pullup. IMHO any endstop input should be configured with Schmitt input, dunno if it is or not...

JohnOCFII

@arhi said in Inconsistent results with optical encoder wheel filament sensor:

you are using connlcd3 or ENC_B and that's from what I see PC7 pin

IMHO any endstop input should be configured with Schmitt input, dunno if it is or not...

I'm thinking I should try a different end stop connection to test. I can do that tomorrow afternoon.

In the meantime, I was winding down for bed with a little light reading: https://www.digikey.com/htmldatasheets/production/386707/0/0/1/74lvt14.html