VIN under-voltage event
-
Hi, recently near the end of printing, print had stopped with VIN under-voltage event.
But interestingly, printer has connected to uninterrupted power supply.
What may be the cause of this problem?
I am using enclosed Voron 2.4
Thank you
M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.6 (2023-07-21 14:11:38) running on Duet 3 MB6HC v1.01 (standalone mode)
Board ID: 08DJM-9P63L-DJ3S0-7J1FA-3S46M-KVK78
Used output buffers: 1 of 40 (24 max)
=== RTOS ===
Static ram: 153252
Dynamic ram: 98000 of which 140 recycled
Never used RAM 95704, free system stack 129 words
Tasks: NETWORK(ready,35.2%,172) ETHERNET(notifyWait,1.4%,311) HEAT(notifyWait,0.4%,321) Move(notifyWait,5.4%,214) CanReceiv(notifyWait,0.4%,771) CanSender(notifyWait,0.0%,327) CanClock(delaying,0.1%,347) TMC(notifyWait,23.1%,56) MAIN(running,34.0%,947) IDLE(ready,0.1%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 23:30:59 ago, cause: software
Last software reset at 2024-04-18 13:59, reason: User, GCodes spinning, available RAM 99496, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Step timer max interval 822
MCU temperature: min 38.1, current 44.2, max 45.4
Supply voltage: min 7.7, current 24.0, max 24.2, under voltage events: 1, over voltage events: 0, power good: yes
12V rail voltage: min 11.3, current 12.1, max 12.4, under voltage events: 0
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/1582/1582, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, mspos 504, reads 49123, writes 98 timeouts 0
Driver 1: standstill, SG min 0, mspos 232, reads 49123, writes 98 timeouts 0
Driver 2: standstill, SG min 0, mspos 584, reads 49123, writes 98 timeouts 0
Driver 3: standstill, SG min 0, mspos 680, reads 49123, writes 98 timeouts 0
Driver 4: standstill, SG min 0, mspos 88, reads 49124, writes 98 timeouts 0
Driver 5: standstill, SG min 0, mspos 808, reads 49124, writes 98 timeouts 0
Date/time: 2024-04-19 13:30:40
Slowest loop: 220.23ms; fastest: 0.04ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 4.0ms, write time 60.1ms, max retries 0
=== Move ===
DMs created 125, segments created 30, maxWait 27756073ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 24537, completed 24537, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 5], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is ready with "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 841081, received 1354594, lost 0, boc 0
Longest wait 1ms for reply type 6042, peak Tx sync delay 392, free buffers 50 (min 49), ts 423300/423299/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 214.95ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
= Ethernet =
State: active
Error counts: 0 0 0 1 0 0
Socket states: 5 2 2 2 2 2 0 2
=== Multicast handler ===
Responder is inactive, messages received 0, responses 0 -
@aytact Were you able to capture an M122 report? While your may be running from a UPS, your PSU may be failing. Or there was a momentary power loss, and it takes time for the UPS to kick in. Hard to say without more info.
Ian
-
When I used to run with a UPS I would get those when he UPS did a self test and the switch over to battery and back would trigger an undervoltage. I had to stop using that UPS as there was no way to schedule or stop it's self tests.
