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

    Connecting and reading a pulse generating encoder

    Scheduled Pinned Locked Moved
    Firmware wishlist
    7
    35
    2.9k
    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.
    • pfnundefined
      pfn @oc_geek
      last edited by

      @oc_geek 500Hz rate? why is it so high? It should only trigger once per unit distance (which shouldn't be much lower than about 1mm per pulse...)

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

        @oc_geek yeah the TCRT5000 is a reflective optical switch or potentially a distance sensor depending on how it was used. is there a rotating element with slots in?

        www.duet3d.com

        oc_geekundefined 1 Reply Last reply Reply Quote 0
        • o_lampeundefined
          o_lampe
          last edited by

          @oc_geek you could use a frequency divider to reduce pulse count/second . They will reduce by 2,4,8 a.s.f. depending on their setting.
          A small ATtiny or PIC processor can do the trick, too.
          Then, when Duet gets triggered , add 2,4,8 pulses to the equation instead of 1.

          In any case make sure, the pulse counting macro is as short as possible. Otherwise you might miss incoming pulses.
          Write another macro to read the global pulsecounter and go on from there.

          1 Reply Last reply Reply Quote 1
          • oc_geekundefined
            oc_geek @T3P3Tony
            last edited by

            @t3p3tony as far as i could see from the Discord ERCF 1.1 discussion it reads a Bondtech gear which rotates with filament
            Filament running at 20 mm / sec so that's where the 200 - 500 Hz comes from (i'm just reporting what i was told)

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

              @oc_geek so whats the pulses/mm of this sensing arrangement. There is existing code for using a pulse based filament monitor
              https://duet3d.dozuki.com/Wiki/M591#Section_M591_RepRapFirmware_Num_3

              Type 7

              www.duet3d.com

              oc_geekundefined 1 Reply Last reply Reply Quote 0
              • dc42undefined
                dc42 administrators @oc_geek
                last edited by

                @oc_geek what's the purpose of measuring the counts? Is it to detect if the mechanism is jammed?

                With a simple pulse generating encoder, you will not be able to determine in which direction the mechanism is moving. Might that be a problem?

                Duet WiFi hardware designer and firmware engineer
                Please do not ask me for Duet support via PM or email, use the forum
                http://www.escher3d.com, https://miscsolutions.wordpress.com

                oc_geekundefined 1 Reply Last reply Reply Quote 0
                • oc_geekundefined
                  oc_geek @dc42
                  last edited by oc_geek

                  @dc42 i understood they use it to determine the filament position (real travel distance) when loading a specific filament in the MMU down to the tool head
                  With the encoder they say it is possible to meisure with a precision of 1 mm
                  Direction is derived by other means and hold by other variables

                  All that said would it be possible to use triggers to follow it up @ e.g. 250 Hz ?

                  pfnundefined 1 Reply Last reply Reply Quote 0
                  • oc_geekundefined
                    oc_geek @T3P3Tony
                    last edited by

                    @t3p3tony i saw that but it wont be possible to inquire the position nor to reset it (unless i'm reading it wrong)

                    1 Reply Last reply Reply Quote 0
                    • Dan1990undefined
                      Dan1990
                      last edited by Dan1990

                      The Klipper firmware seems to work fine with the ERCF, so perhaps will be valuable to check their code? It wIll gives more understanding towards what oc'geek and many others trying to get. (The voron - duet community is big )

                      That is the link to the PCB for ERCF:

                      https://github.com/Tircown/ERCF-easy-brd

                      Link to the project:

                      https://github.com/EtteGit/EnragedRabbitProject

                      oc_geekundefined 1 Reply Last reply Reply Quote 0
                      • oc_geekundefined
                        oc_geek @Dan1990
                        last edited by

                        @dan1990 rightly said

                        in particular the part responsible for the Pulse Generating encoder is a Klipper module written in python

                        1 Reply Last reply Reply Quote 0
                        • pfnundefined
                          pfn @oc_geek
                          last edited by pfn

                          @oc_geek why would you need 250hz? 1 pulse per mm, feed rates are usually like 10mm/s at most... (browsing that code, it looks like it's set at 1.5mm/pulse and something like 100mm/s feed rate, it's probably reasonable enough?)

                          oc_geekundefined 1 Reply Last reply Reply Quote 0
                          • oc_geekundefined
                            oc_geek @pfn
                            last edited by oc_geek

                            @pfn as i wrote this came from the Author of the unit itself... it's not that i need something..

                            834f357d-1bea-404a-89f1-28ae18572708-image.png

                            The sensor is used ONLY when loading / unloading the chosen (between nine) filament to the tool to make sure it arrives where intended and does not jam the unit and so on...
                            I think they do that faster than a print feed rate to reduce the overall print time...(e.g. 1000 filament changes in a print would matter..)

                            that said i did not got any data point from the Duet team on which rates (Hz) are reachable using a trigger... or any other offered solution...

                            pfnundefined 1 Reply Last reply Reply Quote 0
                            • pfnundefined
                              pfn @oc_geek
                              last edited by

                              @oc_geek it may be too fast to push 250 triggers a second (even though it should be brief). 250 triggers a second would be something like 375mm/s feed rate, is the ercf really capable of that? In any case, if RRF isn't capable of that speed of triggering, you can solve it with several means.

                              1. Decrease the pulse resolution, i.e. remix the encoder wheel so that pulses are every 3mm rather than 1.5, decrease resolution until it is manageable, if it is an issue.

                              2. Even easier is to simply lower the feed rate , 100mm/s is already really fast, adjust until pulse counts are manageable.

                              I'd prefer to do 1. Anyhow, if you already have a smart filament sensor handy, it wouldn't be very hard to test to see what kind of rate you can achieve, yank filament through and see how many triggers you can capture.

                              As for the duet team not giving a number, I'm not sure anyone even tests this scenario...

                              oc_geekundefined 1 Reply Last reply Reply Quote 0
                              • oc_geekundefined
                                oc_geek @pfn
                                last edited by

                                @pfn yeah will have to check as you say

                                Option 1 is not possible as the "encoder wheel" is actually a metal Bondtech gear (as i wrote before below)

                                Option 2 seems to be the only practical possibility

                                Also the challenge will be to port the Klipper python module into RRF Marcos...

                                pfnundefined 3 Replies Last reply Reply Quote 0
                                • pfnundefined
                                  pfn @oc_geek
                                  last edited by

                                  @oc_geek ah, that's fascinating, so roughly 1.4mm per pulse, and it seems Ette runs about 170mm/s for the high speed part of the load -- the actual pulse rate that needs to be supported is about 125 per second (if you want to use what Ette runs), 75 pulses per second otherwise (100mm/s default).

                                  Anyway, yeah, test it out with a rotary encoder and see what sort of numbers can be achieved.

                                  1 Reply Last reply Reply Quote 0
                                  • pfnundefined
                                    pfn @oc_geek
                                    last edited by pfn

                                    @oc_geek so, I happened to be building a filament sensor anyway 😁 -- you're in luck and I'm able to give some general data (for duet2wifi)

                                    This sensor design generates 1 pulse for every 0.98mm of filament travel, calculated by 7.5mm filament gear diameter driving a 24 spoke encoder wheel. (pi*7.5/24)

                                    https://cdn.discordapp.com/attachments/711873626080804917/893167909621334076/unknown.png
                                    https://cdn.discordapp.com/attachments/711873626080804917/893288891535228948/20210930_171026.jpg

                                    I'm running this on a spare duet2wifi testbed board. The printer I intend to use with the ERCF is using a duet3 6mbhc, but isn't available for testing. Interestingly, my filament sensor will become obsolete as I will move the function of filament sensing to the ERCF's optical pickup; luckily I have another printer I can put the filament sensor on 😄

                                    I wrote the following macros:

                                    /macros/setup sensor

                                    M950 J1 C"e0stop"
                                    M581 P1 T2 R0 S1
                                    
                                    if !exists(global.pulse_count)
                                      set global pulse_count = 0
                                      
                                    if !exists(global.wall_time)
                                      global wall_time = 0
                                      
                                    if !exists(global.last_time)
                                      global last_time = 0
                                    
                                    set global.pulse_count = 0
                                    set global.wall_time = 0
                                    set global.last_time = 0
                                    

                                    /macros/echo data:

                                    echo {global.pulse_count ^ " " ^  global.last_time - global.wall_time}
                                    set global.pulse_count = 0
                                    set global.wall_time = 0
                                    set global.last_time = 0
                                    

                                    /sys/trigger2.g

                                    if global.pulse_count = 0
                                      set global.wall_time = {state.upTime + state.msUpTime / 1000}
                                    
                                    set global.last_time = {state.upTime + state.msUpTime / 1000}
                                    set global.pulse_count = {global.pulse_count + 1}
                                    

                                    With this setup, I was able to process about 70-100 pulses per second (just averaging). Most of the trials were about 80 pulses per second. Testing consisted of pulling a 500mm length of filament through the sensor at varying durations (from 1-10 seconds). At about 6 seconds, the full pulse count could be achieved. Anything under that aliased to between 70 and 100 pulses per second.

                                    Duet3 may perform more adequately. But if we were putting an ERCF on a duet2, I'd probably go with a 90mm/s loading feedrate.

                                    Aliasing of the pulses may be an artifact of the optical sensor (endstop) I'm using, I'm not sure what its max trigger rate could be. Lots of variables; the sensor in the ERCF could have better performance.

                                    pfnundefined 1 Reply Last reply Reply Quote 1
                                    • pfnundefined
                                      pfn @pfn
                                      last edited by

                                      For a followup, I wrote a simple arduino sketch to count pulses. It was pretty easy to count the full 500mm (~500 pulses) in a second without skipping pulses. My optical endstop isn't the bottleneck here. It'd be nice to try this on my duet3 to see if there's a performance difference.

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

                                        @pfn have you tried using M591 and monitor type type 7?
                                        https://duet3d.dozuki.com/Wiki/M591

                                        www.duet3d.com

                                        pfnundefined 1 Reply Last reply Reply Quote 0
                                        • pfnundefined
                                          pfn @T3P3Tony
                                          last edited by pfn

                                          Hi @t3p3tony I do use M591 for actual filament runout sensing during a print. The purpose of my testing here is to understand how to do filament sensing outside of a print-move context.

                                          The context of what's happening here is that the ERCF is an MMU. As part of what it does, it needs to know that filament is being loaded and unloaded properly. To support this, it has a pulse-generating sensor that it reads while loading and unloading to make sure the counts generally add up.

                                          As I understand how M591 filament sensors work, it's only there to pause the print in case of any fault, it isn't really possible to query the state. Especially not in a way that would work to identify un/load success from a drive that isn't the extruder.

                                          My general plan for how this would work like this:

                                          M591 C"<filament-sensor-pin>" ...; filament sensing during a print
                                          ; print print print ...
                                          ; filament-change
                                          ; get ready for unload
                                          M950 Jx C"<filament-sensor-pin>"
                                          M581 Px Ty ...
                                          ; run unload operations
                                          ; extruder unload
                                          ; read counts accumulated as a result of M581 triggers, validate, reset counts
                                          ; MMU retraction
                                          ; read counts, validate, reset
                                          ; run load operations
                                          ; MMU load
                                          ; read counts, validate, reset
                                          ; extruder load
                                          ; read counts, validate, reset
                                          ; reset filament sensor state to M591 mode
                                          M581 T2 P-1
                                          M591 C"<filament-sensor-pin>"
                                          ; do whatever purging
                                          ; resume printing

                                          T3P3Tonyundefined 1 Reply Last reply Reply Quote 1
                                          • pfnundefined
                                            pfn @oc_geek
                                            last edited by pfn

                                            @oc_geek after reading the ercf manual, and thinking about how it works, it really isn't necessary to fully receive the max pulse rate possible.

                                            For the ERCF operation, there's only 2 things we need to know: was the system able to push filament to the extruder, and was the extruder able to load the filament.

                                            Any pulse count over some fixed number (say 5, or 20) is enough to indicate that the first stage and second stage worked OK.

                                            Additionally, on top of that, RRF can do stall-detection loading on both stages. There isn't a need for an accurate measure of distance to the hot end and nozzle. Once the 2nd stall detect operation happens, a quick pulse count can be taken to ensure that filament moved into the extruder. A short 3mm purge can be run to make sure pulse count is >1 (not sure how this will affect a wipe/purge tower).

                                            After all the loading is completed, the optical sensor can be flipped back to regular M591 mode to do clog/runout/endless spool mode.

                                            Endless spool mode could be supported by doing a flipover in filament-error.g

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