Posts made by cdoe

I went over electronics compartment last weekend and couldn't find anything obvious like a loose wire pressing reset button or some shorting on the button itself. Electronics are cooled by fans which are always on which may be enough - but I'm not sure on that one

Hi,
I'm running Duet 3 mini with SHT36V3Pro toolboard on voron and lately started to have random reboots.
This is more pronounced after/when printing ABS with bed at around 110C

M122 output always shows that reboot was due to reset button being pushed, but that's not always the case:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.5.4 (2024-11-24 10:44:24) running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: N5P25-DQ6KL-K65J0-409NG-11X1Z-ZBMLJ
Used output buffers: 12 of 40 (28 max)
=== RTOS ===
Static ram: 103496
Dynamic ram: 121908 of which 0 recycled
Never used RAM 13492, free system stack 196 words
Tasks: NETWORK(2,nWait 7,8.6%,228) HEAT(3,nWait 6,0.0%,339) Move(4,nWait 6,0.0%,355) CanReceiv(6,nWait 1,0.1%,798) CanSender(5,nWait 7,0.0%,336) CanClock(7,delaying,0.0%,348) TMC(4,nWait 6,1.5%,110) MAIN(1,running,87.7%,665) IDLE(0,ready,1.3%,29) AIN(4,delaying,0.8%,264), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:00:19 ago, cause: reset button
Last software reset at 2025-04-20 17:55, reason: User, Gcodes spinning, available RAM 12276, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU revision 3, ADC conversions started 15220, completed 15219, timed out 0, errs 0
MCU temperature: min 39.1, current 41.7, max 41.7
Supply voltage: min 23.9, current 23.9, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/18, heap memory allocated/used/recyclable 2048/356/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, read errors 0, write errors 1, ifcnt 32, reads 1742, writes 10, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, SG min 0, read errors 0, write errors 1, ifcnt 38, reads 1740, writes 12, timeouts 0, DMA errors 0, CC errors 0
Driver 2: standstill, SG min 0, read errors 0, write errors 1, ifcnt 38, reads 1739, writes 12, timeouts 0, DMA errors 0, CC errors 0
Driver 3: standstill, SG min 0, read errors 0, write errors 1, ifcnt 38, reads 1739, writes 12, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, SG min 0, read errors 0, write errors 1, ifcnt 38, reads 1740, writes 12, timeouts 0, DMA errors 0, CC errors 0
Driver 5: standstill, SG min 0, read errors 0, write errors 1, ifcnt 38, reads 1739, writes 12, timeouts 0, DMA errors 0, CC errors 0
Driver 6: standstill, SG min 0, read errors 0, write errors 1, ifcnt 38, reads 1739, writes 12, timeouts 0, DMA errors 0, CC errors 0
Date/time: 2025-04-24 18:42:12
Cache data hit count 36173130
Slowest loop: 4.69ms; fastest: 0.16ms
=== Storage ===
Free file entries: 20
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 2.1ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: mesh, 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 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, null
HTTP is idle 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
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000000
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 179, received 439, lost 0, errs 1, boc 0
Longest wait 2ms for reply type 6031, peak Tx sync delay 274, free buffers 26 (min 25), ts 98/97/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 5.52ms; fastest: 0.00ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.2.0
MAC address c4:5b:be:ce:92:42
Module reset reason: Power up, Vcc 3.42, flash size 2097152, free heap 42668
WiFi IP address 192.168.77.90
Signal strength -56dBm, channel 13, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

M122 output for toolboard:

M122 B124
Diagnostics for board 124:
Duet SHT36MAX3 firmware version 3.5.4 (2024-11-27 23:20:57)
Bootloader ID: 
All averaging filters OK
Never used RAM 218116, free system stack 436 words
Tasks: Move(3,nWait 7,0.0%,132) HEAT(2,nWait 6,0.2%,130) CanAsync(5,nWait 4,0.0%,64) CanRecv(3,nWait 1,0.0%,364) CanClock(5,nWait 1,0.0%,336) ACCEL(3,nWait 6,0.0%,52) TMC(2,delaying,2.4%,54) MAIN(1,running,80.5%,430) IDLE(0,ready,0.1%,26) USBD(2,blocked,0.0%,150) AIN(2,delaying,16.8%,202), total 100.0%
Owned mutexes:
Last reset 00:02:53 ago, cause: power up or brownout
Last software reset data not available
Driver 0: pos 0, 691.0 steps/mm, standstill, read errors 0, write errors 0, ifcnt 15, reads 20521, writes 15, timeouts 0, DMA errors 0, CC errors 0, steps req 0 done 0
Moves scheduled 0, completed 0, in progress 0, hiccups 0, segs 0, step errors 0, maxLate 0 maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0, ebfmin 0.00 max 0.00
Peak sync jitter -5/11, peak Rx sync delay 355, resyncs 1/1, no timer interrupt scheduled
MCU temperature: min 56.6C, current 56.6C, max 61.8C
Last sensors broadcast 0x00000006 found 2 18 ticks ago, 0 ordering errs, loop time 0
CAN messages queued 5505, send timeouts 50, received 1044, lost 0, errs 0, boc 4, free buffers 38, min 38, error reg 0
Last cancelled message type 4514 dest 127
dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0
Accelerometer: LIS2DW, status: 00
Inductive sensor: raw value 268435455, frequency 20.00MHz, current setting 13, amplitude error
I2C bus errors 0, naks 0, contentions 0, other errors 0

