Magnetic filament sensor: tooMuchMovement?
-
I am getting an error intermittently of "Filament error on extruder 0: tooMuchMovement". I am using the Duet magnetic filament sensor bought ready assembled, connected to a Duet3 6HC running in SBC mode with a raspberry pi 5 with a nvme ssd. Extruder is a bondtech bmg to an e3d v6 hotend.
M584 E0.0 ; set extruder mapping M350 E16 I1 ; configure microstepping with interpolation M92 E830 ; configure steps per mm M566 E900 ; set maximum instantaneous speed changes (mm/min) M203 E600 ; set maximum speeds (mm/min) M201 E1600 ; set accelerations (mm/s^2)
M591 D0 P3 C"io5.in" S1 R50:120 ; filament monitor
Following the error I ran M591 D0 with the following result:
M591 D0 Duet3D magnetic filament monitor v4 on pin io5.in, enabled when SD printing, 28.80mm/rev, allow 50% to 120%, check printing moves every 3.0mm, mag 131 agc 55, measured 24.91mm/rev, min 95% max 105% over 644.7mm
I get the error maybe 2 or 3 times during a 1.5 hour print. What should I check? I know that if the filament feed has too much resistance that can cause a too little movement error, but what could cause too much movement?
-
but what could cause too much movement?
Interesting question. Proper movement is calculated from the commands in the print file - more precisely: from the effective commands RRF sends to the extruder. Thinking of calculation errors is a far fetched assumption not proven by facts. So, in my eyes, the real question is: What causes the MFM to sense (or report) too much movement?
Your
M591 D0
report looks pretty good, no signs of an over-emphasis on feed moves whatsoever. The only problem I can imagine is with retractions: if the MFM slips on these or fails to report very short retractions, RRF may get the impression of some over-extraction.To narrow-down on what really happens, you have several options:
• sharply reduce retraction speed in your slicer (just for testing purposes)
• allow for a bigger max value in yourM591
’s R parameter (that doesn’t harm anyway)
• add the E parameter with a value >3 (measurement interval in mm)If the error persists, shield the signal lines from the MFM to the Duet (or separate them from other cabling).
I think this one is unrelated, but you might want to add the L parameter to your
M591
in the config.g - here, you can enter the real mm/rev as reported inM591 D0
. -
@infiniteloop said in Magnetic filament sensor: tooMuchMovement?:
if the MFM slips on these or fails to report very short retractions, RRF may get the impression of some over-extraction.
yes this is a likely cause. especially if the retract and unretract speeds are set differently. For testing set these to the same and lower to confirm that's the issue.
If you change to firmware retraction then you can test this theory during a print by changing the retraction speeds and distance during a print.
-
I have changed the 'set maximum instantaneous speed changes (mm/min)' from 900 to 200 and the error has not happened since, but I have only run a couple of 2 hour prints and as the issue is/was intermittent I will run some further test with different values and see if this is the cause.
Thanks.
[Edit]
Having run more prints I am still getting occasional tooMuchMovement errors even with 'maximum instantaneous speed changes (mm/min)' set to 200. -
@bug2k22 if it's only occasional then you could allow a little more tolerance in your M591 command. Currently you allow 50% to 120%. You could increase the 120% to e.g. 150%.
How long is the filament path between the MFM and the extruder drive? Is that path well-constrained? the longer and less constrained that path is, the wider the tolerance you need to allow.
-
@dc42 The MFM sits directly on top of the extruder with just a small piece of ptfe tube between them.
I will try to increase the tolerance and see if helps, although the output of 'M591 D0' above does show the min and max measured still between the original values. -
the output of 'M591 D0' above does show the min and max measured still between the original values.
Anything outside the defined range will not be reported but invoke an error instead. So it is perfectly fine to widen the tolerance. However, it might be helpful to tell us if this error occurs in the vicinity of noticeable retractions or in some other context - from a distance, we can only guess what happens.