Checksum errors

dc42

Please post a new M122 report when a job has been running and checksum errors have been reported. I am particularly interested in the Hiccup Count. Note, every time you run M122 this value is reset to zero and starts counting again. So start a print, run a job until several checksum errors have been reported, then run M122 and post the results of that command.

Also, please post your config.g file.

NAK_3D

I am having similar issues with prints just randomly stopping and the printer not functioning till its reset. I am also seeing the same checksum errors.. Has there been any resolution found yet?

droftarts

@NAK_3D It looks like the OP never responded to @dc42 request, so we haven't been able to track down the bug. Could you?

Please post a new M122 report when a job has been running and checksum errors have been reported. I am particularly interested in the Hiccup Count. Note, every time you run M122 this value is reset to zero and starts counting again. So start a print, run a job until several checksum errors have been reported, then run M122 and post the results of that command.

Also, please post your config.g file.

Ian

NAK_3D

Here is the M122 file you requested.. sorry for the lost format..
11:10:44 PM: M122: === Diagnostics ===RepRapFirmware for Duet 2 WiFi/Ethernet version 2.04RC1 running on Duet WiFi 1.02 or laterBoard ID: 08DGM-917DA-G4MSD-6J9DD-3SJ6K-18T39Used output buffers: 1 of 24 (9 max)=== RTOS ===Static ram: 25680Dynamic ram: 94108 of which 372 recycledException stack ram used: 524Never used ram: 10388Tasks: NETWORK(ready,640) HEAT(blocked,1236) MAIN(running,3820) IDLE(ready,160)Owned mutexes:=== Platform ===Last reset 09:11:01 ago, cause: power upLast software reset at 2019-11-03 10:39, reason: User, spinning module GCodes, available RAM 10600 bytes (slot 2)Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414dError status: 0Free file entries: 9SD card 0 detected, interface speed: 20.0MBytes/secSD card longest block write time: 3.7ms, max retries 0MCU temperature: min 21.8, current 32.3, max 33.2Supply voltage: min 23.6, current 24.0, max 24.4, under voltage events: 0, over voltage events: 0, power good: yesDriver 0: open-load-B, SG min/max 0/1023Driver 1: ok, SG min/max 0/1023Driver 2: standstill, SG min/max not availableDriver 3: ok, SG min/max 0/1023Driver 4: standstill, SG min/max not availableDate/time: 2019-11-03 23:10:40Cache data hit count 4294967295Slowest loop: 25.82ms; fastest: 0.08msI2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0=== Move ===Hiccups: 0, FreeDm: 160, MinFreeDm: 106, MaxWait: 131709msBed compensation in use: none, comp offset 0.000=== DDARing ===Scheduled moves: 950081, completed moves: 950041, StepErrors: 0, LaErrors: 0, Underruns: 0, 0=== Heat ===Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1Heater 0 is on, I-accum = 0.0Heater 1 is on, I-accum = 0.5=== GCodes ===Segments left: 1Stack records: 1 allocated, 0 in useMovement lock held by nullhttp is idle in state(s) 0telnet is idle in state(s) 0file is idle in state(s) 0serial is idle in state(s) 0aux is idle in state(s) 0daemon is idle in state(s) 0queue is idle in state(s) 0autopause is idle in state(s) 0Code queue is empty.=== Network ===Slowest loop: 20.65ms; fastest: 0.00msResponder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)HTTP sessions: 1 of 8- WiFi -Network state is runningWiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0WiFi firmware version 1.23WiFi MAC address ec:fa:bc:2d:e6:4bWiFi Vcc 3.41, reset reason Turned on by main processorWiFi flash size 4194304, free heap 25712WiFi IP address 192.168.1.9WiFi signal strength -51dBm, reconnections 0, sleep mode modemSocket states: 0 0 0 0 0 0 0 0=== Filament sensors ===Extruder 0: pos 97.03, ok, measured sens 26.32mm/rev min 61% max 128% over 32898.0mm, errs: frame 7 parity 0 ovrun 0 pol 138 ovdue 0

NAK_3D

Here is my config.g
; Configuration file for Duet WiFi (firmware version 2.03)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v2.0.4 on Sat Oct 05 2019 18:12:48 GMT-0400 (Eastern Daylight Time)

; General preferences
G90 ; send absolute coordinates...
M83 ; ...but relative extruder moves
M550 P"Squire" ; set printer name

