Pulse-generating Hall-E sensor / sparklab FTS
as a follow up to
I'd like to add a few thoughts since I really would like to get simple Hall-E Endstop type pulse-generating filament sensors supported in RRF.
As pointed out in the aforementioned topic the current implementation of a pulse-generating filament sensor turns out to require a rather huge amount of pulses to get a valid measurement.
This makes using Hall-E Endstop type sensors like the sparklab FTS quite difficult, since they generate only one pulse per revolution.
A rather simple yet efficient solution is implemented in Repetier firmware, which - in conjunction with the sparklab FTS - makes jam and filament-out detection work like a charm.
The implementation is outlined at http://the-sparklab.de/sparklab-feed-sensor/ and https://reprap.org/forum/read.php?249,528860,528985#msg-528985 and - in simple terms - works as follows:
(1) - count the extruder steps until the sensor pulse is registered
(2) - compare the counted steps with a reference value (obtained through calibration)
(2.1) - if the counted value is some percentage higher than that reference value, mark the extruder as jammed/out of filament and initiate pausing the print
(3) - reset the counter and start over at (1)
Main advantage of this implementation is the high resolution (roughly 1/EXTRUDER_STEPS) and - as a direct effect of this high resolution - the possibility to detect even small deviations from the reference extruder throughput, which makes it possible to pause the print way before the extruder is completely jammed.
Would it be possible to have this type implementation in RRF?
I would really appreciate it, and I am sure others would too.
I don't see why the existing support for pulse-generating filament sensors won't work with that type of sensor, if you set the E parameter to slightly less than the L parameter.
A fundamental problem with that type of filament monitor is that they can't distinguish between forward and backwards motion of the filament. So if the Hall sensor has just triggered and there is then a retraction that is long enough to un-trigger it followed by more forward motion, it will produce extra pulses. Whereas both types of Duet3d filament monitor sense the direction of rotation as well as the amount.
Thank you for your quick response, David.
The problem is that the existing implementation does not take extruder steps into account, but only extruded length, and in turn lacks precision to be useful with the described type of sensor.
If it would take extruder steps into account it could also distinguish extrude from retract motion (as the firmware should always know the commanded direction of the steppers), and therefore easily know that those extra pulses are caused by extrude/retract/extrude moves around the turning point of the 0/1 measurement curve. Those could be masked by some "minimum steps" parameter obtained through calibration or by a fixed percentage of the "regular steps per revolution".
Maybe I'm doing something wrong, but I yet have to see a proper configuration for this type of sensor working in RRF to a usable degree.
Will try your suggestion (parameter E < L) as soon as I have time to - will report back happily
Okay, testing went through.
Results are somewhat surprising, though.
Configuration was done using
M591 D0 P7 C3 S0 R50:150 E4.8 L5
Test results are
M591 D0 Pulse-type filament monitor on endstop input 3, disabled, sensitivity 5.00mm/pulse, allowed movement 50% to 150%, check every 4.8mm, current position 0.0, measured sensitivity 245.812mm/pulse, measured minimum 0%, maximum 88% over 491.6mm
which leave me somewhat puzzled ...
Any thoughts on those results?
Another, longer test print results in
M591 D0 Pulse-type filament monitor on endstop input 3, disabled, sensitivity 5.00mm/pulse, allowed movement 50% to 150%, check every 4.8mm, current position 0.0, measured sensitivity 2132.568mm/pulse, measured minimum 0%, maximum 87% over 4265.1mm
Could it be that the sink current of the Hall sensor isn't sufficient to pull the endstop pin close enough to 0V, so most of the pulses don't get registered by the Duet?
What happens if you increase the sample distance from 4.8mm to e.g. 50mm or 100mm? Obviously that isn't practical for real use, but it would help to pin down whether there is a firmware issue when using sensors with very low pulses-per-mm values.
I'll try to get a test print done following your suggestion within the next few days.
Does it matter which of your proposed values I chose for testing?
Does either value have some clear advantages in testing over the other?
Same test print as before, just with an E value of 100 in M591.
M591 D0 Pulse-type filament monitor on endstop input 3, disabled, sensitivity 5.00mm/pulse, allowed movement 50% to 150%, check every 100.0mm, current position 0.0, no calibration data
Can you use a multimeter to measure the voltage between the two outside pins of the endstop input connector you are using for the filament sensor, with the sensor wheel in positions that do and don't illuminate the endstop LED?
Did the measurement.
Had a "magic moment" when trying the first measurement, as I must have shorted E0 signal pin and one of the erase jumper pins during a print. Print came to stop, web interface was not reachable - I thought I fried the Duet. But it did respond to bossac, so in no time I was gladly running again
As far as I can tell you the sensor outputs signal HIGH and signal LOW each for half a revolution of the sensor wheels - if this is of any relevance.
HIGH signal level is a stable 3.11V, LOW signal level is stable at 0.81V.
.... just a gentle bump to this topic ...
@dc42 I don't want to bug you, but rather have you just not forget about this topic
Many thanks in advance, David!
It's on my list, but it's unlikely that I will have time to look into it this year. I have a huge amount of development work on my plate right now.
Thanks for the quick response!
I understand that there are plenty of other things to be done first - I just wanted to be sure you noticed the voltage levels measurement you requested.