Information for DC42: V3 Beta12 crashed mid print.

Danal

Crash mid-print for no obvious reason. Just FYI. Printing a job I'd printed before.

CoreXY. Multi-Tool. Using tool0 at the time, probably the 10th swap.

Board: Duet 3 MB6HC (MB6HC)
DSF Version: 1.1.0.5
Firmware: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 3.0beta12 (2019-11-02b1)

M122 B0
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 version 3.0beta12 running on Duet 3 MB6HC
Board ID: 08DGM-9T66A-G63SJ-6J1DD-3SD6K-1V0MA
Used output buffers: 1 of 32 (9 max)
=== RTOS ===
Static ram: 122240
Dynamic ram: 173288 of which 0 recycled
Exception stack ram used: 568
Never used ram: 97120
Tasks: NETWORK(ready,2044) HEAT(blocked,1212) CanReceiv(suspended,3420) CanSender(suspended,1400) CanClock(blocked,1428) TMC(blocked,80) MAIN(running,4212) IDLE(ready,200)
Owned mutexes:
=== Platform ===
Last reset 00:35:33 ago, cause: software
Last software reset at 2019-11-02 19:07, reason: Unknown, spinning module Platform, available RAM 97160 bytes (slot 0)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 45.9, current 46.4, max 46.9
Supply voltage: min 24.1, current 24.5, max 24.7, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0
Driver 0: standstill, reads 40765, writes 43 timeouts 0, SG min/max 0/1023
Driver 1: standstill, reads 40766, writes 43 timeouts 0, SG min/max 0/1023
Driver 2: standstill, reads 40771, writes 39 timeouts 0, SG min/max 0/92
Driver 3: standstill, reads 40772, writes 39 timeouts 0, SG min/max 0/1023
Driver 4: standstill, reads 40773, writes 39 timeouts 0, SG min/max 0/1023
Driver 5: standstill, reads 40774, writes 39 timeouts 0, SG min/max 0/1023
Date/time: 2019-11-02 19:42:57
Slowest loop: 86.93ms; fastest: 0.25ms
=== Move ===
Hiccups: 5, FreeDm: 375, MinFreeDm: 335, MaxWait: 242505ms
Bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 0, completed moves: 21, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
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 assembling a command in state(s) 0
daemon* is ready with "M122 B0" in state(s) 0
queue is idle in state(s) 0
lcd is idle in state(s) 0
spi is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 1.52ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 0 of 8
- Ethernet -
State: 0
Socket states: 0 0 0 0 0 0 0 0
=== CAN ===
Messages sent 20703, longest wait 78ms for type 6024
=== Linux interface ===
State: 0, failed transfers: 4
Last transfer: 26ms ago
RX/TX seq numbers: 3611/249
SPI underruns 9, overruns 8
Number of disconnects: 1
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v1.1.0.5
Code buffer space: 4096
Configured SPI speed: 2000000 Hz
Full transfers per second: 30.93

dc42

Thanks. Did you run that M122 35 minutes after it started printing, or 35 minutes after it stopped?

Danal

35 min after it stopped.

dc42

Thanks. I can tell that the reset was commanded by DSF, but not why. Is there anything in the DSF log?

Danal

How would I access the DSF log?

gtj0

@Danal said in Information for DC42: V3 Beta12 crashed mid print.:

How would I access the DSF log?

On the Pi... journalctl -u duetcontrolserver

You can leave the log running with... journalctl -fu duetcontrolserver

chrishamm

@Danal Please run 'sudo journalctl -u duetcontrolserver', press G and type '?has been reset' followed by RETURN. That way you can jump to the log where the last RRF reset was reported. If it isn't the part where the corresponding reset occurred, press ? and RETURN to jump to a previous occurence. It would probably help to see what was being executed when the reset occurred.

Danal

Fantastic, thank you. Will find the correct spot and report it here, later this evening (US time).

Danal

The oldest log I can find with journalctl -u duetcontrolserver is after that crash. If it occurs again, I'll immediately capture that log.