M667 S1 ; select CoreXY mode

; Network
M552 S1 ; enable network
M587 S"" P"" ; Configure access point. You can delete this once connected
M586 P0 S1 ; enable HTTP
M586 P1 S0 ; disable FTP
M586 P2 S0 ; disable Telnet

; Drives
M569 P0 S1 ; physical drive 0 goes forwards X
M569 P1 S1 ; physical drive 1 goes forwards Y
M569 P2 S0 ; physical drive 2 goes backwards Z
M569 P3 S0 ; physical drive 3 goes Backwards E0
M584 X0 Y1 Z2 E3 ; set drive mapping
M350 X16 Y16 Z16 E16 I1 ; configure microstepping with interpolation
M92 X200.00 Y200.00 Z69.67 E811.49 ; set steps per mm
M566 X900.00 Y900.00 Z12.00 E900.00 ; set maximum instantaneous speed changes (mm/min)
M203 X18000.00 Y18000.00 Z1000.00 E3000.00 ; set maximum speeds (mm/min)
M201 X1000.00 Y1000.00 Z500.00 E1000.00 ; set accelerations (mm/s^2)
M906 X1000 Y1000 Z2300 E1000 I30 ; set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout

; Axis Limits
M208 X-48 Y0 Z0 S1 ; set axis minima
M208 X237 Y305 Z10000000000000000000 S0 ; set axis maxima

; Endstops
M574 Z0 S0 ; set active low and disabled endstops
M574 X1 Y1 S1 ; set active high endstops

; Z-Probe
M558 P0 H5 F120 T6000 ; disable Z probe but set dive height, probe speed and travel speed
M557 X15:215 Y15:195 S20 ; define mesh grid

; Heaters
M305 P0 T100000 B4725 C7.060000e-8 R4700 ; set thermistor + ADC parameters for heater 0
M143 H0 S110 ; set temperature limit for heater 0 to 110C
M305 P1 T100000 B4725 C7.060000e-8 R4700 ; set thermistor + ADC parameters for heater 1
M143 H1 S280 ; set temperature limit for heater 1 to 280C

; Fans
M106 P0 S0 I0 F500 H-1 ; set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off
M106 P1 S0 I0 F500 H-1 ; set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned off

; Tools
M563 P0 D0 H1 F0 ; define tool 0
G10 P0 X0 Y0 Z0 ; set tool 0 axis offsets
G10 P0 R0 S0 ; set initial tool 0 active and standby temperatures to 0C

; Custom settings are not defined

; Miscellaneous
M501 ; load saved parameters from non-volatile memory
M911 S10 R11 P"M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000" ; set voltage thresholds and actions to run on power loss
M591 D0 P3 C3 S0 R68:132 L24.8 E3.0 ; Duet3D rotating magnet sensor for extruder drive 0 is connected to E0 endstop input, enabled, sensitivity 24.8mm.rev, 70% to 130% tolerance, 3mm detection length

dc42

@NAK_3D said in Checksum errors:

