Connecting and reading a pulse generating encoder
-
@pfn have you tried using M591 and monitor type type 7?
https://duet3d.dozuki.com/Wiki/M591 -
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 -
@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
-
@pfn that makes sense.
So in summary you send G1 Ennn Fxxx where nnn is the length of the filament feed tube as part of a macro (tool change macro or filament change macro) and xxx is as high a speed as you can do this which is a lot higher than the normal printing speed. And the issue is that M591 does not work for normal extruder moves that are not filament moves.
I have moved this to the firmware wishlist to further the discussion about how we might be able to support using filament monitors for no printing extrusion moves such as this.
-
@t3p3tony hmm, adding firmware support for this would be great.
I have some initial ideas around how to better support an mmu use case like this:
-
Allow filament monitoring in several different stages, during a print, outside of a print, all the time, count-only (the current behavior of S0, but with added options of all the time, or non print), off. This can be configured by extending the S parameter with more options.
-
Expose more information in the object model about the filament monitor state so that various information about the tracked filament can be extracted: distance sensed, etc
Thanks!
-
-
@pfn great work !
thanks for all what you did and are doing -
@t3p3tony
thanks guys !
would be great to see something like that supported in the fw -
@t3p3tony said in Connecting and reading a pulse generating encoder:
I have moved this to the firmware wishlist to further the discussion about how we might be able to support using filament monitors for no printing extrusion moves such as this.
Hi,
Is there any ETA for this feature being implemented any time soon ?
thanks -
@oc_geek not right now - we have quite a few feature requests to consider.
-
Just chiming in to say I am also interested in this feature and would greatly appreciate the flexibility.
