Checksum errors

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.