Here is the M122 file you requested.. sorry for the lost format..
11:10:44 PM: M122: === Diagnostics ===RepRapFirmware for Duet 2 WiFi/Ethernet version 2.04RC1 running on Duet WiFi 1.02 or laterBoard ID: 08DGM-917DA-G4MSD-6J9DD-3SJ6K-18T39Used output buffers: 1 of 24 (9 max)=== RTOS ===Static ram: 25680Dynamic ram: 94108 of which 372 recycledException stack ram used: 524Never used ram: 10388Tasks: NETWORK(ready,640) HEAT(blocked,1236) MAIN(running,3820) IDLE(ready,160)Owned mutexes:=== Platform ===Last reset 09:11:01 ago, cause: power upLast software reset at 2019-11-03 10:39, reason: User, spinning module GCodes, available RAM 10600 bytes (slot 2)Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414dError status: 0Free file entries: 9SD card 0 detected, interface speed: 20.0MBytes/secSD card longest block write time: 3.7ms, max retries 0MCU temperature: min 21.8, current 32.3, max 33.2Supply voltage: min 23.6, current 24.0, max 24.4, under voltage events: 0, over voltage events: 0, power good: yesDriver 0: open-load-B, SG min/max 0/1023Driver 1: ok, SG min/max 0/1023Driver 2: standstill, SG min/max not availableDriver 3: ok, SG min/max 0/1023Driver 4: standstill, SG min/max not availableDate/time: 2019-11-03 23:10:40Cache data hit count 4294967295Slowest loop: 25.82ms; fastest: 0.08msI2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0=== Move ===Hiccups: 0, FreeDm: 160, MinFreeDm: 106, MaxWait: 131709msBed compensation in use: none, comp offset 0.000=== DDARing ===Scheduled moves: 950081, completed moves: 950041, StepErrors: 0, LaErrors: 0, Underruns: 0, 0=== Heat ===Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1Heater 0 is on, I-accum = 0.0Heater 1 is on, I-accum = 0.5=== GCodes ===Segments left: 1Stack records: 1 allocated, 0 in useMovement lock held by nullhttp is idle in state(s) 0telnet is idle in state(s) 0file is idle in state(s) 0serial is idle in state(s) 0aux is idle in state(s) 0daemon is idle in state(s) 0queue is idle in state(s) 0autopause is idle in state(s) 0Code queue is empty.=== Network ===Slowest loop: 20.65ms; fastest: 0.00msResponder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)HTTP sessions: 1 of 8- WiFi -Network state is runningWiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0WiFi firmware version 1.23WiFi MAC address ec:fa:bc:2d:e6:4bWiFi Vcc 3.41, reset reason Turned on by main processorWiFi flash size 4194304, free heap 25712WiFi IP address 192.168.1.9WiFi signal strength -51dBm, reconnections 0, sleep mode modemSocket states: 0 0 0 0 0 0 0 0=== Filament sensors ===Extruder 0: pos 97.03, ok, measured sens 26.32mm/rev min 61% max 128% over 32898.0mm, errs: frame 7 parity 0 ovrun 0 pol 138 ovdue 0

Was that M122 run during or immediately after running a print during which checksum errors were displayed?

NAK_3D

@dc42 the M122 was run during a print after several errors had occurred.

dc42

The hiccup count is zero, so it's not likely to be caused by the processor being unable to service the interrupt. My best guesses are that the PanelDue cable is running close to a source of noise, such as a stepper motor cable, or that the cable it too long or too thin to pass the data without risk of corruption (resistance per conductor must be 0.1 ohm or less), or a bad crimp connection.

NAK_3D

@dc42 That's unfortunate... This means there is still an unknown issue causing the duet to randomly reset..

dc42

@NAK_3D said in Checksum errors:

@dc42 That's unfortunate... This means there is still an unknown issue causing the duet to randomly reset..

The M122 report you posted earlier shows that the last reset before you ran that was caused by power up. If that was one of the "random resets" you talk about, then you have a power issue.

calibanorg

@dc42 @NAK_3D this morning i started a 15hr print and it stopped in the afternoon. When i checked the M122 (see below) it did a reset and cause: power up. Also i had the checksum error (see picture below) on the screen.

It looks like i have the same issue as @NAK_3D?

@dc42 in regards of the power up cause -> is this an issue of not enough power, powerloss? shortage?

M122
=== Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 2.04 running on Duet WiFi 1.02 or later Board ID: 08DGM-9T6BU-FG3S4-6JTD8-3S86Q-1BR3F Used output buffers: 3 of 24 (9 max) === RTOS === Static ram: 25680 Dynamic ram: 92748 of which 416 recycled Exception stack ram used: 320 Never used ram: 11908 Tasks: NETWORK(ready,572) HEAT(blocked,1232) MAIN(running,3752) IDLE(ready,200) Owned mutexes: === Platform === Last reset 00:27:54 ago, cause: power up Last software reset at 2019-11-17 08:04, reason: User, spinning module GCodes, available RAM 11736 bytes (slot 1) Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 12.0MBytes/sec SD card longest block write time: 0.0ms, max retries 0 MCU temperature: min 29.8, current 30.2, max 34.5 Supply voltage: min 24.0, current 24.1, max 24.2, 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 Date/time: 2019-11-19 16:52:39 Cache data hit count 4294967295 Slowest loop: 6.04ms; fastest: 0.06ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Move === Hiccups: 0, FreeDm: 160, MinFreeDm: 160, MaxWait: 0ms Bed compensation in use: none, comp offset 0.000 === DDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 Stack records: 1 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: 208.25ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0) HTTP sessions: 1 of 8 - WiFi - Network state is running WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.23 WiFi MAC address cc:50:e3:4a:dc:00 WiFi Vcc 3.34, reset reason Turned on by main processor WiFi flash size 4194304, free heap 22912 WiFi IP address 10.10.2.21 WiFi signal strength -46dBm, reconnections 0, sleep mode modem Socket states: 0 0 0 0 0 0 0 0

