RRF3.4 RC2 Filament error on extruder 0: sensorError
-
Finished downgrading the 6hc and 1lc to 3.3. Going to start a 17 hour print and see how it goes will report back with findings
-
Just got the same error but this time it is not on the console event. It was a pop out on the DWC where it says printing paused because extruder 0 reported "sensor error" once I close it there is nothing on the console.
Prior to resuming the print:
M591 D0
Duet3D rotating magnet filament monitor v3 on pin 121.io1.in, enabled, sensitivity 28.80mm/rev, allow 35% to 130%, check every 20.0mm, version 3, mag 129 agc 86, measured sensitivity 24.80mm/rev, min 75% max 102% over 39118.1mm
Diagnostics
=== Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.3 (2021-06-15 21:45:47) running on Duet 3 MB6HC v1.01 or later (SBC mode) Board ID: 08DJM-956BA-NA3TN-6JTD0-3SJ6S-1V82V Used output buffers: 1 of 40 (40 max) === RTOS === Static ram: 150904 Dynamic ram: 62356 of which 124 recycled Never used RAM 137952, free system stack 127 words Tasks: SBC(ready,4.6%,328) HEAT(delaying,0.0%,325) Move(notifyWait,0.3%,250) CanReceiv(notifyWait,0.0%,774) CanSender(notifyWait,0.0%,362) CanClock(delaying,0.0%,339) TMC(notifyWait,8.1%,59) MAIN(running,86.9%,922) IDLE(ready,0.0%,29), total 100.0% Owned mutexes: HTTP(MAIN) === Platform === Last reset 19:55:56 ago, cause: power up Last software reset at 2022-03-13 02:40, reason: HardFault, GCodes spinning, available RAM 141068, slot 1 Software reset code 0x4063 HFSR 0x40000000 CFSR 0x00080000 ICSR 0x0440f803 BFAR 0x00092040 SP 0x2041b180 Task MAIN Freestk 1663 ok Stack: 00000002 ffffffff 20418194 ffffffff 00000004 0047a67b 0047a714 610f0000 00000000 00000000 4ae049bf 0000000a 00000000 2042b7f0 20419728 2042cd74 00000000 44800000 003ffff5 0047a1d7 2042cd74 00000000 00000000 0047a51f 00000000 0047a67b 20429710 Error status: 0x04 Aux0 errors 0,0,0 Step timer max interval 208 MCU temperature: min 43.2, current 43.5, max 43.8 Supply voltage: min 23.9, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0 Heap OK, handles allocated/used 99/1, heap memory allocated/used/recyclable 2048/72/36, gc cycles 0 Driver 0: position 20165, standstill, reads 17186, writes 0 timeouts 0, SG min/max 0/1023 Driver 1: position -19365, standstill, reads 17187, writes 0 timeouts 0, SG min/max 0/1023 Driver 2: position 41331, standstill, reads 17186, writes 0 timeouts 0, SG min/max 0/1023 Driver 3: position 0, standstill, reads 17186, writes 0 timeouts 0, SG min/max 0/1023 Driver 4: position 0, standstill, reads 17186, writes 0 timeouts 0, SG min/max 0/1023 Driver 5: position 0, standstill, reads 17186, writes 0 timeouts 0, SG min/max 0/1023 Date/time: 2022-03-13 22:36:53 Slowest loop: 137.66ms; fastest: 0.02ms === Storage === Free file entries: 10 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === DMs created 125, maxWait 0ms, bed compensation in use: mesh, comp offset -0.046 === MainDDARing === Scheduled moves 965980, completed moves 965980, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 Heater 0 is on, I-accum = 0.2 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 Movement lock held by null HTTP* is doing "M122" in state(s) 0 0, running macro 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 SBC is idle in state(s) 0 Daemon is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause* is idle in state(s) 0 Code queue is empty. === Filament sensors === Extruder 0: no data received === CAN === Messages queued 96919, received 34382, lost 0, longest wait 5ms for reply type 6024, peak Tx sync delay 286, free buffers 49 (min 32), ts 13721/13721/0 Tx timeouts 0,0,0,0,0,0 === SBC interface === State: 4, failed transfers: 1, checksum errors: 0 Last transfer: 2ms ago RX/TX seq numbers: 6693/6693 SPI underruns 0, overruns 0 Disconnects: 0, timeouts: 0, IAP RAM available 0x2c810 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.3.0 HTTP: Executing macro 0:/macros/Diagnostics, started by M98 P"0:/macros/Diagnostics" > Next stack level Code buffer space: 4096 Configured SPI speed: 8000000Hz Full transfers per second: 47.19, max wait times: 90.0ms/0.0ms Codes per second: 27.73 Maximum length of RX/TX data transfers: 4403/1700 File /opt/dsf/sd/gcodes/Pandero 14in Mesh_0.6n_0.3mm_PLA_14h16m.gcode is selected, paused
Toolboard diagnostics
Diagnostics for board 121: Duet TOOL1LC firmware version 3.3 (2021-06-15 16:12:58) Bootloader ID: SAMC21 bootloader version 2.3 (2021-01-26b1) Never used RAM 2204, free system stack 2717 words Tasks: Move(notifyWait,1.0%,99) HEAT(delaying,0.2%,99) CanAsync(notifyWait,0.0%,61) CanRecv(notifyWait,0.2%,74) CanClock(notifyWait,0.0%,65) ACCEL(notifyWait,0.0%,61) TMC(delaying,2.9%,57) MAIN(running,90.6%,350) IDLE(ready,0.0%,27) AIN(delaying,5.0%,142), total 100.0% Last reset 19:56:02 ago, cause: power up Last software reset data not available Driver 0: position 38031462, 405.0 steps/mm, standstill, SG min/max 0/48, read errors 0, write errors 0, ifcnt 15, reads 976, writes 0, timeouts 1, DMA errors 0, failedOp 0x06, steps req 1994653 done 1994653 Moves scheduled 951641, completed 951641, in progress 0, hiccups 0, step errors 0, maxPrep 684, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0 Peak sync jitter 0/6, peak Rx sync delay 218, resyncs 0/0, no step interrupt scheduled VIN: 24.3V MCU temperature: min 40.7C, current 44.7C, max 52.8C Ticks since heat task active 98, ADC conversions started 71537725, completed 71537700, timed out 24, errs 0 Last sensors broadcast 0x00000002 found 1 103 ticks ago, loop time 0 CAN messages queued 33134, send timeouts 0, received 93367, lost 0, free buffers 37, min 35, error reg 0 dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 889, adv 22052/74662 Accelerometer detected: yes, status: 00 I2C bus errors 0, naks 0, other errors 0 === Filament sensors === Interrupt 4 to 36us, poll 8 to 7086us Driver 0: pos 121.29, errs: frame 306 parity 0 ovrun 0 pol 0 ovdue 0
Once the print finishes I plan on remaking the small harness for the filament sensor to see if that helps in any way.
-
Can you show a photo of how you have it mounted/installed?
When and where did you purchase the sensor?
-
Re wired the sensor and made sure I the connections were solid but just got the error an 74% complete. I bought it from filastruder on January 15th 2022. Here is how it is currently installed.
-
@charliedrums Can You check, if Object Model has correct data for this filament sensor? In my case they do not correspond to what is configured by M591
-
@boa Object model? I kinda lost you there.
-
@charliedrums In DWC:
M591 D0 P3 C"io5.in" S1 L25.4 R50:150 E12.7 A0, so sampleDistance, allowed range and mmPerRev have incorrect value (I think)
-
@boa Got you. Will do. At work right now but once I get home I'll check it out.
-
@boa I confirm this is a bug: changes to the filament monitor configuration values are not reflected in the OM browser in DWC. They are reported correctly by M409.
-
@boa I don't seem to have that on my DWC
Maybe because I'm running on a SBC (raspberryPi) -
On my last print I had the error occur once and the print took 17h 41m 30s
-
@charliedrums said in RRF3.4 RC2 Filament error on extruder 0: sensorError:
Maybe because I'm running on a SBC (raspberryPi)
The object model browser is a plugin you'd need to load.
@charliedrums said in RRF3.4 RC2 Filament error on extruder 0: sensorError:
On my last print I had the error occur once and the print took 17h 41m 30s
Can you check this thread for an updated housing for the sensor?
This person had good results from the change.
https://forum.duet3d.com/topic/27661/mfm-0-toolittlemovement/9
-
@phaedrux Will print the housing and test to see if that helps.
-
@phaedrux Reprinted the housing and assembled everything. My agc was a little low so I had to take it apart an shim it with a piece of paper. Now I have an agc within the range (59)
Duet3D rotating magnet filament monitor v3 on pin 121.io1.in, enabled, sensitivity 24.84mm/rev, allow 35% to 130%, check printing moves every 15.0mm, version 3, mag 131 agc 59, measured sensitivity 25.12mm/rev, min 98% max 101% over 781.5mm
I'm wating on some filament to start a couple of 15 to 17 hour prints to see if I keep getting the issue.
O and I updated to the RRF3.4 stable release.
Just if anyone was wondering, I make hand drums to play Plena (music from Puerto Rico) and I built a 24inx24inx26in printer to be able to print the drums in one go using the duet. That's why I have so many 15 to 20 hour prints to do.
-
@charliedrums said in RRF3.4 RC2 Filament error on extruder 0: sensorError:
agc 59
Still seems a bit low.
-
@phaedrux I showld shim it again? what would be a normal value?
-
If shimming was able to get you up to 59, then adding a bit more to get it closed to 100 might be worthwhile. But I'm not really sure. This may be fine at 59.
-
@phaedrux Brought it up to 70. Going to do some test prints to see if I get the error again.
M591 D0 Duet3D rotating magnet filament monitor v3 on pin 121.io1.in, enabled, sensitivity 24.84mm/rev, allow 35% to 130%, check printing moves every 15.0mm, version 3, mag 132 agc 70, measured sensitivity 24.82mm/rev, min 98% max 101% over 556.6mm
-
I updated to the release version 3.4. After reprinting the sensor hosing and having a consistent agc 72-76 I ran 3 15 to 23 hour Prints. I never got the
Error: Filament error on extruder 0: sensorError
but in every print I get once or twice the
Error: Filament error on extruder 0: tooLittleMovement
I know for a fact the the filament does not stop spinning the magnet. I printed the enclosure in clear filament so I can see the green LED of filament movement and after the first print I set a camera up and recorded the print. I always have a green light but I get the tooLittleMovement error. Could it be a noise issue? I have no idea.
I started creating a log file with M929 and these are the codes.
2022-03-24 22:04:20 Event logging started 2022-03-25 05:49:39 Error: Filament error on extruder 0: tooLittleMovement 2022-03-25 05:49:39 Resume state saved 2022-03-25 12:55:28 Printing resumed 2022-03-25 14:37:55 Finished printing file 0:/gcodes/Panderos 16in/Pandero 16in Organico_0.6n_0.3mm_PLA_21h58m.gcode, print time was 23h 43m
I'm thinking of just changing the sensor to the Sentinel Filament Detector from dyze. I know it is a dumber sensor but all I need to know is if I run out of filament. The last time I ever got a jam was back in 2014 with a Makerbot Replicator 2. So I really don't need that functionality.
-
Did the too little movement error cause a pause? Was it during an area of small short moves?
The magnet sensor also has a filament presence option. You just need to wire in the connection and setup the trigger.
https://docs.duet3d.com/User_manual/Connecting_hardware/Sensors_filament#connecting-to-the-duet
Optional filament presence switch
The Duet3D Rotating Magnet Filament Monitor and Duet3D Laser Filament Monitor have an optional filament presence switch. You can connect a microswitch to the 2-pin "SW" header arranged so that the switch contacts are closed when filament is present and open when it is not.
However, this is not normally necessary, because the filament monitor will detect that there is no filament moving through just a few mm after the end of the filament has passed over the sensor, which will normally be well before the end of the filament reaches the extruder drive.
Note this switch header is not populated in all versions of the monitor but it can be added if desired. It is a standard a standard Molex KK 2 pin header
Simple filament presence switch
For a simple filament presence switch connect the switch between the IN and GND pins of your chosen IO_x connector, as you would a normal microswitch endstop. We recommend you use the normally-closed contacts of a microswitch, which are generally the outside two connections on the microswitch, as the signal is less susceptible to interference than normally-open connections.