Spurious Sensor Errors
-
One thing i have noticed with this MFM sensor is the mm per rev's are very spontaneous between prints and power cycles of the printer. It'll be in the mid 20's one time, then the next time i go to use the printer it will be in the mid 30's, i've even seen as high as 12,000 once before.
9/17/2022, 9:04:08 AM M591 D0 Duet3D rotating magnet filament monitor v4 on pin e0stop, disabled, sensitivity 26.17mm/rev, allow 60% to 120%, check printing moves every 10.0mm, version 4, mag 130 agc 65, measured sensitivity 36.76mm/rev, min -4% max 140% over 9338.1mm 9/17/2022, 9:08:19 AM M591 D0 Duet3D rotating magnet filament monitor v4 on pin e0stop, disabled, sensitivity 26.17mm/rev, allow 60% to 120%, check printing moves every 10.0mm, version 4, mag 133 agc 67, measured sensitivity 35.39mm/rev, min -4% max 138% over 11639.3mm 9/17/2022, 9:08:26 AM M591 D0 Duet3D rotating magnet filament monitor v4 on pin e0stop, disabled, sensitivity 26.17mm/rev, allow 60% to 120%, check printing moves every 10.0mm, version 4, mag 132 agc 67, measured sensitivity 35.49mm/rev, min -4% max 138% over 11704.1mm 9/17/2022, 9:11:49 AM M591 D0 Duet3D rotating magnet filament monitor v4 on pin e0stop, disabled, sensitivity 26.17mm/rev, allow 60% to 120%, check printing moves every 10.0mm, version 4, mag 132 agc 67, measured sensitivity 38.88mm/rev, min -4% max 151% over 13606.2mm -
@invertmast said in Spurious Sensor Errors:
I tried printing Lo-fi's case a couple dozen times yesterday and never had any success
You might have a hard time trying this with a 1.2 mm nozzle.
@invertmast said in Spurious Sensor Errors:
I do have a resin printer and am printing the original housing currently
This should resolve the mechanical problems. On the electrical side, you can try to route the fan with lines separate from the cat6, that will improve the mfm's signal quality.
@invertmast said in Spurious Sensor Errors:
the mm per rev's are very spontaneous between prints
In most cases, this indicates mechanical issues.
-
@infiniteloop said in Spurious Sensor Errors:
@invertmast said in Spurious Sensor Errors:
I tried printing Lo-fi's case a couple dozen times yesterday and never had any success
You might have a hard time trying this with a 1.2 mm nozzle.
@invertmast said in Spurious Sensor Errors:
I do have a resin printer and am printing the original housing currently
This should resolve the mechanical problems. On the electrical side, you can try to route the fan with lines separate from the cat6, that will improve the mfm's signal quality.
@invertmast said in Spurious Sensor Errors:
the mm per rev's are very spontaneous between prints
In most cases, this indicates mechanical issues.
sorry, i tried printing the case on my other printer with a .4mm nozzle and .1mm layers. none came out well enough once it got to the standoffs that the circuit board mounts too.
-
@invertmast said in Spurious Sensor Errors:
none came out well enough once it got to the standoffs that the circuit board mounts to …
… which affects the distance between magnet (on the hobbed assembly) and sensor. Printing the housing with a FDM printer, two other areas can be problematic: the filament path and the function of the idler (both free movement of the idler bearing and the corps of the idler).
-
Finally got a decent housing printed out, assembled and a print going. Only to get a "sensor error" a little over an hour into this print.
M591 D0 Duet3D rotating magnet filament monitor v4 on pin e0stop, enabled, sensitivity 27.50mm/rev, allow 60% to 120%, check printing moves every 10.0mm, version 4, mag 133 agc 51, measured sensitivity 27.25mm/rev, min 86% max 105% over 44253.9mmM122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.1 (2022-06-01 21:05:28) running on Duet WiFi 1.02 or later + DueX5 Board ID: 08DGM-956GU-DJ3SJ-6J9DD-3SD6S-9UPZH Used output buffers: 3 of 26 (17 max) === RTOS === Static ram: 23860 Dynamic ram: 76472 of which 12 recycled Never used RAM 8544, free system stack 104 words Tasks: NETWORK(ready,41.9%,211) HEAT(notifyWait,0.2%,308) Move(notifyWait,5.5%,294) DUEX(notifyWait,0.0%,24) MAIN(running,52.3%,448) IDLE(ready,0.2%,30), total 100.0% Owned mutexes: WiFi(NETWORK) === Platform === Last reset 01:48:25 ago, cause: software Last software reset at 2022-09-17 18:39, reason: User, GCodes spinning, available RAM 8064, slot 2 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0 Step timer max interval 0 MCU temperature: min 33.6, current 34.8, max 36.3 Supply voltage: min 23.7, current 24.2, max 24.7, under voltage events: 0, over voltage events: 0, power good: yes Heap OK, handles allocated/used 99/1, heap memory allocated/used/recyclable 2048/12/0, gc cycles 0 Events: 1 queued, 1 completed Driver 0: standstill, SG min 0 Driver 1: standstill, SG min 0 Driver 2: standstill, SG min 0 Driver 3: standstill, SG min 0 Driver 4: standstill, SG min n/a Driver 5: standstill, SG min 0 Driver 6: standstill, SG min 0 Driver 7: standstill, SG min 0 Driver 8: standstill, SG min n/a Driver 9: standstill, SG min n/a Driver 10: Driver 11: Date/time: 2022-09-17 20:28:20 Cache data hit count 4294967295 Slowest loop: 81.53ms; fastest: 0.15ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 9 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest read time 1.6ms, write time 1.9ms, max retries 0 === Move === DMs created 83, segments created 14, maxWait 586279ms, bed compensation in use: mesh, comp offset 0.000 === MainDDARing === Scheduled moves 34273, completed 34273, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0 Heater 0 is on, I-accum = 0.0 === GCodes === Segments left: 0 Movement lock held by null HTTP is idle in state(s) 0 Telnet is idle in state(s) 0 File is idle in state(s) 0 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty === Filament sensors === Extruder 0: pos 237.30, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0 === DueX === Read count 1, 0.01 reads/min === Network === Slowest loop: 169.04ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 1 of 8 - WiFi - Network state is active WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.26 WiFi MAC address 5c:cf:7f:76:63:7a WiFi Vcc 3.40, reset reason Turned on by main processor WiFi flash size 4194304, free heap 25192 WiFi IP address 192.168.254.188 WiFi signal strength -61dBm, mode 802.11n, reconnections 0, sleep mode modem Clock register 00002002 Socket states: 0 0 0 0 0 0 0 0 -
Only to get a "sensor error" a little over an hour into this print.
Usually, this indicates an electrical problem: overtalking or interference with other lines. to rule this out, keep the sensor's lines separate from all others and keep them (relatively) short.
Finally got a decent housing printed out …
Congrats! Is it a resin print?
-
@infiniteloop said in Spurious Sensor Errors:
Only to get a "sensor error" a little over an hour into this print.
Usually, this indicates an electrical problem: overtalking or interference with other lines. to rule this out, keep the sensor's lines separate from all others and keep them (relatively) short.
Finally got a decent housing printed out …
Congrats! Is it a resin print?
I have since re-routed all of the fan/stepper wires away from the sensor wiring. I have a print going now to see if that will work.
not a resin print, just a ffm print of lofi's case.
-
Sensor Error's still continue.
M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.1 (2022-06-01 21:05:28) running on Duet WiFi 1.02 or later + DueX5 Board ID: 08DGM-956GU-DJ3SJ-6J9DD-3SD6S-9UPZH Used output buffers: 3 of 26 (17 max) === RTOS === Static ram: 23860 Dynamic ram: 76472 of which 12 recycled Never used RAM 8088, free system stack 100 words Tasks: NETWORK(ready,115.4%,229) HEAT(notifyWait,0.4%,308) Move(notifyWait,16.7%,295) DUEX(notifyWait,0.0%,24) MAIN(running,358.7%,440) IDLE(ready,0.5%,30), total 491.7% Owned mutexes: WiFi(NETWORK) === Platform === Last reset 02:52:12 ago, cause: power up Last software reset at 2022-09-17 18:39, reason: User, GCodes spinning, available RAM 8064, slot 2 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x08 Aux0 errors 0,1,0 Step timer max interval 0 MCU temperature: min 26.5, current 32.5, max 33.9 Supply voltage: min 23.7, current 24.2, max 24.7, under voltage events: 0, over voltage events: 0, power good: yes Heap OK, handles allocated/used 99/1, heap memory allocated/used/recyclable 2048/12/0, gc cycles 0 Events: 2 queued, 2 completed Driver 0: standstill, SG min 0 Driver 1: standstill, SG min 0 Driver 2: standstill, SG min 0 Driver 3: standstill, SG min 0 Driver 4: standstill, SG min n/a Driver 5: standstill, SG min 0 Driver 6: standstill, SG min 0 Driver 7: standstill, SG min 0 Driver 8: standstill, SG min n/a Driver 9: standstill, SG min n/a Driver 10: Driver 11: Date/time: 2022-09-18 10:26:41 Cache data hit count 4294967295 Slowest loop: 144.69ms; fastest: 0.12ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 9 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest read time 1.7ms, write time 59.9ms, max retries 0 === Move === DMs created 83, segments created 33, maxWait 128221ms, bed compensation in use: mesh, comp offset 0.000 === MainDDARing === Scheduled moves 98460, completed 98460, hiccups 0, stepErrors 0, LaErrors 0, Underruns [1, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0 Heater 0 is on, I-accum = 0.0 === GCodes === Segments left: 0 Movement lock held by null HTTP is idle in state(s) 0 Telnet is idle in state(s) 0 File is idle in state(s) 0 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty === Filament sensors === Extruder 0: pos 268.95, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0 === DueX === Read count 1, 0.01 reads/min === Network === Slowest loop: 162.93ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 1 of 8 - WiFi - Network state is active WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.26 WiFi MAC address 5c:cf:7f:76:63:7a WiFi Vcc 3.40, reset reason Turned on by main processor WiFi flash size 4194304, free heap 25352 WiFi IP address 192.168.254.188 WiFi signal strength -59dBm, mode 802.11n, reconnections 0, sleep mode modem Clock register 00002002 Socket states: 4 0 0 0 0 0 0 0 m591 D0 Duet3D rotating magnet filament monitor v4 on pin e0stop, enabled, sensitivity 27.50mm/rev, allow 60% to 120%, check printing moves every 10.0mm, version 4, mag 132 agc 47, measured sensitivity 27.15mm/rev, min 69% max 106% over 72205.7mm -
Sensor Error's still continue.
The best advice I can give at this stage is to use another cable for the MFM lines - simply throw some wires in to test the efficiency of that measure.
min 69% max 106% over 72205.7mmThe max value of 106% is fine, however, the min value reported looks a bit low to me: I'm not sure, but this might indicate a mechanical issue. Can you post a photo of how you've attached the MFM to your extruder?
-
Sensor is rigidly mounted via the short piece of bowden tube and via a bracket.
[
For comparison, my other printer has the MFM remotely mounted from the extruder gantry and its wiring is completely seperate from anything else until it gets within the electronics enclosure. It has the same problems even with using shielded 3 conductor wiring.
edit-1 At this point,
the sensor errors have gotten slightly better, but not much*Edit2,3,4 - they have not. I literally just had Six back to back within 5 minutes. They have gotten significantly worse in that the printer can't even get through a single layer now without a sensor error posting.I’m at the point where i would rather just set up a macro where if it comes as as sensor error that it would just restart the print on its own.
-
I’m at the point where i would rather just set up a macro where if it comes as as sensor error that it would just restart the print on its own.
Try that.
not a resin print, just a ffm print of lofi's case.
Looking at the rather low "min" values reported, you might want to file a bit to smoothen operation of the idler and to widen the filament path (really just a little bit). It should be possible to limit deviation on the low side to far less than 10%. However, this does not affect the rate of "sensor error" messages.
EDIT: Thanks for the photo. I wanted to have a look at the filament path, but you've built it just fine
-
@infiniteloop said in Spurious Sensor Errors:
I’m at the point where i would rather just set up a macro where if it comes as as sensor error that it would just restart the print on its own.
Try that.
not a resin print, just a ffm print of lofi's case.
Looking at the rather low "min" values reported, you might want to file a bit to smoothen operation of the idler and to widen the filament path (really just a little bit). It should be possible to limit deviation on the low side to far less than 10%. However, this does not affect the rate of "sensor error" messages.
EDIT: Thanks for the photo. I wanted to have a look at the filament path, but you've built it just fine
i did clean up the idler path a bit by scraping some of the layer line texture away with an Xacto knife blade.. it felt pretty smooth, but i can recheck after this print completes. As for the filament path, i'll give it a cleaning with a small drill bit.
-
@infiniteloop said in Spurious Sensor Errors:
I’m at the point where i would rather just set up a macro where if it comes as as sensor error that it would just restart the print on its own.
Try that.
not a resin print, just a ffm print of lofi's case.
Looking at the rather low "min" values reported, you might want to file a bit to smoothen operation of the idler and to widen the filament path (really just a little bit). It should be possible to limit deviation on the low side to far less than 10%. However, this does not affect the rate of "sensor error" messages.
EDIT: Thanks for the photo. I wanted to have a look at the filament path, but you've built it just fine
Thanks for the help the past few days. Still haven't figured out what is causing the sensor error's, even with running a separate 3 conductor shielded cable to the sensor outside of the drag chain from everything else. But, with the filament-error.g set to just ignore sensor error's, i've got mostly one entire print without an unnecessary pause.
-
Still haven't figured out what is causing the sensor error's, even with running a separate 3 conductor shielded cable to the sensor outside of the drag chain from everything else.
Sorry to hear that. I have no further idea of potential reasons, although reading the forum quite intensely.
With the filament-error.g set to just ignore sensor error's, i've got mostly one entire print without an unnecessary pause.
Great! I’ll try that myself, especially as I just encountered some of those sensor errors during my latest print. Among them, there was a single nozzle jam reported, so I still think the MFM is an invaluable tool as it saved my 22-hour print.
