Magnetic Sensor - Extruder X reports sensor not working errors
-
@clegg78 hmm... not sure what’s going on. With the SD error, I’d be tempted to format a fresh SD card, copy all files over, and see if that helps, as intermittent SD cards can cause very random behaviour. Firmware 2.05.1 should have got rid of most of the output buffer errors, so it’s really looking for why they are happening with the filament sensors enabled. Can you disable them for a print, and see if the behaviour and errors go away? Either they are causing the errors, or some other error is causing them to misbehave.
Also, can you post your full config.g, and config_override.g if used? It may show up something. Finally, which version of DWC do you use?
Ian
-
Thanks for the reply!
So I spent the last few days doing a TON of testing. I put in a new SD card, and haven't seen any SD issues/errors since.
I am running DWC 2.1.1 (upgraded to it a week ago).
What I've seen in my testing is that:
- Output buffer overruns or exhaustion errors DO seem to coincide with getting sensor not working errors reported, but they can happen even without those errors it seems.
*Sensor Not Working errors can happen even without those happening though.
*These errors can happen early in a print, or late in a print... at high speed, or slow speed, during big continuous prints or short high retract prone print jobs.
*Currently E1 sensor is more prone to throwing these errors, but E0 does as well now and then. With the same frequency on Z and E1 endstop that they did on the CONN_LCD port. The E0 sensor is the newer replacement one of the two after the first E0 would throw errors all the time.
Current Diag from a print that has had 2 "Not Working" errors reported:
M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 2.05.1 running on Duet Ethernet 1.02 or later + DueX5 Board ID: 08DGM-917NK-F23T0-6J1F6-3SD6T-1GBWD Used output buffers: 3 of 24 (22 max) === RTOS === Static ram: 25712 Dynamic ram: 95048 of which 0 recycled Exception stack ram used: 488 Never used ram: 9824 Tasks: NETWORK(ready,628) HEAT(blocked,1232) DUEX(suspended,160) MAIN(running,3736) IDLE(ready,160) Owned mutexes: === Platform === Last reset 01:55:03 ago, cause: software Last software reset at 2020-04-12 09:12, reason: User, spinning module GCodes, available RAM 10028 bytes (slot 3) Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d Error status: 0 Free file entries: 8 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 66.6ms, max retries 0 MCU temperature: min 42.7, current 43.4, max 44.7 Supply voltage: min 23.9, current 23.9, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: standstill, SG min/max not available Driver 1: ok, SG min/max 406/1023 Driver 2: ok, SG min/max 402/1023 Driver 3: standstill, SG min/max not available Driver 4: standstill, SG min/max 0/1023 Driver 5: ok, SG min/max 13/1023 Driver 6: ok, SG min/max 15/1023 Driver 7: open-load-A open-load-B, SG min/max 16/1023 Driver 8: standstill, SG min/max not available Driver 9: standstill, SG min/max not available Date/time: 2020-04-12 11:07:47 Cache data hit count 4294967295 Slowest loop: 144.45ms; fastest: 0.09ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Move === Hiccups: 0, FreeDm: 158, MinFreeDm: 117, MaxWait: 0ms Bed compensation in use: mesh, comp offset 0.000 === DDARing === Scheduled moves: 109907, completed moves: 109867, StepErrors: 0, LaErrors: 0, Underruns: 0, 1 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 Heater 0 is on, I-accum = 0.2 Heater 2 is on, I-accum = 0.6 === GCodes === Segments left: 1 Stack records: 3 allocated, 0 in use 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 serial is idle in state(s) 0 aux is idle in state(s) 0 daemon is idle in state(s) 0 queue is idle in state(s) 0 autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 155.36ms; fastest: 0.06ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0) HTTP sessions: 2 of 8 Interface state 5, link 100Mbps full duplex === Filament sensors === Extruder 0: pos 0.00, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0 Extruder 1: pos 330.47, errs: frame 3 parity 0 ovrun 9 pol 1 ovdue 0
Current M591 for E1:
M591 D1 Duet3D magnetic filament monitor on input 4, enabled, sensitivity 26.50mm/rev, allow 30% to 140%, check every 60.0mm, version 3, mag 133 agc 98, measured sensitivity 26.30mm/rev, min 80% max 102% over 5406.4mm
Error in Event Log:
2020-04-12 09:13:14 Started printing file 0:/gcodes/Surgical_Mask_Strap_Remix - 10x-T1-edit.gcode 2020-04-12 10:12:48 Resume state saved 2020-04-12 10:12:48 Extruder 1 reports sensor not working 2020-04-12 10:12:55 Printing paused at X-9.1 Y-122.6 Z0.8 U-9.1 2020-04-12 10:13:12 Printing resumed 2020-04-12 10:22:48 Resume state saved 2020-04-12 10:22:48 Extruder 1 reports sensor not working 2020-04-12 10:22:54 Printing paused at X141.3 Y-42.1 Z0.7 U141.3 2020-04-12 10:23:11 Printing resumed
All I want is for the error to have more context as to WHY the sensor isnt working... These so far are costing me time, materials, and stress... while trying to address the rare print material feed or run-out issues.
I'll post my config in the next reply (due to forum post size limits)
- Output buffer overruns or exhaustion errors DO seem to coincide with getting sensor not working errors reported, but they can happen even without those errors it seems.
-
Current Config:
; General preferences M929 P"eventlog.txt" S1 ; Set event log G90 ; Send absolute coordinates... M83 ; ...but relative extruder moves M555 P2 ; Set firmware compatibility to look like Marlin G21 ; Work in millimetres ; Network M550 P"Joes Monster Printer" ; Set machine name M552 S1 ;DHCP for the printer ;M552 P192.168.50.45 S1 ; Enable network and set IP address ;M553 P255.255.255.0 ; Set netmask ;M554 P192.168.50.1 ; Set gateway M586 P0 S1 ; Enable HTTP M586 P1 S0 ; Disable FTP M586 P2 S0 ; Disable Telnet ; Movement section M569 P0 S0; Drive 0 goes backwards(change to S0 to reverse it) -X M569 P1 S1 ; Drive 1 goes forwards Z M569 P2 S1 ; Drive 2 goes forwards Z M569 P3 S0 ; Drive 3 goes backwards E0 M569 P4 S1 ; Drive 4 goes forwards E1 M569 P5 S1 ; Drive 5 goes forwards U M569 P6 S1 ; Drive 6 goes backwards Y M569 P7 S0 ; Drive 7 goes forwards Y M569 P8 S1 ; Drive 8 goes forwards M569 P9 S1 ; Drive 9 goes forwards ; Motor Assignments M584 X0 Y6:7 Z1:2 U5 E3:4 ; U Axis for second X stepper, dual X and Dual Y and dualZ ; Endstops M574 X1 Y2 U2 S1 ; Set endstop configuration (X and Y endstops at low end, U endstop at high end, active high ) M574 Z1 S2 ; Set endstops controlled by probe ; Motor Speeds and steps M350 Z16 I1 M350 X16 Y16 U16 I1; Configure microstepping with interpolation M350 E16:16 I1; Interpolation enabled for Extruders M906 X1100 Y1200 U1100 Z1150 E1000 I15; Set motor currents (mA) and motor idle factor in percent M84 S240 ; Set idle timeout ;Motor Stall Detection M915 X Y U F0 R1 S15 M915 Z F0 R2 S30 M92 X200 Y200 U200 Z1600; Set axis steps/mm - reduced the Z to 800 from 1600 in a test M92 E809:825 ; Set extruder steps per mm ; Speeds: M201 X1500 Y1500 U1500 Z500 E1900; Accelerations (mm/s^2) M203 X15000 Y15000 U15000 Z1800 E5000; Maximum speeds (mm/min) M205 X16 Y14 U16 Z8 E20 ; Maximum jerk speeds mm/sec ;M204 P800 T2000 ; Set printing and travel accelerations ; Build volume (Center 0 Adjusted) ;Printable volume 305x 305y M208 X152.5 Y174.5 U203.78 Z300 ; Set axis maxima (adjust to suit your machine) U 203.35 original - Tweaking to 203.78 to test aligment (moving to the left) M208 X-198.5 Y-189.5 U-152.5 Z0 S1 ; Set axis minimum (adjust to make X=0 and Y=0 the CENTER of the bed) -3mm between the X and U wit the U being 3mm further back, so add -3 to the Y number ;Filament settings M404 N1.75 D0.4 ; Set nominal filament diameter to 1.75 and nozzle width to 0.4 ;Call Filament Sensor Configurations M98 P/macros/jobscripts/FilamentSensor.g ;Cold Extrusion Limit M302 S185 R185 ; ############# Z-Probe M307 H3 A-1 C-1 D-1 ; Disable heater on PWM channel for BLTouch M558 P9 H3 F75 T2000 A10 R0.8 S0.004 ; P9 for BLTouch, dive height 3mm, probe at 75mm/s, travel 2000mm/s, up to 10 probes, pause 0.8s, variance of .003 G31 X13 Y34 Z1.08 P25 ; Set Z probe trigger value, offset and trigger height Zoffset at 1.08 (Higher the number the closer to the nozzle) - move to 1.08 from 1.10 for PETG printing and testing M557 X-150:150 Y-150:150 S60 ; Changed to center the bed. M376 H3 ; Taper off compensation over 3mm of height ; ########### Heaters M307 H0 F5 ; Disable bang-bang mode for the bed heater and set PWM limit -Commented as it is defined in the config override. M305 P0 T100000 B3950 ; Set thermistor + ADC parameters for heater 0 M143 H0 S140 ; Set temperature limit for heater 0 to 140C M305 P1 T100000 B4725 C7.06e-8 ; Set thermistor + ADC parameters for heater 1 M143 H1 S285 ; Set temperature limit for heater 1 to 285 ( Limit of the thermistor) M305 P2 T100000 B4725 C7.06e-8 ; Set thermistor + ADC parameters for heater 2 M143 H2 S285 ; Set temperature limit for heater 2 to 285C (limit of the thermistor) ; Virtual heater names M305 P101 S"DuetDriversTemp" M305 P102 S"DuexDriversTemp" ; ############ Fans M106 P0 C"E0 Part Fan" ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off M106 P1 H-1 S0 C"E1 Part Fan" ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned off ; Default Part Fans to 0 M106 P2 F1 L100 X255 B1 T40:50 H100:101:102 C"Board Fans" ; Set fan 2 Duet case fan. Turns on when the MCU temperature (virtual heater 100) ; reaches 40C and reaches full speed when the MCU temperature reaches 50C or if any TMC2660 ; drivers (virtual heaters 101 and 102) report that they are over-temperature ; Minimum speed 100, PWM frequency 1 M106 P3 C"E0 Hot End Fan" T80 L0 X255 H1 ;12v Fan for the hot end run off the Duex M106 P4 C"E1 Hot End Fan" T80 L0 X255 H2 ;12v Fan for the hot end run off the Duex ; ############### LEDs (Updated) ;Populate start state for LEDs ;start up state for the LEDs M106 P6 S0 C"E0 R LED" M106 P7 S0 C"E1 R LED" M106 P8 S0 C"Bed R LED" M106 P5 S0 C"Pause LED" ;###TOOL DEFINITIONS#### ; Tool 0 X - Left hand Extruder M563 P0 D0 H1 F0 X0 S"Left Titan Aero" ; tool 0 uses extruder 0 and heater 1 and maps X to X, use fan 2 as the print cooling fan G10 P0 X0 Y0 Z0 ; Set tool 0 axis offsets ;G10 P0 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C ;Tool 1 U - Right hand Extruder M563 P1 D1 H2 X3 F1 S"Right Titan Aero" ; tool 1 uses extruder 1 and heater 2 and maps X to U, use fan 1 as the print cooling fan G10 P1 X0 Y-3.52 Z0 ; Set initial tool 1 active and standby temperatures to 0C (was -.71 before adjusted the Left X axis down) Tweaked Y it was -2.95 ;G10 P1 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C ; Duplication Tool 2 M563 P2 D0:1 H1:2 X0:3 F0:1 S"Dual Duplication Print" ; tool 2 uses both extruders and hot end heaters, maps X to both X and U, and uses both print cooling fans G10 P2 X76 Y0 U-76 Z0 ; set tool offsets and temperatures for tool 2 ;G10 P2 R0 S0 M567 P2 E1:1 ; set mix ratio 100% on both extruders ; Mirror Tool 3 M563 P3 D0:1 H1:2 X0:3 F0:1 S"Dual Mirror Print" ; tool 2 uses both extruders and hot end heaters, maps X to both X and U, and uses both print cooling fans G10 P3 X85 Y0 U-85 Z0 ; set tool offsets and temperatures for tool 2 (+10mm offset for clearance due to the mirroring movements) ;G10 P3 R0 S0 M567 P3 E1:1 ; set mix ratio 100% on both extruders ; Automatic saving after power loss is not enabled M501 ; Load Config Override items
My config override just has hot end/hot bed calibrations in it.
Macro I call to load the filament sensor config:
;Magnetic Filament Sensor M591 D0 P3 C2 S1 R30:140 L25.6 E60 M591 D1 P3 C4 S1 R30:140 L26.5 E60 ;disable sensors ;M591 D0 S0 P0 ;M591 D1 S0 P0
-
I've ended up disabling the sensors on my system for now, and may remove them entirely until a solution can be found that lets them work consistently. As someone else has posted (and from my searching "Not Working" errors seem to be tied to people running the DUEX boards as well. ) I cant test if they don't have the issues without the Duex as it's needed to run my printer.
IMO this is a Duet firmware/hardware issue that needs to be resolved. I even changed the wires over to shielded/grounded wires to ensure there was no interference in the loop.
At this point the sensors are a liability and I cant trust them.
-
So I was doing some testing after having both sensors disabled for the last few weeks. Once I enable them I start seeing Error codes and output buffer overruns. If I disable them, I never see error codes. Regardless if they are on the CONN_LCD or on normal end stops.
-
@clegg78 There was a recent very lengthy thread regarding someone who had problems with errors and underruns, and it came down to having wires running next to or along the ribbon cable that connects the Duet and Duex. This is because the ribbon cable can pick up interference from other cables relatively easily. Can you check your cables don't run near the ribbon cable?
Ian
-
I will check that. Currently the only wires running near the ribbon for the Duex are power 24v runs, everything else is either sheilded or away from the ribbon wire. Would a shorter wire help limit that issue? My Duet and Duex are very close to one another, and I could shorten that wire considerably. I will work on rerouting some wiring away from that connector. The Conn_LCD connector is close to the ribbon in general but the wires run away from the connector for the sensors.
I will do some testing and checking on that. I'll also look for that thread!
Thanks
-
@clegg78 said in Magnetic Sensor - Extruder X reports sensor not working errors:
I'll also look for that thread!
Started in this one: https://forum.duet3d.com/topic/15421/duet-2-05-memory-leak
Continued here, with final identification of problem here: https://forum.duet3d.com/post/149785Ian
-
@droftarts Thanks!
I just finished upgrading to RRF3 3.01 RC12 just to keep current, I am going to shorten the ribbon for the Duex and wrap it in aluminized tape, and move some of the wires away from it. I will report back!
-
So I shortened the ribbon for the Duet/Duex by about 1.5" (I know how to re-terminate make 50 pin cables from my SCSI days) I moved all the wires away from the ribbon as well.
I powered up the printer running RRF 3.01RC12, and went to lunch to work on it later. All I did was enable the 2 sensors, and my standard config (updated for RRF3).
When I came back from lunch I ran M122 and saw it ran into a buffer exhaustion issues while it was just sitting here!!
M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.01-RC12 running on Duet Ethernet 1.02 or later + DueX5 Board ID: 08DGM-917NK-F23T0-6J1F6-3SD6T-1GBWD Used output buffers: 3 of 24 (24 max) === RTOS === Static ram: 28084 Dynamic ram: 97540 of which 44 recycled Exception stack ram used: 536 Never used ram: 4868 Tasks: NETWORK(ready,176) SENSORS(blocked,112) HEAT(blocked,1228) DUEX(suspended,160) MAIN(running,1828) IDLE(ready,76) Owned mutexes: === Platform === Last reset 00:43:24 ago, cause: power up Last software reset at 2020-05-14 10:59, reason: User, spinning module GCodes, available RAM 4936 bytes (slot 2) Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN Error status: 4 MCU temperature: min 41.1, current 41.7, max 42.2 Supply voltage: min 23.9, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: standstill, SG min/max not available Driver 1: standstill, SG min/max not available Driver 2: standstill, SG min/max not available Driver 3: standstill, SG min/max not available Driver 4: standstill, SG min/max not available Driver 5: standstill, SG min/max not available Driver 6: standstill, SG min/max not available Driver 7: standstill, SG min/max not available Driver 8: standstill, SG min/max not available Driver 9: standstill, SG min/max not available Date/time: 2020-05-14 12:08:16 Cache data hit count 4294967295 Slowest loop: 12.49ms; 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.5ms, write time 4.4ms, max retries 0 === Move === Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves: 12, completed moves: 12, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === AuxDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 Heater 1 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 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 11.49ms; fastest: 0.05ms Responder states: HTTP(2) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) HTTP sessions: 1 of 8 Interface state active, link 100Mbps full duplex === Filament sensors === Extruder 0: pos 0.00, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0 Extruder 1: pos 0.00, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0 === DueX === Read count 0, 0.00 reads/min
The wire closest to the ribbon there is an LED that turns on only when the printer is paused.
-
-
@droftarts @dc42 Thanks!
So tonight I was doing a long 7 hour print, after upgrading to RRF 3.1 on my Duet 2 Ethernet.
The Sensor on E0 that was printing worked fine for ~ the first 4 or 5 hours. Then it had the first "Sensor not working" error, then a second about 4hours later.
The weird thing was after the last one, the sensor went dark. No LED flashing, nothing... After the print I plugged it back in and it started flashing again. Could there be some static discharge issue at play here? (correction - the last event was a "too little movement error" when the sensor was visibly dead) The E0 sensor is the older of the two, I RMA'd the E1 sensor already.
I did see an Error Code 4 come up in the M122, but that happened about hour 2 or 3 into the print, before any "Not Working" error happened.
I am onto another print that I need to get done tonight, but here is the M122 from that (Note I disabled the E0 sensor for this print as I cant have it stop overnight)
m122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.1.0 running on Duet Ethernet 1.02 or later + DueX5 Board ID: 08DGM-917NK-F23T0-6J1F6-3SD6T-1GBWD Used output buffers: 3 of 24 (24 max) === RTOS === Static ram: 28180 Dynamic ram: 97052 of which 464 recycled Exception stack ram used: 600 Never used ram: 4776 Tasks: NETWORK(ready,36) SENSORS(blocked,112) HEAT(blocked,1224) DUEX(suspended,160) MAIN(running,1732) IDLE(ready,80) Owned mutexes: === Platform === Last reset 12:10:33 ago, cause: software Last software reset at 2020-05-19 10:25, reason: Stack overflow, spinning module none, available RAM 4932 bytes (slot 2) Software reset code 0x4111 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80e BFAR 0xe000ed38 SP 0x2001ffb4 Task NETW Stack: 20002860 20002894 00455625 00000000 00000000 200029b8 20002a55 0000000a 00454c35 200028c4 200055f4 Error status: 4 MCU temperature: min 42.3, current 43.4, 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 Driver 0: ok, SG min/max 25/1023 Driver 1: standstill, SG min/max 170/1023 Driver 2: standstill, SG min/max 161/1023 Driver 3: ok, SG min/max 0/1023 Driver 4: standstill, SG min/max not available Driver 5: standstill, SG min/max 337/1023 Driver 6: ok, SG min/max 18/1023 Driver 7: ok, SG min/max 18/1023 Driver 8: standstill, SG min/max not available Driver 9: standstill, SG min/max not available Date/time: 2020-05-19 22:36:08 Cache data hit count 4294967295 Slowest loop: 8.91ms; fastest: 0.14ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 8 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest read time 5.2ms, write time 0.0ms, max retries 0 === Move === Hiccups: 0(0), FreeDm: 162, MinFreeDm: 143, MaxWait: 976200ms Bed compensation in use: mesh, comp offset 0.000 === MainDDARing === Scheduled moves: 5667, completed moves: 5647, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: 3 === AuxDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 Heater 0 is on, I-accum = 0.1 Heater 1 is on, I-accum = 0.6 === GCodes === Segments left: 1 Movement lock held by null HTTP is idle in state(s) 0 Telnet is idle in state(s) 0 File is doing "G1 X-46.276 Y21.579 F3705" 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 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 17.16ms; fastest: 0.05ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 1 of 8 Interface state active, link 100Mbps full duplex === Filament sensors === Extruder 1: pos 0.00, errs: frame 0 parity 0 ovrun 0 pol 1 ovdue 0 === DueX === Read count 0, 0.00 reads/min
The Event log:
2020-05-19 15:07:42 Started printing file 0:/gcodes/K40ElbowMK1.gcode 2020-05-19 15:37:59 Resume state saved 2020-05-19 15:38:02 Printing paused at X-16.8 Y-53.9 Z1.2 U201.0 2020-05-19 15:41:02 Printing resumed 2020-05-19 15:41:23 Resume state saved 2020-05-19 15:41:26 Printing paused at X-32.5 Y-63.7 Z1.2 U201.0 2020-05-19 15:41:39 Printing resumed 2020-05-19 15:55:19 HTTP client 192.168.50.122 login succeeded 2020-05-19 17:32:47 HTTP client 192.168.50.122 disconnected 2020-05-19 17:32:58 HTTP client 192.168.50.122 disconnected 2020-05-19 17:33:00 HTTP client 192.168.50.122 login succeeded 2020-05-19 17:33:51 HTTP client 192.168.50.122 disconnected 2020-05-19 19:23:41 Resume state saved 2020-05-19 19:23:41 Extruder 0 reports sensor not working 2020-05-19 19:23:45 Printing paused at X47.1 Y8.1 Z50.1 U201.0 2020-05-19 19:24:10 HTTP client 192.168.50.137 login succeeded 2020-05-19 19:24:40 Printing resumed 2020-05-19 21:14:35 HTTP client 192.168.50.137 login succeeded 2020-05-19 21:16:48 HTTP client 192.168.50.137 login succeeded 2020-05-19 21:16:57 HTTP client 192.168.50.137 login succeeded 2020-05-19 22:03:39 Resume state saved 2020-05-19 22:03:39 Extruder 0 reports too little movement 2020-05-19 22:03:42 Printing paused at X-3.8 Y-54.5 Z110.1 U201.0 2020-05-19 22:04:47 HTTP client 192.168.50.137 login succeeded 2020-05-19 22:04:48 HTTP client 192.168.50.137 login succeeded 2020-05-19 22:05:18 Printing resumed 2020-05-19 22:11:53 Finished printing file 0:/gcodes/K40ElbowMK1.gcode, print time was 6h 58m 2020-05-19 22:24:44 Started printing file 0:/gcodes/Elbow Top.gcode
-
@clegg78 Can you post the response to M591 D0 and M591 D1? Though I think you'll need to run both of them for a short while to get any data. Are they still connected to Z and E1 endstops?
It still feels like an SPI problem between the Duet and Duex to me, ie something glitchy in communication between the two causing the error 4 (Output buffer starvation). I don't know if it is the sensors causing it, or the sensors misreading as a result. One thing I notice is from your config.g is that you have the X axis (X and U) split, with X on the Duet and U on the Duex. I guess you combine these to X with M584 X0:5 after homing X? My thinking is that it would be better to have the motors of each axis on the same driver, and have X, U and Y on the Duet, Z and extruders on the Duex, if possible.
Ian
-
@droftarts said in Magnetic Sensor - Extruder X reports sensor not working errors:
till feels like an SPI problem between the Duet and Duex to me, ie something glitchy in communication between the two causing the error 4 (Output buffer starvation). I don't know if it is the sensors causing it, or the sensors misreading as a result. One thing I notice is from your config.g is that you have the X axis (X and U) split, with X on the Duet and U on the Duex. I guess you combine these to X with M584 X0:5 after homing X? My thinking is that it would be better to have the motors of each axis on the same driver, and have X, U and Y on the Duet, Z and extruders on the Duex, if possible.
Yeah I am about to print again and I will get the info from them for you.
Also I noticed something interesitng, I just connected to the printer after it was sitting idle for a few hours after powering up. and on connection I heard it reboot the machine. I checked the M122 and saw this:
Last reset 00:00:23 ago, cause: software Last software reset at 2020-05-20 13:46, reason: Stack overflow, spinning module none, available RAM 4932 bytes (slot 3) Software reset code 0x4111 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80e BFAR 0xe000ed38 SP 0x2001ffb4 Task NETW Stack: 20002860 20002894 00455625 00000000 00000000 200029b8 00000000 a0000000 00454c35 200028c4 200055f4 Error status: 0
A Stack Overflow reset out of nowhere? Not sure I've seen that before.
-
@clegg78 said in Magnetic Sensor - Extruder X reports sensor not working errors:
A Stack Overflow reset out of nowhere? Not sure I've seen that before.
That's a known issue with RRF 3.1.0, fixed in 3.1.1.
-
Have all your "sensor not working" errors been accompanied by the sensor no longer flashing?
There could indeed be a static discharge issue. Have you grounded the body of the extruder stepper motor?
-
No that was the first time I've seen that happen, after unplugging and replugging it, it worked again. The Extruder body isnt grounded (its on the X Axis gantry, direct drive extruder, so no easy way to ground it. I dont have an extra wire in the bundle going to the printer right now that carries a ground consistently. I could look into running a small ground wire in the bundle to the extruders.
And yeah upgrading to 3.1.1 fixed that stack overflow error.
-
I've been running 3.1.1 for a bit and just tonight, ran in a similar problem. I'll create a new thread with the exact issue.