• Tags
  • Documentation
  • Order
  • Register
  • Login
Duet3D Logo Duet3D
  • Tags
  • Documentation
  • Order
  • Register
  • Login

Inconsistent results with optical encoder wheel filament sensor

Scheduled Pinned Locked Moved Solved
Filament Monitor
9
168
11.0k
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • undefined
    JohnOCFII @arhi
    last edited by 27 Nov 2020, 21:13

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

    1 Reply Last reply Reply Quote 0
    • undefined
      alankilian @JohnOCFII
      last edited by 27 Nov 2020, 21:53

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

      SeemeCNC Rostock Max V3 converted to V3.2 with a Duet2 Ethernet Firmware 3.2 and SE300

      undefined 1 Reply Last reply 27 Nov 2020, 22:06 Reply Quote 0
      • undefined
        JohnOCFII @alankilian
        last edited by 27 Nov 2020, 22:06

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

        1 Reply Last reply Reply Quote 0
        • undefined
          alankilian @JohnOCFII
          last edited by 28 Nov 2020, 00:59

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

          SeemeCNC Rostock Max V3 converted to V3.2 with a Duet2 Ethernet Firmware 3.2 and SE300

          undefined 1 Reply Last reply 28 Nov 2020, 01:23 Reply Quote 0
          • undefined
            JohnOCFII @alankilian
            last edited by 28 Nov 2020, 01:23

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

            Screen Shot 2020-11-27 at 7.22.31 PM.png

            1 Reply Last reply Reply Quote 1
            • undefined
              JohnOCFII
              last edited by 28 Nov 2020, 01:24

              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
              
              1 Reply Last reply Reply Quote 3
              • undefined
                alankilian
                last edited by 28 Nov 2020, 15:32

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

                SeemeCNC Rostock Max V3 converted to V3.2 with a Duet2 Ethernet Firmware 3.2 and SE300

                1 Reply Last reply Reply Quote 0
                • undefined
                  alankilian
                  last edited by 28 Nov 2020, 15:36

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

                  SeemeCNC Rostock Max V3 converted to V3.2 with a Duet2 Ethernet Firmware 3.2 and SE300

                  undefined 1 Reply Last reply 28 Nov 2020, 20:44 Reply Quote 0
                  • undefined
                    JohnOCFII @alankilian
                    last edited by 28 Nov 2020, 20:44

                    @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

                    1 Reply Last reply Reply Quote 0
                    • undefined
                      JohnOCFII
                      last edited by 30 Nov 2020, 01:14

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

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

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

                      1 Reply Last reply Reply Quote 2
                      • undefined
                        JohnOCFII
                        last edited by 1 Dec 2020, 03:01

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

                        And 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.2mm
                        

                        So -- looking good, if I can figure out these false issues. Maybe my wheel slipped?

                        fractalengineerundefined 1 Reply Last reply 1 Dec 2020, 14:09 Reply Quote 1
                        • fractalengineerundefined
                          fractalengineer @JohnOCFII
                          last edited by 1 Dec 2020, 14:09

                          @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

                          Railcore II ZL

                          undefined 1 Reply Last reply 1 Dec 2020, 14:31 Reply Quote 0
                          • undefined
                            JohnOCFII @fractalengineer
                            last edited by 1 Dec 2020, 14:31

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

                            1 Reply Last reply Reply Quote 1
                            • Nuramoriundefined
                              Nuramori @JohnOCFII
                              last edited by 1 Dec 2020, 15:49

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

                              1 Reply Last reply Reply Quote 0
                              • undefined
                                JohnOCFII
                                last edited by JohnOCFII 12 Jan 2020, 16:28 1 Dec 2020, 16:28

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

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

                                IMG_2076.jpeg

                                1 Reply Last reply Reply Quote 2
                                • undefined
                                  alankilian
                                  last edited by 1 Dec 2020, 16:32

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

                                  SeemeCNC Rostock Max V3 converted to V3.2 with a Duet2 Ethernet Firmware 3.2 and SE300

                                  undefined 1 Reply Last reply 1 Dec 2020, 16:52 Reply Quote 1
                                  • undefined
                                    JohnOCFII @alankilian
                                    last edited by 1 Dec 2020, 16:52

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

                                    1 Reply Last reply Reply Quote 3
                                    • undefined
                                      JohnOCFII
                                      last edited by 26 Dec 2020, 20:27

                                      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

                                      fractalengineerundefined 1 Reply Last reply 27 Dec 2020, 16:19 Reply Quote 1
                                      • fractalengineerundefined
                                        fractalengineer @JohnOCFII
                                        last edited by fractalengineer 27 Dec 2020, 16:19

                                        @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

                                        Railcore II ZL

                                        undefined 1 Reply Last reply 27 Dec 2020, 17:40 Reply Quote 0
                                        • undefined
                                          JohnOCFII @fractalengineer
                                          last edited by 27 Dec 2020, 17:40

                                          @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

                                          1 Reply Last reply Reply Quote 1
                                          • First post
                                            Last post
                                          Unless otherwise noted, all forum content is licensed under CC-BY-SA