Spinning Module Gocodes, Duet 0.8.5, looking for some input

timothyz · 10 Sept 2020, 13:56

Hi,
There is a printer at my work running an older Duet 0.8.5 and I updated it to the latest firmware the other day while rebuilding it to improve it's quality. I am running the latest version of DWC and everything seems to be working well, except for it seems to be stopping almost 12 hours into prints pretty reliably and I am struggling to find the cause. Overall, it works wonderfully until this point.

Here are some setup attributes so you guys don't have to ask:

Freshly full formatted SD (but not brand new) inserted directly
Power supply 24V
corexy - 144 steps per mm (using one stage of belted reduction)
using two extruders with a mix ratio of 1:0.995 (one just to feed the material)

Any input would be greatly appreciated. See below for M122.

m122
=== Diagnostics ===
RepRapFirmware for Duet version 1.26.1 running on Duet 0.85
Used output buffers: 3 of 16 (11 max)
=== System ===
Static ram: 44212
Dynamic ram: 42716 of which 3184 recycled
Stack ram used: 136 current, 3724 maximum
Never used ram: 4468
=== Platform ===
Last reset 10:46:28 ago, cause: power up
Last software reset at 2020-09-09 10:53, reason: User, spinning module GCodes, available RAM 4468 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0xffffffff
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 21.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 33.1, current 33.2, max 33.6
Date/time: 2020-09-10 08:18:59
Slowest loop: 3.19ms; fastest: 0.10ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 100, MinFreeDm: 100, 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, chamberHeaters = -1 -1
=== 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 ===
Free connections: 15 of 16
Free transactions: 23 of 24
Locked: 0, state: 4, listening: 20071bf4, 0, 0

JoergS5 · 9 Oct 2020, 14:49

@timothyz said in Spinning Module Gocodes, Duet 0.8.5, looking for some input:

Software reset code 0x0003

I cannot see anything wrong with the M122.
Do you print the same object and can identify a specific layer where the error occurs? Maybe an error in the code producing the problem.
Or is the daytime the same, being some currency peak in the house? Reset code 0x0003 means sometimes problem with heater or fan, is there something unusual happening in the DWC which you can identify? Sometimes it was also an error reading a file.
Maybe something like https://github.com/Duet3D/RepRapFirmware/issues/209, do you make something at this time like uploading a file?

What is the effect of the error, a reboot or some error message?

PDBeal created this issue 24 Sept 2018, 23:32 in Duet3D/RepRapFirmware

closed Duet 0.8.5 crashed on file upload while printing #209

timothyz · 10 Sept 2020, 15:15

Thanks for the response!

The effect of this error is a reboot of the controller loosing the print position. It has happened twice in a row, same print sliced differently, so completely different gcode. It happens about 12 hours into the print repeatably (but not at a specific location). No signs of heater or fan issues as well. If it was a heater fault, it would stop due to the heater fault.

No error message, but when I check the printer in the morning, it just is running normally, but with the print head fused to where it stopped printing.

Thanks,
Tim

JoergS5 · 10 Sept 2020, 16:09

@timothyz it will probably be useful to run it in debug mode (M111 and log messages). I never did it myself, so someone may tell you how to do it so the logs survive the reboot.

Phaedrux · 10 Sept 2020, 18:11

You may want to try a new SD card.

What version specifically of DWC are you using? You may want to stick to 2.0.7 or 1.22.6 that are included alongside the 2.05.1/1.26.1 firmware release.

Also, post your config.g

dc42 · 9 Oct 2020, 18:31

That software reset code indicates that the board was reset due to receiving M999 or emergency stop or a firmware upgrade. It happened yesterday.

The last reset was caused by power up today.

If this issue happens again, run M122 without resetting the board again.

timothyz · 10 Sept 2020, 18:54

@dc42 That's the thing, I did not intentionally reset the board before sending the m122, that was how it was when I walked up to the machine in the morning. The power up was immediately following the reset if I read the timing correctly.

This is one of those silly Fusion3 F400s, I will disconnect the paneldue and reset button connected to the expansion connector and try again, also will see if I can scrounge up a brand new sd card.

Anything else I can do to debug? Doesn't M111 need a PC connected via usb to receive the debug messages?

-Tim

timothyz · 10 Sept 2020, 18:57

@Phaedrux I am running 3.1.1 and it seems to be working very well (I was having issues with the much older version of DWC).

Do you think that the newer version of DWC could cause this even with no client connected?

-Tim

Phaedrux · 10 Sept 2020, 18:57

Has any wiring for the PanelDue or reset button been moved near motor wiring during your rebuild?

Is the power supply malfunctioning?

debug logs would go out over USB
https://duet3d.dozuki.com/Wiki/Gcode#Section_M111_Set_Debug_Level