Posible bug detected in filament monitoring

[T3P3Tony]

@Tinchus yes I was asking about the calibration pulses/mm.

So to confirm, looking at that. If you set it to a lower value, it calibrated to that lower value (or a bit lower) and that is repeatable. Would be interesting to see if it follows you "up" if you set higher values.

The measured min/max increasing over a print is to be expected, up untill the true minimum and maximum of the system is reached.

[Tinchus]

@T3P3Tony To answer your question, this data is of right now:

M591 D0
Pulse-type filament monitor on pin io2.in, enabled, sensitivity 0.291mm/pulse, allowed movement 65% to 140%, check every 3.0mm, measured sensitivity 0.289mm/pulse, measured minimum 76%, maximum 136% over 84145.8mm
(this data was the result of M591 D0 command after being reset, because I was afraid to hit limits overnight)

No, I will execute command :
M591 D0 P7 C"io2.in" L0.289 S1 R65:140 E3
Notice that Im changing the L value to be the measured mm/pulse reported by calibration data.
And I get after some printed mms:

M591 D0
Pulse-type filament monitor on pin io2.in, enabled, sensitivity 0.289mm/pulse, allowed movement 65% to 140%, check every 3.0mm, measured sensitivity 0.287mm/pulse, measured minimum 98%, maximum 104% over 28.5mm

Noticed the measured mm/pulse? it has gone done 0.002 again. It s extremely repeatable the change.

The problem now is: how do I now th REAL mm/pulse value. Original value was the one I got from the initial calibration run: 0.294 if I remember well. SO Now I executed again this:

M591 D0 P7 C"io2.in" L0.294 S1 R65:140 E3

And I get:
Pulse-type filament monitor on pin io4.in, enabled, sensitivity 0.294mm/pulse, allowed movement 65% to 140%, check every 3.0mm, measured sensitivity 0.290mm/pulse, measured minimum 98%, maximum 112% over 255.0mm

Again, mm/pulse is "reameasured" to a value around 0.002 and 0.004 mm smaller than my L set value

[T3P3Tony]

@Tinchus ah interesting, so what about if you set 0.3, 0.35, 0.25,0.2 etc? you might want to set the monitor to S0 so it does not actually pause the print during this testing.

[T3P3Tony]

also you may want to let it run for more than a few mm with the quite different values - check a few times to confirm the calibration value has stabilised before recording that and then trying a new one.

[Tinchus]

@T3P3Tony I have set it now to 0.3 and I get:

M591 D0
Pulse-type filament monitor on pin io2.in, enabled, sensitivity 0.300mm/pulse, allowed movement 65% to 140%, check every 3.0mm, measured sensitivity 0.291mm/pulse, measured minimum 100%, maximum 108% over 105.2mm

I will let it run but so fay, on ce a measure mm/pulse is reported, that measurement is very very stable (the sensor is well inside it limit capabilities) so I initially discarded a possible error introduced by the sensor, still this is my guess, not saying the sensor can not be the problem as a fact. But this measured mm/pulse change is very repeatable

[T3P3Tony]

@Tinchus yes i am not blaming the sensor either - just wanting to see more about the sisue you are describing as it may help to point to a possible cause. If we can prove a trend across a large range that will help i think. As you only have <4 pulse per mm there is a wide range of movement that can happen between pulses ( 0.294mm of movement ofcourse) so with retractions across pulse boundaries there is significant potential error.

[Tinchus]

@T3P3Tony Hello. Tis is the result I got from the weekend print. It was suposed to be a 72 hs print. It paused at 25hs and this is the result of the command M591 D0:

M591 D0
Pulse-type filament monitor on pin io2.in, enabled, sensitivity 0.300mm/pulse, allowed movement 65% to 170%, check every 3.0mm, measured sensitivity 0.286mm/pulse, measured minimum 88%, maximum 227% over 54956.8mm

Te reported values look very "wrong". 227% of max error would mean 1 of 2 things I think: or the sensor measured 227% extra movement (it can not be, the sensor is working really good. And still before lauching this print, I changed it to a new one just in case and calibration reported exactly the same values, so...) or something in the extruder made it move 227% more that the theoretical amouht expressed on gcode (that dodn not happened, the print paused and in terms of extrusion is perfect, 227% in overextrusion would have created a ball of plastic)

My guess is still the original and Im saying this without knowing the code in the formware so I can be really wrong: the formware looks like it is measuring the error over the entire used filament vs the sum of all error and not in the 3mm sample. If the firmware is taking a 3mm sample like in my config, error should be computed there and the reset to cero and start again in the next sample?

And more weird number" I cheged L to 0.35 and I get this:

M591 D0
Pulse-type filament monitor on pin io2.in, enabled, sensitivity 0.350mm/pulse, allowed movement 65% to 170%, check every 3.0mm, measured sensitivity 0.275mm/pulse, measured minimum 121%, maximum 147% over 25.0mm

Calibration mm/pulse went down again as expected, and max and min errors got crazy

[dc42]

@Tinchus unfortunately your pulse-type filament monitor doesn't distinguish between forwards and backwards motion (unlike Duet3D filament monitors, which do). Additionally some of those monitors have very little hysteresis, so that if the filament stops at a point where a the sensor is on the cusp of changing state you may get spurious pulses from it.

I am fairly sure that your sensor is detecting occasional high sensitivity values for one or both of these reasons. I suggest you allow a high upper tolerance to allow for these, for example by allowing 65% to 300%. What's important is that the measured lower sensitivity doesn't drop too much. Your measured lower value of 88% looks good.

[Tinchus]

@dc42 this sensor has the capability to detect forward and backward movements. I just didnt connect the cable that is suposed to be used for that, I only connected 1 of the cables so the sensor only detects movement. So have this extra cable, where should I connect in the duet?
My guess was: retraction should not be taken into account, the firmware knows that is doing a retraction, does it? so why take into account for calibration or for movement detection? Only extrusion should be taken into account I think

[jp.douarvil 0]

@Tinchus
RRF is a multipurpose firmware, it is supposed to be very tunable. Hence, depending on your specific hardware, sending negative E value does not necessarily equate to a retraction move (it could be just for unjamming, for backlash compensation, for a special tool change move or who knows what). So, unless you specifically indicate the firmware to retract/unretract filament (G11 command) the firmware will not assume by default that negative E value means a retraction which tracking value mustn't be taken into account.

[jp.douarvil 0]

I don't know how to connect the second wire to the duet to take direction into account. A quick and dirty work-around might be to post-process your g-code so to deactivate filament tracking just before a retraction move and reactivate it immediately afterward.