filament sensor def. not very usable with PA
-
Hi,
Well according to that dump the device is disabled. Is that true?
Frederick
-
@fcwilt said in filament sensor def. not very usable with PA:
Well according to that dump the device is disabled. Is that true?
yes, hence it did not pause the print when the read data went over 110% or below 90%, otherwise it behaves just like it's enabled
-
@fcwilt this is not new, we already discussed it in different thread as the mechanism does not take filament direction into account. During retractions it just ignores input. PA speed/slow down the extruder (and reverse it in some cases) and while I never notice any reverse movement on my setup looks like the slowdown is also not followed up with the filament tracking module
-
@dc42 sorry I know you are now overloaded with new hw but if you can help out a bit maybe we can solve this
I'm looking at the MagneticFilamentMonitor and it's sending a data word with 10bit "filament position". If I convert output of the encoder to a compatible output and send "filament position" that I track locally so increase in one direction, decrease in other (overflow?!) will this work with PA and DAA ? Is the only problem direction or there are other issues with PA/DAA not handling pulse inputs?
I see that LaserFilamentMonitor is sending 11bit position with 100count/mm configured. Same question as magnetic one?
It would be super simple to create a small board that takes AB from encoder and generates these signals for the RRF. I can go with ATtiny44A to be compatible with existing boards, should be quick and simple project, but makes no sense in doing it if it will not work. @omni has duet's laser sensor and he's getting similar span of min/max as I am with it with PA+DAA on so that's why I'm bugging you with questions
-
looks like DDA is not a problem, filament monitor code fetches
DDARing::GetAccumulatedExtrusion
so it's just PA that's not in this chain -
@arhi said in filament sensor def. not very usable with PA:
looks like DDA is not a problem, filament monitor code fetches
DDARing::GetAccumulatedExtrusion
so it's just PA that's not in this chainGetAccumulatedExtrusion looks at the actual number of microsteps taken, so it does take PA into account.
-
@dc42 said in filament sensor def. not very usable with PA:
GetAccumulatedExtrusion looks at the actual number of microsteps taken, so it does take PA into account.
direction too? it reduce the number if PA reverses the direction of the extruder?
-
@arhi said in filament sensor def. not very usable with PA:
@dc42 said in filament sensor def. not very usable with PA:
GetAccumulatedExtrusion looks at the actual number of microsteps taken, so it does take PA into account.
direction too? it reduce the number if PA reverses the direction of the extruder?
Yes. However, there is a short delay between the filament monitor starting to take a reading and then sending it to the Duet, so PA does reduce the accuracy of the correlation a little.
-
I found a bug in my design that allowed filament to slip, that's why I had those "zero" readings... now with fixed design it's much better:
Pulse-type filament monitor on pin e0stop, disabled, sensitivity 0.119mm/pulse, allowed movement 90% to 110%, check every 3.0mm, measured sensitivity 0.124mm/pulse, measured minimum 79%, maximum 131% over 9440.3mm
this looks usable. If a get a clog/block the min will quickly drop below 50% and the print will pause.. so I just need to add a bigger span than original 90-110 and it should work.
Looking at the two "smart" sensors too, I think I'll make one attiny adapter for the encoder type to behave like laser or magnetic one or you think it is better to add a new type of sensor (smart encoder for e.g.) ?
-
def. works.. finished few prints with enabled sensor with PA working ..
Pulse-type filament monitor on pin e0stop, enabled, sensitivity 0.124mm/pulse, allowed movement 50% to 200%, check every 3.0mm, measured sensitivity 0.124mm/pulse, measured minimum 74%, maximum 117% over 3091.4mm
so if PA is not reversing everything is ok. the 0% minimum was a hardware failure (fixed :D)
so def makes sense to add a converter to convert quadrature output to the position data to send like those smart sensors