Inconsistent results with optical encoder wheel filament sensor

JohnOCFII

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

@JohnOCFII I'd still do that test without hotend

remove hotend so you have only extrder drive and sensor

disable "heating" in the g-code

allow "cold extrusion" in the firmware

do a print of a simple long extrusion g-code

I disconnected the extruder from the hot-end and set up some GCode to run so I could measure filament. I started with a test at 100mm, but M591 D0 is showing no data. Curious if not having the printer homed is causing the data collection to be ignored. Maybe I missed something.

Here's my GCode:

; Test Extrusion 
;
M302 P1                                            ; Allow cold extrusion
G92 X0Y0Z0                                         ; duet now assume we are homed
M82                                                ; extruder absolute position
G92 E0                                             ; reset extruder to 0
M591 D0 P7 C"connlcd.encb" S0 R50:1500 L1.2 E5 A1  ; config filament sensor
; G1 E1000 F120                                     ; extrude 1000mm at 2mm/sec, so will be extruding around 8 minutes
G1 E100 F120                                       ; extrude 100mm at 2mm/sec, so will be extruding around 1.2 minutes
M591 D0                                            ; query filament sensor

Time for some yard work! Got to go rake leaves.

arhi

@JohnOCFII you have to save that script as a file and make RRF print that file, you can't just execute the script as in that case filament monitor is disabled

JohnOCFII

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

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

@JohnOCFII I'd still do that test without hotend

remove hotend so you have only extrder drive and sensor

disable "heating" in the g-code

allow "cold extrusion" in the firmware

do a print of a simple long extrusion g-code

I disconnected the extruder from the hot-end and set up some GCode to run so I could measure filament. I started with a test at 100mm, but M591 D0 is showing no data. Curious if not having the printer homed is causing the data collection to be ignored. Maybe I missed something.

Here's my GCode:
; Test Extrusion 
;
M302 P1                                            ; Allow cold extrusion
G92 X0Y0Z0                                         ; duet now assume we are homed
M82                                                ; extruder absolute position
G92 E0                                             ; reset extruder to 0
M591 D0 P7 C"connlcd.encb" S0 R50:1500 L1.2 E5 A1  ; config filament sensor
; G1 E1000 F120                                     ; extrude 1000mm at 2mm/sec, so will be extruding around 8 minutes
G1 E100 F120                                       ; extrude 100mm at 2mm/sec, so will be extruding around 1.2 minutes
M591 D0                                            ; query filament sensor

Yes, I saved it as ColdExtrusioTest.g and "printed" it same as I would any other file.
There must be something else I'm missing. I'll have to think about it.

10/31/2020, 3:10:14 PM	M591 D0
Pulse-type filament monitor on pin (connlcd.encb,connlcd.3), disabled, sensitivity 1.200mm/pulse, allowed movement 50% to 1500%, check every 5.0mm, no calibration data
10/31/2020, 3:07:37 PM	Finished printing file 0:/gcodes/Calibration/ColdExtrusionTest.g, print time was 0h 0m
10/31/2020, 3:06:47 PM	M32 "0:/gcodes/Calibration/ColdExtrusionTest.g"
File 0:/gcodes/Calibration/ColdExtrusionTest.g selected for printing
Pulse-type filament monitor on pin (connlcd.encb,connlcd.3), disabled, sensitivity 1.200mm/pulse, allowed movement 50% to 1500%, check every 5.0mm, no data received
10/31/2020, 3:05:50 PM	M591 D0
Pulse-type filament monitor on pin (connlcd.encb,connlcd.3), disabled, sensitivity 1.200mm/pulse, allowed movement 50% to 1500%, check every 5.0mm, no calibration data
10/31/2020, 3:03:59 PM	Finished printing file 0:/gcodes/Calibration/ColdExtrusionTest.g, print time was 0h 0m
10/31/2020, 3:03:09 PM	M32 "0:/gcodes/Calibration/ColdExtrusionTest.g"
File 0:/gcodes/Calibration/ColdExtrusionTest.g selected for printing
Pulse-type filament monitor on pin (connlcd.encb,connlcd.3), disabled, sensitivity 1.200mm/pulse, allowed movement 50% to 1500%, check every 5.0mm, no data received

JohnOCFII

I homed the printer, then ran this file while it was still homed - no change in output.

arhi