Is there a way to capture some logs/telemetry to see what might be causing the issue?
Thank you

@gloomyandy thanks for the update. Appreciate tracking this one down

@gloomyandy @T3P3Tony Thanks for ideas and suggestions. Now it makes sense - i'll rework daemon.g to only change colour if needed rather than just blindly doing so

@T3P3Tony I did and pauses went away, so i strongly suspect it's M150 and movement buffer interaction
Just in case, here's how leds are configured (wired on sht36 toolboard):

M950 E0 C"124.rgbled" T1

After updating my daemon.g to

while true
  ;#################### Electronics Bay Fan ###########################
  if move.axes[0].homed || move.axes[1].homed || move.axes[2].homed         ; check whether X, Y or Z drivers are active
    M106 P2 S0.85 H-1                                                       ; fan 2 runs at 80%
    M106 P3 S0.85 H-1                                                       ; fan 3 runs at 80%
  else
    M106 P2 S0                                                              ; if not, turn off the electronics bay fan 2
    M106 P3 S0                                                              ; if not, turn off the electronics bay fan 3

  ; Toolhead led based on temp
  ; unfortunately seems like this will pause move
  ; heater 0 - bed
  ; heater 1 - hotend
  if heat.heaters[1].current > global.hotSenseTemp
    M150 E0 R222 U95 B188 P96 S1 F0
  elif heat.heaters[1].current > global.warmSenseTemp
    M150 E0 R222 U201 B95 P96 S1 F0
  else
    M150 E0 R96 U223 B223 P96 S1 F0
  G4 S5 ; wait 5 seconds before looping

I'm still observing a slight pause (now every ~5 seconds).
Looking through Changelog M150 and its interaction with movement are mentioned couple of times. In particular "M150 commands are now queued to sync them with movement commands" (feature in 3.2) - and there were couple of fixes later on around that functionality is it possible that this is causing a pause?
Is there a way to check if movement buffer / queue is empty or not when that M150 in my daemon.g is executed?

@T3P3Tony Thanks for the tip.Will try this out.
I think this can be marked as solved (not sure how to do that).

@infiniteloop thank you - the issue is with daemon.g
in particular with calling macros which change led colour
Here's indicator_warm content:

; Set led on stealthburner to warm colour
M150 E0 R222 U201 B95 P96 S1 F0

@infiniteloop
I do:

;#################### Electronics Bay Fan ###########################
if move.axes[0].homed || move.axes[1].homed || move.axes[2].homed         ; check whether X, Y or Z drivers are active
  M106 P2 S0.85 H-1                                                       ; fan 2 runs at 80%
  M106 P3 S0.85 H-1                                                       ; fan 3 runs at 80%
else
  M106 P2 S0                                                              ; if not, turn off the electronics bay fan 2
  M106 P3 S0                                                              ; if not, turn off the electronics bay fan 3

; heater 0 - bed
; heater 1 - hotend
if heat.heaters[1].current > global.hotSenseTemp
  M98 P"/macros/led/indicator_hot"
elif heat.heaters[1].current > global.warmSenseTemp
  M98 P"/macros/led/indicator_warm"
else
  M98 P"/macros/led/indicator_cold"

@resam I don't - setup is running in standalone mode. But that gave me an idea. I think next step would be to check if there's an issue with toolboard - maybe some sort of issue with canbus throughput?
Reslicing with cura didn't help though - still having this periodic pauses

@Phaedrux Thanks for helping me figure this out..
There's no commonality i can figure out, tbh. It's also visible (in form of blobs) in vase mode as well - which from what i understand shouldn't have any pauses or layer changes at all?
Issue occurs even when heightmap/bed compensation is disabled.

I'm trying to "port" my profile to cura to see if this is a slicer issue.

