Emergency stop being triggered on 3.5.1?
-
Hello. I have upgraded to 3.5.1 from 3.4.6, duet3 SBC mode, I have other small issues with the upgrade and continue doing debugging. I havbe just lauched 3 prints, all of them got interrupted, on screen I see the "reset machine" message and on console i see "Emergency stop, attemping to reconnect..."
Is like when pressing the software emergency stop buttom or like when I press the emergency stop buttom I installed (of course Im not doing that jajajaja)
Have anybody seen this behaviour? Any ideas what can be triggering this "problem"?
Thanks in advance
-
Can you share some more information?
M122 after a reset?
DCS logging? -
@Phaedrux Sure, I though M122 would not provide info after a reset.
This M122 info is super fresh, last print I tried as yesterday late, it reset again , this time after 6 hs of printing. M122:
M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5.1 (2024-04-19 14:30:55) running on Duet 3 MB6HC v1.01 (SBC mode)
Board ID: 08DJM-956L2-G43S8-6J9DL-3S46J-1S2QD
Used output buffers: 1 of 40 (17 max)
Error in macro line 4 while starting up: in file macro line 4: M307: value must be greater than zero
=== RTOS ===
Static ram: 155208
Dynamic ram: 89060 of which 208 recycled
Never used RAM 98660, free system stack 214 words
Tasks: SBC(2,ready,1.0%,415) HEAT(3,nWait 1,0.0%,348) Move(4,nWait 6,0.0%,278) CanReceiv(6,nWait 1,0.0%,940) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,336) TMC(4,nWait 6,9.3%,56) MAIN(2,running,88.7%,103) IDLE(0,ready,1.1%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:03:05 ago, cause: software
Last software reset at 2024-05-24 12:23, reason: User, Gcodes spinning, available RAM 96608, slot 0
Software reset code 0x6003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
MCU temperature: min 31.6, current 32.5, max 32.6
Supply voltage: min 24.5, current 24.5, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.2, under voltage events: 0
Heap OK, handles allocated/used 99/9, heap memory allocated/used/recyclable 2048/1372/1200, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min n/a, mspos 56, reads 40028, writes 16 timeouts 0
Driver 1: standstill, SG min n/a, mspos 392, reads 40028, writes 16 timeouts 0
Driver 2: standstill, SG min n/a, mspos 472, reads 40028, writes 16 timeouts 0
Driver 3: standstill, SG min n/a, mspos 840, reads 40029, writes 16 timeouts 0
Driver 4: standstill, SG min n/a, mspos 600, reads 40029, writes 16 timeouts 0
Driver 5: standstill, SG min n/a, mspos 8, reads 40029, writes 16 timeouts 0
Date/time: 2024-05-24 12:26:54
Slowest loop: 2.11ms; fastest: 0.08ms
=== Storage ===
Free file entries: 20
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
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 0 -1 -1 -1, ordering errs 0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null, 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 doing "G4 S2" in state(s) 0 0, running macro
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x80000003
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== Filament sensors ===
check 0 clear 1453738
Extruder 0 sensor: no data received
=== CAN ===
Messages queued 1606, received 0, lost 0, errs 874051, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 930/0/0
Tx timeouts 0,0,929,0,0,675 last cancelled message type 30 dest 127
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 13059/13059
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x253c0
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.1 (2024-04-19 16:20:35, 32-bit)
HTTP+Executed:Executing M122
Daemon:
Buffered code: G4 S2
Buffered codes: 32 bytes totalDoing macro daemon.g, started by system
Number of flush requests: 1
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 73.92, max time between full transfers: 219.3ms, max pin wait times: 89.9ms/24.3ms
Codes per second: 1.39
Maximum length of RX/TX data transfers: 7164/964 -
@Phaedrux here it is the responsible ; i fopund it on DCS logs:
May 24 02:37:10 PU-HT-7729 DuetControlServer[412]: [info] Starting macro file trigger8.g on channel Trigger
May 24 02:37:10 PU-HT-7729 DuetControlServer[412]: [warn] Trigger: Aborting orphaned macro file trigger8.g
May 24 02:37:10 PU-HT-7729 DuetControlServer[412]: [info] Aborted macro file trigger8.g
May 24 02:37:10 PU-HT-7729 DuetControlServer[412]: [warn] Daemon: Aborting orphaned macro file daemon.g
May 24 02:37:10 PU-HT-7729 DuetControlServer[412]: [info] Aborted macro file daemon.g
May 24 02:37:10 PU-HT-7729 DuetControlServer[412]: [warn] Daemon: Failed to find suitable stack level for flush request, falling back to current one
May 24 02:37:10 PU-HT-7729 DuetControlServer[412]: [warn] Emergency stop
May 24 02:37:10 PU-HT-7729 DuetControlServer[412]: [info] Aborted job file
May 24 02:37:10 PU-HT-7729 DuetControlServer[412]: [info] Cancelled printing file 0:/gcodes/lapida 2.gcode, print time was 6h 19mThat trigger has a M112 inside, it is switch installed outside printing area, I use it as a safe protection in case the motors loose steps to avoid crashing the printhead wioth the frame. But that switch was never hit. I can tell that because the printhead it is always inside printing area all the times this reset happened. And this configuration was working ok under 3.4.6 for at least 3 months. For some reason this switch in being "triggered" now with 3.5.1? I have to say that this switch is against recommendations, because it is a NO one (recommendation is to use NC)
So 1 posibility is that some noise is triggering the switch? Is there any chance the firmware is now more "sensitive? (someone wihtout electronic knowledge like me is the one asking this so I apologize is the question is really stup...) -
@Tinchus said in Emergency stop being triggered on 3.5.1?:
And this configuration was working ok under 3.4.6 for at least 3 months.
You could try rolling back to 3.4.6 to see if it is resolved there.