calibanorg

not sure if related i just did a test print and got following error

Error: G10: Attempt to set/report offsets and temperatures for non-existent tool: 1
Error: G10: Attempt to set/report offsets and temperatures for non-existent tool: 2

droftarts

@calibanorg That sounds more like SD card corruption, which may cause the checksum errors and random power cycles. Have you tried a new card? Are you using the SD card socket on the Duet or the PanelDue?

Ian

NAK_3D

This post is deleted!

NAK_3D

@dc42 said in Checksum errors:

@NAK_3D said in Checksum errors:

@dc42 That's unfortunate... This means there is still an unknown issue causing the duet to randomly reset..

The M122 report you posted earlier shows that the last reset before you ran that was caused by power up. If that was one of the "random resets" you talk about, then you have a power issue.

That was just an example of the checksum error.. that log was not from a reset condition.

NAK_3D

@droftarts said in Checksum errors:

That sounds more like SD card corruption, which may cause the checksum errors and random power cycles. Have you tried a new card? Are you using the SD card socket on the Duet or the PanelDue?

Ian

I'm printing off of the original SD card provided in the Duet (not from Panel Due) and I've only loaded approx 6 files to it. If its a corrupted SD I'd say it must be defective as its barely used..

droftarts

@NAK_3D said in Checksum errors:

@droftarts said in Checksum errors:

That sounds more like SD card corruption, which may cause the checksum errors and random power cycles. Have you tried a new card? Are you using the SD card socket on the Duet or the PanelDue?

Ian

I'm printing off of the original SD card provided in the Duet (not from Panel Due) and I've only loaded approx 6 files to it. If its a corrupted SD I'd say it must be defective as its barely used..

My reply about SD card corruption was in answer to @calibanorg, not you. I've edited my post to make that clear. Ideally people should start a new thread for their problem to avoid confusion, but it did sound similar. But then you weren't the OP, either.

@NAK_3D said in Checksum errors:

That was just an example of the checksum error.. that log was not from a reset condition.

@NAK_3D We really need to see an M122 after a reset event.
A couple of other things that are worth trying to isolate this:
Are you uploading gcode files to the Duet while printing? This can cause corruption.
Have you tried removing the SD card from the printer, put it in your PC, and copying a gcode file onto it directly? Does that create checksum errors?
Have you tried running gcode files in simulation mode, and see if they produce checksum errors?
Have you checked the things @dc42 suggested:

My best guesses are that the PanelDue cable is running close to a source of noise, such as a stepper motor cable, or that the cable it too long or too thin to pass the data without risk of corruption (resistance per conductor must be 0.1 ohm or less), or a bad crimp connection.

Is your PanelDue connected by the ribbon cable or the 4-wire cable? As you're not using the SD card, use the 4-wire cable, it's more robust. Make sure it's routed away from potential sources of noise.

Not related to your problem, but delete or comment out the M587 line from your config.g. As it says in the gcode dictionary:

This command must not be used in the config.g file
Important! Do not use M587 within config.g. As well as being a security hazard, writing the access point parameters to WiFi chip every time you start the Duet may eventually wear out the flash memory. Also, the wifi module does not get enabled until the end of running config.g. It is better to use a macro to send M587 (source: https://forum.duet3d.com/post/42798)

Ian

calibanorg

@droftarts i'm using the Duet SD card socket. I guess i will replace the SD card to make sure this can be ruled out. I checked yesterday the cables and rerouted them so the noise should be less. I started the same print this morning and so far it still printing since then. Another 3h 40min to go so wish me luck i don't have an issue here.

calibanorg

@droftarts said in Checksum errors:

My reply about SD card corruption was in answer to @calibanorg, not you. I've edited my post to make that clear. Ideally people should start a new thread for their problem to avoid confusion, but it did sound similar. But then you weren't the OP, either.

@NAK_3D my apologize that i hijacked your post

@droftarts i will open a new post next time -> Thanks for help anyway.