Hi guys,
I'm running RRF v3.5.4 on Voron 2.4 300 mm with duet 5 mini and SHTv3 toolboard. Xol toolhead with orbiter v2 extruder. Prusa Slicer is used to slice models.
I've noticed that printing staggers every 12 seconds or so - first thought was this was to let layer cool, but that was also visible on printing infill on large-ish prints as well.
SD card was changed and that had no effect (both old and new were able to produce 40mb/s reads and 10mb/s writes.
I've tried bumping up acceleration but that seems to have no effect as well. My bed compensation is tapered (over 6mm), however, pauses were also visible on layers higher than 6mm, suggesting that this is probably (don't take my word on it) not related to low acceleration for Z axis.
Attached are M122/M122 B124 outputs and my config along with gcode file.
Where/what can I look at next?
config.g.txt
M122B124.txt
M122.txt
v13_top_panel.gcode

I've set orbiter filament sensor v2 set up recently.
It has 2 outputs (FS for sensing if filament is present) and FTU (outputs if filament is tangled or filament unload button is pressed).
The set up is slightly more elaborate than just a sensor since both outputs have 2 functions and logic is not straightforward as well. FS output works as expected as in changing state when filament is present or runs out, FTU output only changes state if filament is already present.

I'm running FlySHT36v3 Max toolboard with 124 being board CAN address and connected FS to io1.in to FTU to io2.in inputs (taking 5v and ground from same 5 pin connector) and had to use triggers for things to work.
This is a section in config.g

; Filament Sensor
M950 J1 C"^124.io1.in"                       ; define logical input for filament auto load
M581 P1 T3 S1 R0                             ; define trigger for filament auto load triggers trigger3.g
M581 P1 T2 S0 R0                             ; define trigger for filament sensing triggers trigger2.g
M950 J2 C"^124.io2.in"                       ; define logical input for filament unload
M581 P2 T4 S1 R0                             ; define trigger for filament auto unload triggers trigger4.g

trigger2.g:

; trigger2.g
if state.status == "processing"
    M300 S2000 P100                                     ; play beep sound
    M291 P"Ran out of filament while printing" S0 T3    ; display message
    M25
elif state.status == "pausing" || state.status == "paused"
    M291 P"Retriggered filament sensor during pause" ; display message
else
    M300 S2000 P100                     ; play beep sound
    M291 P"Ran out of filament" S0 T3   ; display message

trigger3.g:

; trigger3.g
M98 P"0:/macros/filament-load"

trigger4.g:

; trigger4.g
if state.status = "processing"
    M300 S2000 P100                                                     ; play beep sound
    M291 P"Filament is stuck or filament unload button pressed" S0 T3   ; display message
    M25
else
    M98 P"0:/macros/filament-unload"

filament-load and filament-unload macros will need to be created and populated for this to work but that should be more or less straightforward and more printer-specific than general set up
Hope that helps

Thanks again, updating from duet board worked. Digitizer doesn't work though but that's a separate issue

Thanks I'll try that. Didn't realise it can be done while paneldue has no firmware at all...

I've been able to flash 3.4.1 with bossac. GUI version is windows/macos version only which i don't have, so it seems that my paneldue is now just a bunch of useless hardware

bossac says “flash command failed”

Hi,
I've tried re-flashing 3.5.0 rc 8 firmware over usb and followed process described in documentation.
PanelDue had 3.4.1 firmware previously. However, it was in storage and was stuck in calibration prompt - i.e. a dot on top of the screen was visible and there was a prompt to touch it, but that was not progressing as if touch was not detected.
Here are some outputs from bossac:

$ ./bossac --port=/dev/ttyACM0 -i
Atmel SMART device 0x289b09e0 found
Device       : ATSAM4S4
Chip ID      : 289b09e0
Version      : v1.13 RC2 Feb 20 2013 13:25:17
Address      : 4194304
Pages        : 512
Page Size    : 512 bytes
Total Size   : 256KB
Planes       : 1
Lock Regions : 16
Locked       : none
Security     : false
Boot Flash   : false

output when flashing with 3.5.0:

./bossac --port=/dev/ttyACM0 -e -w -v -b ~/Downloads/PanelDueFirmware-3.5.0-rc8-7.0i.bin 
Atmel SMART device 0x289b09e0 found
Erase flash
done in 0.001 seconds

Write 176720 bytes to flash (346 pages)
[                              ] 0% (0/346 pages)
Flash command failed

Similar output when trying with version 3.4.1:

./bossac --port=/dev/ttyACM0 -e -w -v -b ~/Downloads/PanelDueFirmware-3.4.1/PanelDueFirmware-3.4.1-7.0i.bin
Atmel SMART device 0x289b09e0 found
Erase flash
done in 0.001 seconds

Write 170916 bytes to flash (334 pages)
[                              ] 0% (0/334 pages)
Flash command failed

Are there any troubleshooting steps I could try to figure out why flashing no longer works and if hardware is in working condition?
There are no torn wires or connector strips on visual inspection

Only got my hands to it now. Sadly 140R resistor burned out so badly that there are no traces left to put replacement component. LEDs are fine though. Has anyone tried using silver tracing pen to re-draw traces? Will it work properly with moving part like effector?

Thank you.