Duet v0.6 Hung Mid Build
What diagnostics information do I need to collect to help identify the route cause of a mid build hang?
This is the M122 report after a power cycle over USB as it is currently stuck at 'Connection lost, attempting to reconnect...' on DWC.
I will upload the latest firmware and attempt to restart a build shortly.
=== Diagnostics ===
RepRapFirmware for Duet version 1.23 running on Duet 0.6
Used output buffers: 1 of 16 (6 max)
=== System ===
Static ram: 44276
Dynamic ram: 42820 of which 3016 recycled
Stack ram used: 1080 current, 2660 maximum
Never used ram: 5532
=== Platform ===
Last reset 00:31:25 ago, cause: power up
Last software reset at 2019-05-01 17:45, reason: User, spinning module GCodes, available RAM 4608 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0400f000 BFAR 0xe000ed38 SP 0xffffffff
Error status: 1
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 28.8, current 54.9, max 55.3
Date/time: 2019-07-19 08:25:02
Slowest loop: 320.53ms; fastest: 0.09ms
I2C nak errors 24, send timeouts 0, receive timeouts 0, finishTimeouts 0
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 100, MinFreeDm: 100, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Stack records: 2 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 ready with "M122" in state(s) 0
aux is assembling a command 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: 16 of 16
Free transactions: 24 of 24
Locked: 0, state: 4, listening: 20071c18, 0, 0
Response for G28 is:
G0/G1: insufficient axes homed
It refused to do any moves, even after setting G92 X0 Y0 Z50.
Decided to go for the next level of fault diagnostics and opened the cover. Nothing obviously wrong. Powered up with the cover open and it worked fine...? I think it maybe a power supply issue. Didn't think to check voltage, but will do next time.
Stephen6309 last edited by
@doctrucker You need to add S2 to any movement commands before homing of the axis is done. The behaviour was changed in an earlier firmware.
@stephen6309 Thanks for your reply. I had already have that in my macros for homing, and hadn't changed firmware or the macros for some time. The G92 X0 Y0 Z50 overrides this behaviour forcing the machine to think it is homed and at (0,0,50), negating the need for any additional flags on G1 commands.
I think this is the power supply on it's last legs, but time will tell. The machine has run for 4 hours today without issue after I got it running.