Posts made by M-Pixel

Error: VSSA fault, check thermistor wiring
4/12/2021, 11:07:17 AM 	M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.3beta2+1 (2021-04-11 10:20:02) running on Duet 3 Mini5plus Ethernet (SBC mode)
Board ID: PG824-LA67A-G65J0-40TFS-L3D0Z-ZGG9A
Used output buffers: 1 of 40 (12 max)
=== RTOS ===
Static ram: 100072
Dynamic ram: 92492 of which 0 recycled
Never used RAM 48284, free system stack 126 words
Tasks: Linux(ready,139) HEAT(delaying,231) CanReceiv(notifyWait,944) CanSender(notifyWait,357) CanClock(delaying,332) TMC(notifyWait,99) MAIN(running,599) IDLE(ready,20) AIN(notifyWait,260)
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 01:46:38 ago, cause: power up
Last software reset at 2021-04-11 19:13, reason: User, none spinning, available RAM 48284, slot 0
Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task Linu Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
MCU revision 3, ADC conversions started 7620048, completed 7620047, timed out 0, errs 1
tnd=0 rnd=0 wrd=0 wtd=1 war=1
Supply voltage: min 0.0, current 0.1, max 24.3, under voltage events: 1, over voltage events: 0, power good: no
Heap OK, handles allocated/used 99/1, heap memory allocated/used/recyclable 2048/12/0, gc cycles 0
Driver 0: position 16418, ok, SG min/max 0/72, read errors 0, write errors 0, ifcnt 15, reads 20007, writes 15, timeouts 1, DMA errors 0, failedOp 0x01
Driver 1: position 8692, ok, SG min/max 0/54, read errors 0, write errors 0, ifcnt 15, reads 19999, writes 15, timeouts 9, DMA errors 0, failedOp 0x6a
Driver 2: position 120, standstill, SG min/max 0/352, read errors 0, write errors 0, ifcnt 15, reads 20008, writes 15, timeouts 0, DMA errors 0
Driver 3: position 0, ok, SG min/max 0/34, read errors 0, write errors 0, ifcnt 13, reads 20001, writes 13, timeouts 9, DMA errors 0, failedOp 0x6a
Driver 4: position 0, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 11, reads 20012, writes 11, timeouts 0, DMA errors 0
Driver 5: position 0, assumed not present
Driver 6: position 0, assumed not present
Date/time: 2021-04-12 19:07:16
Cache data hit count 4294967295
Slowest loop: 108.23ms; fastest: 0.06ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 0.0MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, maxWait 5180087ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 623, completed moves 623, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File* is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue* is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== CAN ===
Messages queued 57504, send timeouts 57501, received 0, lost 0, longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 17 (min 17)
Last cancelled message type 30 dest 127
=== SBC interface ===
State: 4, failed transfers: 0
Last transfer: 3ms ago
RX/TX seq numbers: 30312/30312
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x118dc
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.2.2
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 5.95
Maximum length of RX/TX data transfers: 3220/1640
File /opt/dsf/sd/gcodes/hdd-rack-frame large left.gcode is selected, paused

In the meantime, it would be fantastic if it could pause the print instead of marking it as completed after one of these events, so that it's easier to resume. Or at the very least, it would be useful if it didn't cause the axes to lose their "homed" status.

+1 over here. Duet 3 Mini 5+ in SBC mode; SBC is powered by a step-down which is in turn powered by the same 48V supply that powers the Duet, so it's not possible for the Duet to lose power without the SBC also losing power. Occurrence seems completely random - I haven't observed a single common variable between the occurrences (apart from the fact that they all occur on the same printer, of course).

I've been contending with the issue by figuring out approximately where the print stopped, then manually editing the gcode file to pick up where it left off.

I'm loading the April 7th firmware now, and will post diagnostics if the issue occurs again.