@JohnOCFII and it passed those 100mm trough extruder and sensor and the wheel were rotating? that's rotating rather slow right, can you check the impulses with a multimeter maybe? analog one would work great?

JohnOCFII

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

@JohnOCFII and it passed those 100mm trough extruder and sensor and the wheel were rotating? that's rotating rather slow right, can you check the impulses with a multimeter maybe? analog one would work great?

Yes. Also, the optical sensor board has an LED that was blinking at regular intervals.

Depending on the weather, I'm supposed to fly with a student tomorrow (weekend flight instructor). If not, I'll try this tomorrow.

Saleae LA should arrive Monday or Tuesday.

arhi

@JohnOCFII I'm more interested to see the levels you see on the duet board so measuring voltage between the signal pin (connlcd.encb) and gnd using voltmeter while slowly moving the encoder so to see what you have there for 0 (when that signal led is off) and what you have there for 1 (when that signal led is on) .. as I don't see a reason why would RRF detect these impulses for me and not for you unless there's something fishy with the voltage levels there ... how the cable is crymped etc etc..

JohnOCFII

So I've re-assembled the hot-end/extruder, and added some wiring extensions to connect to the Logic Analyzer. I was seeing incredibly strange outputs -- like this:

Pulse-type filament monitor on pin (connlcd.encb,connlcd.3), disabled, sensitivity 1.200mm/pulse, allowed movement 50% to 1500%, check every 5.0mm, measured sensitivity 0.000mm/pulse, measured minimum 0%, maximum 1052141% over 46.6mm

So I pulled the optical sensor off the case, and confirmed the encoder wheel is still moving as expected.

So while the print was running, I started using a flat print to interrupt the sensor on a sort of regular basis, and started to get "more normal" results again. And by normal -- I mean normal for my recent results...

Pulse-type filament monitor on pin (connlcd.encb,connlcd.3), disabled, sensitivity 1.200mm/pulse, allowed movement 30% to 1500%, check every 10.0mm, measured sensitivity 0.386mm/pulse, measured minimum 0%, maximum 6059% over 372.6mm

I'm starting to wonder about wiring issues, or something else more related to the DUET. One thing you suggested was to try a different port, as this CONNLCD might be treated differently than the other ports.

