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

    Here's my printable optical encoder wheel filament sensor!

    Scheduled Pinned Locked Moved
    Filament Monitor
    11
    37
    3.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.
    • jay_s_ukundefined
      jay_s_uk
      last edited by

      I think I better start printing some parts....

      Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

      1 Reply Last reply Reply Quote 1
      • A Former User?
        A Former User
        last edited by

        Might give it a go, re-designing the wheel to work with an outer rubber band, an o-ring or something as I'm not set up to print flexibles yet. Interesting approach!

        fractalengineerundefined 1 Reply Last reply Reply Quote 1
        • fractalengineerundefined
          fractalengineer @A Former User
          last edited by

          @bearer you should be able to do it easily; you will find the wheel assembles on a 6mm hex key 🙂

          Railcore II ZL

          1 Reply Last reply Reply Quote 0
          • RobMinkundefined
            RobMink
            last edited by

            What size bearing does it use?

            fractalengineerundefined 1 Reply Last reply Reply Quote 0
            • gnydickundefined
              gnydick
              last edited by gnydick

              I printed mine out a couple hours ago.

              I started the thread below, any ideas on configuration?

              https://forum.duet3d.com/topic/16920/testing-filament-sensor-on-rrf3

              1 Reply Last reply Reply Quote 0
              • fractalengineerundefined
                fractalengineer @RobMink
                last edited by

                @RobMink it's in the object description man

                @gnydick nice, I only got my Duet 3 so I can't help with your setup; I updated the guide to make it more flexible though if that helps

                Railcore II ZL

                RobMinkundefined 1 Reply Last reply Reply Quote 0
                • RobMinkundefined
                  RobMink @fractalengineer
                  last edited by

                  @fractalengineer Whoops, thanks, that was dumb.

                  1 Reply Last reply Reply Quote 0
                  • gnydickundefined
                    gnydick
                    last edited by

                    i got it working @fractalengineer. the only problem now is that it's sensing 50mm/pulse.

                    i'm watching it print and it's pulsing the led much more frequently than that. any ideas?

                    fractalengineerundefined 1 Reply Last reply Reply Quote 0
                    • fractalengineerundefined
                      fractalengineer @gnydick
                      last edited by

                      @gnydick answered in your dedicated post 🙂

                      Railcore II ZL

                      1 Reply Last reply Reply Quote 0
                      • T3P3Tonyundefined
                        T3P3Tony administrators
                        last edited by

                        @fractalengineer Great Job!

                        www.duet3d.com

                        1 Reply Last reply Reply Quote 1
                        • A Former User?
                          A Former User
                          last edited by

                          dc42 said in RRF 3.1.1 M572 breaks M591:

                          When you enable pressure advance, depending on the speed and acceleration you use, the extruder may reverse during the last part of a printing move. So it's important that the filament monitor senses the direction of motion and passes it to the Duet along with the amount of motion, as the Duet3D filament monitors do. If the filament monitor just sends motion pulses with no direction information, then the reverse motion will be misinterpreted as forward motion; so it will appear to RRF that there is too much filament motion. Is this what is happening?

                          interesting side note, still looking forward to trying this though, not yet wandered into PA stuff yet

                          fractalengineerundefined 1 Reply Last reply Reply Quote 1
                          • fractalengineerundefined
                            fractalengineer @A Former User
                            last edited by fractalengineer

                            @bearer Oh boi I sense we'll be needing incremental encoder support

                            Would be fairly simple to implement though; "just" adding a second sensor and 2nd row of slots from the hardware point...now to add it in the code..

                            alt text

                            I use a custom Flex3Drive with absolute shortest filament path so I haven't experimented with PA either

                            Railcore II ZL

                            1 Reply Last reply Reply Quote 1
                            • A Former User?
                              A Former User
                              last edited by

                              Had a buddy come build one today and seemed to come out with different holediameters and depths. The depth might be a non issue as I think the screws we had on hand were M3x8 not the reccomended M3x6.

                              But the circled holes came out too tight for M3, but nothing a drill+tap didn't sort. Something you have changed since i downloaded it? Or just tiertime that decides to things their way, for better or worse?
                              0dcd19e8-cdbc-4bde-a52d-af2c46ffad08-image.png

                              Still need to re-do the wheel to get some external flex, but looks good man - thanks for sharing!

                              fractalengineerundefined 1 Reply Last reply Reply Quote 1
                              • arhiundefined
                                arhi
                                last edited by

                                @bearer said in Here's my printable optical encoder wheel filament sensor!:

                                So it's important that the filament monitor senses the direction of motion and passes it to the Duet along with the amount of motion,

                                Can't we just use the "direction pin" on the extruder driver to determine direction ?!
                                It is not possible for filament to change direction without motor doing so, it might move less than we want but it will never move more than we want and in oposite direction

                                A Former User? T3P3Tonyundefined 2 Replies Last reply Reply Quote 0
                                • A Former User?
                                  A Former User @arhi
                                  last edited by

                                  @arhi did you see this? https://forum.duet3d.com/topic/17111/rrf-3-1-1-m572-breaks-m591/

                                  (missleading topic title i'd say, but maybe relevant)

                                  beyond that I'd defer to big cheese dc42 as it was his quote (i just stripped the @ to keep the noise down)

                                  1 Reply Last reply Reply Quote 0
                                  • T3P3Tonyundefined
                                    T3P3Tony administrators @arhi
                                    last edited by

                                    @arhi said in Here's my printable optical encoder wheel filament sensor!:

                                    Can't we just use the "direction pin" on the extruder driver to determine direction ?!

                                    We could use a quadrature encoder, or a pulse+direction arrangement. however in both cases these need more pins. for some applications that is no problem, in others pins are limited. ATTiny microprocessors are inexpensive which is why we went with the option of carrying out the initial processing on the filament monitor and then passing that processed information back to the Duet in a form that just uses 1 pin and works on an endstop input.

                                    It would be possible to either:

                                    1. Develop alternative code for the Duet main firmware that uses multiple pins to work with pulse+direction or quadrature.
                                    2. Develop alternative firmware for the Attiny or similar microprocessor that read your preferred sensor arrangement and converted it to the protocol the Duet uses.

                                    That said at this point I don't see us (the core Duet3D team) having time to do either.

                                    www.duet3d.com

                                    arhiundefined 2 Replies Last reply Reply Quote 0
                                    • T3P3Tonyundefined
                                      T3P3Tony administrators
                                      last edited by T3P3Tony

                                      And -rereading your original question I now see that you mean for the firmware to stick with reading the pulses from the sensor, but use the commanded direction of the extruder driver to determine the direction that those pulses relate to.

                                      That's a different question from the one one I answered above. there are certainly cases where with high enough pressure advance the extruder could be turning in the opposite direction from what would be expected looking at the gcode, but as you say the firmware knows that as its commanding the extruder to move in that direction....

                                      So the question is can a pulse extruder be configured to work more accurately if the firmware takes into account the current commanded direction of the extruder and then assumes that any pulses relate to movement in the direction commanded. Definitely one for @dc42 !

                                      www.duet3d.com

                                      arhiundefined 1 Reply Last reply Reply Quote 1
                                      • arhiundefined
                                        arhi @T3P3Tony
                                        last edited by

                                        ok, lemme reiterate

                                        There is no way a filament will move in contra direction of the motor, the only thing that can happen is filament not moving, filament moving less than required or filament moving as required. It is not possible for filament to move in contra direction or more than expected.

                                        So I do understand that current implementation does not know how to handle this and that firmware look at pulses as "forward only" (weird decision but ok) and that there is a non-working duet filament sensor that has a small MCU and can send additional data and and and.... but, the motor is rotated by the firmware. The point that there are few processes influencing motor behavior (acceleration, jerk, pressure advance, dynamic acceleration...) is irrelevant it just means that software needs to be improved not that there is a need to add direction data as there is direction data in the firmware already, it is just a question if you are using it or not.

                                        I, of course, understand the limited nature of resources and I agree that there are more important features that should be finished/polished and / or implemented so I can agree that writing a bit of code on the attiny or pic12f or another puny few cent few pin mcu can solve the issue faster, allowing those "resources" to focus on more important features. I'm not familiarized with the duet codebase (I did manage to compile it and modify it a bit but am still missing the big picture) to be able to quickly figure out how this works now and what needs to be changed to make it work properly

                                        o_lampeundefined 1 Reply Last reply Reply Quote 0
                                        • arhiundefined
                                          arhi @T3P3Tony
                                          last edited by

                                          @T3P3Tony said in Here's my printable optical encoder wheel filament sensor!:

                                          converted it to the protocol the Duet uses

                                          I assume the "the protocol the Duet uses" can be deducted from the attiny firmware for the duet laser sensor?

                                          1 Reply Last reply Reply Quote 0
                                          • arhiundefined
                                            arhi @T3P3Tony
                                            last edited by

                                            @T3P3Tony said in Here's my printable optical encoder wheel filament sensor!:

                                            but as you say the firmware knows that as its commanding the extruder to move in that direction....

                                            Yes, there's no "external system" that measures the pressure and reverses the motor direction without firmware knowing about it. The motor is directly controlled by the firmware hence firmware knows the direction motor is turning.

                                            So the question is can a pulse extruder be configured to work more accurately if the firmware takes into account the current commanded direction of the extruder and then assumes that any pulses relate to movement in the direction commanded.

                                            As I said it's virtually impossible for direction of filament to be different than direction of the motor. Also, I think I did ask when I first looked at the "e_stop" input if the firmware uses the motor direction to properly handle retractions as there is no direction pin, and I think dc42 replied that it does or there was no reply at all so I assumed it does, I don't remember and I can't find that post any more.

                                            I always assumed that direction is fetched from the motor direction, and before PA it does look ok, seems that retractions are handled properly (even a rather long retraction), but looking at mentioned thread looks like PA messes it up, so it's possible that for retractions the direction is considered but for PA direction is not considered and just need to be "fixed" (the question is how quick that fix is, I don't feel comfortable assuming anything is easy/hard to fix till I get myself familiar with the code).... now, I do have some gaps in workflow these days that I can use for some development... doing a quick "read encoder, shoot data over spi/i2c/usart/1wire.." should be super simple if the protocol is described somewhere or example (existing sensor) is not too cryptic 😄

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