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

@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

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