(I've got more free time than expected today -- so will keep plugging at things today)

alankilian

@JohnOCFII Hey John, I've been trying to keep up with this thread and I have a question you may have answered already:

How is the receiver part of your optical interruptor connected to your Duet?
Do you have a pull-up or pull-down resistor on the signal that goes to the Duet?

If you got the digital-only Saleae you won't be able to see if there's a level problem due to a missing or too-large pull-resistor.

JohnOCFII

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

@JohnOCFII Hey John, I've been trying to keep up with this thread and I have a question you may have answered already:

How is the receiver part of your optical interruptor connected to your Duet?
Do you have a pull-up or pull-down resistor on the signal that goes to the Duet?

If you got the digital-only Saleae you won't be able to see if there's a level problem due to a missing or too-large pull-resistor.

The optical sensor is connected to pins 1,2,3 on the CONN_LCD connector. I'd previously used this connection for a basic physical endstop-type filament sensor. I've tried the optical sensor with, and without the pull-up as indicated by including the "^" in the configuration string, but didn't see a noticeable change in behavior.

Screen Shot 2020-11-01 at 2.55.28 PM.png

https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview#Section_Pin_names_for_Duet_2_WiFi_Ethernet

I'm getting the Logic 8, which appears to have analog inputs. https://www.saleae.com

Also - right now I've hooked up a BitScope Micro, which I ordered a few years ago, but never used. When I hook it up to GND and the signal pin, I see a bit of noise, but no change when I interrupt the optical sensor beam. On the sensor itself breaking the beam turns off an LED. Perhaps no data flows to the Duet when a print isn't running?

I've never used a Logic Analyzer or O-Scope before, so this is all new to me.

alankilian

Both the LED-side and the receive-side of the interrupter need to be hooked up "in the right way"

Can you post which connection on the Duet is connected to which connection on the optical interrupter?
Also, can you post the name/number of the interrupter or a data sheet?

It's pretty easy to get one side or the other backwards. AND it's pretty easy to fix!

The new Logic 8 will be great.
I have the very very old digital only Logic 8 as well as an old Logic 16 Pro that does both analog and Digital, so I can certainly help you setup and look at the signal when you get that.

JohnOCFII

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

Can you post which connection on the Duet is connected to which connection on the optical interrupter?

Duet Pin 1 (+3.3) <---> Pin labeled V on sensor
Duet Pin 2 (GND) <--> Pin labeled G on sensor
Duet Pin 3 (STOP 10 - ENC_B) <--> Pin labeled S on sensor

Also, can you post the name/number of the interrupter or a data sheet?

The markings on the unit are 70T2. These are sensors I bought: https://www.ebay.com/itm/4-Pieces-Optical-Endstop-Limit-Switch-RAMPS-1-4-Board-3D-Printer-3Pin-Cable-A27/254260205504

It's pretty easy to get one side or the other backwards. AND it's pretty easy to fix!

The new Logic 8 will be great.
I have the very very old digital only Logic 8 as well as an old Logic 16 Pro that does both analog and Digital, so I can certainly help you setup and look at the signal when you get that.

Excellent -- and thank you!

alankilian

Hmmmmm.

How do you know if that's supposed to have 5 Volts or 3.3 Volts?

And if it is supposed to pull the signal high or low?
And if you need to add an extra resistor or not?

(I'll do some googling and see if I can answer my own questions.)

JohnOCFII

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

Hmmmmm.

How do you know if that's supposed to have 5 Volts or 3.3 Volts?

And if it is supposed to pull the signal high or low?
And if you need to add an extra resistor or not?

(I'll do some googling and see if I can answer my own questions.)

I don't. Just going off the recommendations of the guy who designed this filament sensor project: https://www.thingiverse.com/thing:4445504

Good thing I consider this just a learning experience. Because even at the end of the day, Best case it seems I'll be stuck with a 20-40mm "window" of filament passage before it'll trigger an issue. Might just go back to the switch for "filament out". It won't catch jams, but it'll reliably catch the case of filament out.

But first, I'd like to figure out why my results are so much worse than what @fractalengineer sees.

JohnOCFII

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

@JohnOCFII I'm more interested to see the levels you see on the duet board so measuring voltage between the signal pin (connlcd.encb) and gnd using voltmeter while slowly moving the encoder so to see what you have there for 0 (when that signal led is off) and what you have there for 1 (when that signal led is on) .. as I don't see a reason why would RRF detect these impulses for me and not for you unless there's something fishy with the voltage levels there ... how the cable is crymped etc etc..

Voltage settles out at 3.2 when I pass a solid object between the optical sensor "arms." When nothing is between the arms, the voltage is not a clean, solid 0.0 but hovers in the 0.300-0.400 range.

And also remember, this optical sensor board has an LED that is lit when there is no object breaking the beam, which turns off when the beam is broken.

It seems like the sensor is sending what amounts to "on" or "off" but the Duet isn't dealing with it properly. This is firmware 3.1.1 on a Duet 2 Ethernet board.

arhi

@JohnOCFII dunno I don't understand why firmware is not reading those pulses if they are around 0.2V and 3.2V they should be read properly on the input pin. Maybe @dc42 can shed some light on what might be happening, and how to test/debug. I'm clueless at this point

alankilian

@JohnOCFII Those are perfect values for this sensor and the Duet should have no problems detecting them as pulses.

I'll take a look deeper and we can see what the waveforms look like when you have the logic analyzer.

JohnOCFII

The Logic Analyzer arrived! Here's some data.

Screen Shot 2020-11-02 at 3.11.26 PM.png

arhi

@JohnOCFII that looks ok, signals are more/less clean ... should work 1/1

if you grab a longer piece, do you see that during constant extrusion move signals are evenly spaced as one would expect?

levels seem ok, ~3V and ~0V, timing seem ok .. using the "extruder endstop" input is the only other idea I have.. don't see why would that make any difference but I use the encoder endstop input and it works for me ... now I still have some variance but I never reproduced this with many impulses and still "no data" on the sensor reading... @dc42 wrote that part of the code iirc and he should be able to say what might be wrong, the code for the pulse sensor itself, I looked month or two ago (and for laser sensor too) and I did not find anything weird there but..

alankilian

That waveform looks OK.

Can you try commanding something like a 120mm extrusion slowly and then turn the wheel so that you have 100 notches pass and see if you get near the right amount of detected extrusion?

While capturing using the Saleae so we can also see the signal?

If you could then post the Saleae capture file anyone can download the Saleae software and take a look at it with you.