@chrishamm
Thanks for verifying that that was a legitimate error/concern.
By default, does 3.5-rc.1 have large SPI transmissions right off the get-go but 3.4.6 does not? Perhaps that's why 3.4.6 was connecting but not faulting out like 3.5-rc.1?

After further testing:
For Bullseye (Deb 11), this works:

echo "options spidev bufsiz=8192" | sudo tee /etc/modprobe.d/spidev.conf 

For Bookworm (Deb 12), it does not.

Instead, I had to add:

spidev.bufsiz=8192

to the end of

/boot/cmdline.txt

After a reboot, when I:

cat /sys/module/spidev/parameters/bufsiz

I get 8192 and DWC now connects to the 6HC with 3.5-rc.1 in SBC mode.

I know we are probably an early adopter of Bookworm on the Pi w/Duet SBC so I'll report out anything else I run into. We'll be exercising our system heavily over the next few weeks.

Update: 10-23-2024

After tabling this issue for the past couple of months, we had to revisit it when we performed a major upgrade to our system that caused the issue to come back in full force to the point where our "automatic" workaround (basically, detection of the issue and software reset) wouldn't work anymore.

We replaced a lot of our 24V hardware with new versions of the same devices and went to different, dual 24V power supplies as well.

After the upgrade, we ran into the disconnection issue almost immediately when trying to run the equipment. We would get tens, almost hundreds of TfrRdy pin glitches in matter of seconds and the Pi/Duet would disconnect within 30s. We disconnected one 24V device at a time and ran some tests until we found that a brushed 24V/2A vacuum pump was putting out excessive noise on the 24V wire which was feeding back to the Pi/Duet. We put a capacitor across the pump's terminals and the TfrRdy pin glitches went to 0. We've been running for a couple of days now and we haven't had a single disconnection between the Pi and Duet.

It looks like our problem was excessive noise generated by poor component selection/sourcing. We tested the other pumps and devices on the system and we are seeing varying amounts of noise but none to the extent of that one particular vacuum pump.

I'll mark this one as solved!

@rkutun

Check:
/etc/xdg/lxsession/LXDE-pi/autostart
~/.config/wayfire.ini
~/.config/labwc/autostart

It all depends on which windowing system you are using, X11, Wayfire, or Labwc

Per the smartypants gurus here:
https://forum.duet3d.com/topic/37316/sbc-rpi4-bookworm-3-5-4-disable-chrome-startup?_=1746822121050

@chrishamm I spoke too soon, again...

So, after I RTFM (read the flipping manual, though it's not flipping), I found I was missing:

pip install dsf-python==3.6.0-b2

Soooooooooo... now I am at 3.6-beta4 for all boards, DSF, DWC, python bindings, etc...

Initial testing of our python app shows functionality.

@Falcounet That did it, thanks!
I had performed:
sudo apt install python3-dsf-python
but didn't include the snippet of that in my post. I guess it didn't matter since I had the older version of dsf-python installed. I do install that version via a script when setting up the Pi/Duet "out of the box". I'll update my script to use python3-dsf-python instead.

Thanks again!

@droftarts I can verify that the root cause is not reset button press, metallic debris, shorting of J32, condensation, or missing R30. Which leaves us ESD. We do have 24V brushed vacuum pumps on the system connected to out0 through out4. The odd thing is that the issue does not necessarily happen only when any one of the pumps is on. The issue has occurred with pumps being on or off.

So here is what we've tried in the past few weeks:

1. changed out both 3HC boards reporting the reset - no change in frequency from 1 per hour
2. changed out all 3 3HC boards - issue reduced in frequency to 1 per day
3. changed out 6HC board - issue greatly reduced in frequency to less than 1 per week

Now that the stoppages are so infrequent, the heat is off for the time being.

The next thing we are trying will be to get brushless vacuum pumps to replace the brushed units.

I'll table this issue for now and report back when the brushless pumps arrive.

I've gone a few days now and the multiple motion systems is working well. I'll call this one closed.

Thanks for the assist!

@droftarts @rero

Son of a #$@#!

Thanks gents! I'll start playing around with that example.

@droftarts Thanks for the update.

I tried the M997 S2 F"unstable" method but the update kept hanging while updating duetcontrolserver (around 89%). It did update the boards to 3.6.0-beta2, just not duetcontrolserver so I kept getting incompatible firmware messages. I had to use the "manual" update method to revert back to 3.5.3 and noticed the potential documentation issue. I'm going to run some more tests to see if the M997 issue is repeatable and I'll create a new thread under Beta firmware if it is. This is all on my testbench, so no harm, no foul.

@Leonard03
I don't have an answer for your original issue, but...

If you want to get your config.g to run with M98 without the error after startup, you can use the exists() function to check if the global already exists and use the result to skip defining the globals again.
https://docs.duet3d.com/User_manual/Reference/Gcode_meta_commands

So this,

global MMUmode = true					; enable or disable Multi Material Unit
 
if global.MMUmode = true
	global spoolJoin = false			; enable or disable the SpoolJoin feature of the Multi Material Unit
	global useCutter = true				; enable or disable the CUT feature of the Multi Material Unit
 
	global statusBondtech = 0
	global statusFinda = 0
	global currentSlot = {null, null}		; [0]last loaded slot, [1]last tool temperature
	global loadNext = false
	global pause = false
	global tcBlock = false
	global counter = {0,0,0}			; [0]extruder count, [1]fails, [2]total attempts
	
global errQueue = {null,null}

becomes this,

if !exists(global.MMUmode)
        global MMUmode = true

if global.MMUmode = true
        global spoolJoin = false			; enable or disable the SpoolJoin feature of the Multi Material Unit
        global useCutter = true				; enable or disable the CUT feature of the Multi Material Unit
         
        global statusBondtech = 0
        global statusFinda = 0
        global currentSlot = {null, null}		; [0]last loaded slot, [1]last tool temperature
        global loadNext = false
        global pause = false
        global tcBlock = false
        global counter = {0,0,0}			; [0]extruder count, [1]fails, [2]total attempts
        	
if !exists(global.errQueue)
        global errQueue = {null,null}

Then just change the true to false on line 2 to achieve the mode your desire between reboots.

You only need to check MMUmode because if MMUmode doesn't exist, then none of the globals can exist because MMUmode is used to create all of the other globals.

@rkutun

Check:
/etc/xdg/lxsession/LXDE-pi/autostart
~/.config/wayfire.ini
~/.config/labwc/autostart

It all depends on which windowing system you are using, X11, Wayfire, or Labwc

Per the smartypants gurus here:
https://forum.duet3d.com/topic/37316/sbc-rpi4-bookworm-3-5-4-disable-chrome-startup?_=1746822121050

@Leonard03
I don't have an answer for your original issue, but...

If you want to get your config.g to run with M98 without the error after startup, you can use the exists() function to check if the global already exists and use the result to skip defining the globals again.
https://docs.duet3d.com/User_manual/Reference/Gcode_meta_commands

So this,

global MMUmode = true					; enable or disable Multi Material Unit
 
if global.MMUmode = true
	global spoolJoin = false			; enable or disable the SpoolJoin feature of the Multi Material Unit
	global useCutter = true				; enable or disable the CUT feature of the Multi Material Unit
 
	global statusBondtech = 0
	global statusFinda = 0
	global currentSlot = {null, null}		; [0]last loaded slot, [1]last tool temperature
	global loadNext = false
	global pause = false
	global tcBlock = false
	global counter = {0,0,0}			; [0]extruder count, [1]fails, [2]total attempts
	
global errQueue = {null,null}

becomes this,

if !exists(global.MMUmode)
        global MMUmode = true

if global.MMUmode = true
        global spoolJoin = false			; enable or disable the SpoolJoin feature of the Multi Material Unit
        global useCutter = true				; enable or disable the CUT feature of the Multi Material Unit
         
        global statusBondtech = 0
        global statusFinda = 0
        global currentSlot = {null, null}		; [0]last loaded slot, [1]last tool temperature
        global loadNext = false
        global pause = false
        global tcBlock = false
        global counter = {0,0,0}			; [0]extruder count, [1]fails, [2]total attempts
        	
if !exists(global.errQueue)
        global errQueue = {null,null}

Then just change the true to false on line 2 to achieve the mode your desire between reboots.

You only need to check MMUmode because if MMUmode doesn't exist, then none of the globals can exist because MMUmode is used to create all of the other globals.

@chrishamm @T3P3Tony
Looking at CodeLogger did help me figure a few things, thanks for that push.

After some testing, the EXECUTED mode is what I need. I was only testing the PRE and POST interception modes previously.

I am having issues with the sample program https://github.com/Duet3D/dsf-python/blob/v3.6-dev/examples/custom_m_codes.py

My desire is to capture ALL error messages. Currently I am receiving just those that are generated by G/M/T codes.
I want to do exactly what the first comment in the sample program is stating, capture the whole G-code stream (no filters).

It crashes on the non-G/M/T codes being intercepted (the
cde = intercept_connection.receive_code()
call) and the reported exceptions are a bit Greek to me.

If I change the interception mode from EXECUTED to POST, I get the non-G/M/T intercepts but lose the G/M/T intercepts completely, though the program does not crash. So I don't know if what I am facing is an issue the sample script or the binding call itself.

Who might be the python guru for dealing with the dsf-python bindings? Is it @Falcounet ? I see AndyEveritt is pushing a lot of the contributions for dsf-python on git. Does he have a handle on here?

@chrishamm

I've created a function to subscribe to the OM. It sees some of the error messages but not all of them.

From the DWC Dashboard:

1. When I try to overtravel an axis, the message comes through to my app and the DWC console.
2. If I try to set a global variable that doesn't exist, the message does not come through to my app but it does show up in the DWC console.
3. If I try to run a macro that doesn't exist with M98, the message does not come through to my app but it does show up in the DWC console.

The terminal screen on the right shows just the 'message' portion of the OM patch once I receive the full OM on the first call, I didn't want to dump the whole patch on each patch iteration, just when a new message shows up.

The DWC console "sees" everything, my app only saw the target position error.

Does the source of the command call to the DSF matter (my app or DWC) in determining where the message goes?

@chrishamm

I'd like to revisit this question if that's ok. I've been playing around some more and I think I can articulate my issue a little better now. I have downloaded the source for the DWC and DSF. I've skimmed through it but I am certainly not fluent in it.

The messages I am looking to intercept are those that are generated by DSF while it is monitoring the system. These seem to be the "red" banner messages that are displayed at the bottom of the DWC and logged in the DWC console as they occur.

If I execute, via CommandConnection with async_exec = True, from a small app on the Raspberry Pi:
G90 G1 X-10 F1000 (my machine limit for X is 0 and 100)
DWC displays and logs Error: G1: target position outside machine limits
This message is not returned from the CommandConnection call that was used to send the G1 command (obviously since async is set to true). The response is blank which I interpret as the command was validly formatted and accepted by DSF.
If I set async_exec = False, I do get the error message as the result from the CommandConnection call.

So, if async is set to true, DWC gets the error message.
If async is false, my app gets the error message, DWC does not.

So how does the DWC achieve this "capturing" of errors when my app is sending commands in async_exec = true mode? This is what I want to achieve with my larger app; send commands asynchronously and receive error messages as they occur.

Can you point me to the DWC source code where this happens?
I just need a starting point from which I can follow the bread crumbs.

@droftarts I can verify that the root cause is not reset button press, metallic debris, shorting of J32, condensation, or missing R30. Which leaves us ESD. We do have 24V brushed vacuum pumps on the system connected to out0 through out4. The odd thing is that the issue does not necessarily happen only when any one of the pumps is on. The issue has occurred with pumps being on or off.

So here is what we've tried in the past few weeks:

1. changed out both 3HC boards reporting the reset - no change in frequency from 1 per hour
2. changed out all 3 3HC boards - issue reduced in frequency to 1 per day
3. changed out 6HC board - issue greatly reduced in frequency to less than 1 per week

Now that the stoppages are so infrequent, the heat is off for the time being.

The next thing we are trying will be to get brushless vacuum pumps to replace the brushed units.

I'll table this issue for now and report back when the brushless pumps arrive.

My setup:
1 6HC, SBC mode, CNC mode, non-printer application
3 3HC
All boards at 3.5.4
13 stepper motors, 10 Nema17 and 3 Nema23
Pi5 4GB with DuetPi from Nov. 2024
Power supply is 24V, 20A split to all 4 boards

My machine has been running for a year now and just this week, I am suddenly getting resets from the 3HC boards.

I have expansion-timeout and expansion-reconnect report out the board # when an event occurs, so when the latest reset occurred on board 3, in the DWC, I get :

I then pulled an M122 B3 and M122.

M122 B3 before the disconnect/reset

4/9/2025, 12:20:37 PM	M122 B3
Diagnostics for board 3:
Duet EXP3HC rev 1.02 or later firmware version 3.5.4 (2024-11-24 10:40:29)
Bootloader ID: SAME5x bootloader version 2.11 (2024-08-09)
All averaging filters OK
Never used RAM 156540, free system stack 178 words
Tasks: Move(3,nWait 7,0.0%,145) HEAT(2,nWait 6,0.0%,130) CanAsync(5,nWait 4,0.0%,62) CanRecv(3,nWait 1,0.0%,74) CanClock(5,nWait 1,0.0%,63) TMC(2,nWait 6,6.8%,95) MAIN(1,running,92.0%,438) IDLE(0,ready,0.0%,39) AIN(2,delaying,1.1%,259), total 100.0%
Owned mutexes:
Last reset 00:09:49 ago, cause: power up
Last software reset data not available
Driver 0: pos 0, 8.9 steps/mm, standstill, SG min 0, mspos 8, reads 61258, writes 16 timeouts 0, steps req 0 done 0
Driver 1: pos 0, 6.7 steps/mm, standstill, SG min 0, mspos 8, reads 61258, writes 16 timeouts 0, steps req 0 done 0
Driver 2: pos 1351998, 1600.0 steps/mm, standstill, SG min 0, mspos 584, reads 61258, writes 17 timeouts 0, steps req 0 done 403620
Moves scheduled 9, completed 9, in progress 0, hiccups 0, segs 6, step errors 0, maxLate 0 maxPrep 16, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0, ebfmin 0.00 max 0.00
Peak sync jitter -6/6, peak Rx sync delay 184, resyncs 0/0, no timer interrupt scheduled
VIN voltage: min 23.8, current 23.8, max 24.1
V12 voltage: min 12.3, current 12.3, max 12.4
MCU temperature: min 30.5C, current 30.8C, max 33.1C
Last sensors broadcast 0x00000000 found 0 73 ticks ago, 0 ordering errs, loop time 0
CAN messages queued 4869, send timeouts 0, received 5311, lost 0, errs 0, boc 0, free buffers 38, min 38, error reg 0
dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 403, adv 37023/37086

M122 B3 after the disconnect/reset

4/9/2025, 12:57:22 PM	M122 B3
Diagnostics for board 3:
Duet EXP3HC rev 1.02 or later firmware version 3.5.4 (2024-11-24 10:40:29)
Bootloader ID: SAME5x bootloader version 2.11 (2024-08-09)
All averaging filters OK
Never used RAM 156684, free system stack 180 words
Tasks: Move(3,nWait 7,0.0%,128) HEAT(2,nWait 6,0.0%,132) CanAsync(5,nWait 4,0.0%,66) CanRecv(3,nWait 1,0.0%,74) CanClock(5,nWait 1,0.0%,64) TMC(2,nWait 6,7.0%,61) MAIN(1,running,91.8%,387) IDLE(0,ready,0.0%,39) AIN(2,delaying,1.1%,264), total 100.0%
Owned mutexes:
Last reset 00:04:28 ago, cause: reset button
Last software reset data not available
Driver 0: pos -17952, 80.0 steps/mm, standstill, SG min 0, mspos 200, reads 56767, writes 16 timeouts 0, steps req 0 done 20268
Driver 1: pos 0, 80.0 steps/mm, standstill, SG min n/a, mspos 840, reads 56770, writes 13 timeouts 0, steps req 0 done 0
Driver 2: pos -994, 80.0 steps/mm, standstill, SG min 0, mspos 712, reads 56770, writes 14 timeouts 0, steps req 0 done 2240
Moves scheduled 13, completed 13, in progress 0, hiccups 0, segs 6, step errors 0, maxLate 0 maxPrep 17, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0, ebfmin 0.00 max 0.00
Peak sync jitter -6/6, peak Rx sync delay 180, resyncs 0/0, no timer interrupt scheduled
VIN voltage: min 22.2, current 23.8, max 23.9
V12 voltage: min 12.3, current 12.3, max 12.4
MCU temperature: min 34.0C, current 34.2C, max 35.5C
Last sensors broadcast 0x00000000 found 0 157 ticks ago, 0 ordering errs, loop time 0
CAN messages queued 2169, send timeouts 0, received 2437, lost 0, errs 0, boc 0, free buffers 38, min 38, error reg 0
dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 399, adv 36151/37197

I can assure you that no one is pressing the reset button on the 3HC board.

M122 for 6HC after the disconnect/reset

4/9/2025, 12:59:37 PM	M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5.4 (2024-11-24 10:47:10) running on Duet 3 MB6HC v1.01 (SBC mode)
Board ID: 08DJM-9P63L-DJMSS-6J9F0-3SN6N-9UHZA
Used output buffers: 1 of 40 (24 max)
=== RTOS ===
Static ram: 155464
Dynamic ram: 98656 of which 0 recycled
Never used RAM 18360, free system stack 138 words
Tasks: SBC(2,ready,2.0%,747) HEAT(3,nWait 6,0.0%,351) Move(4,nWait 6,0.1%,211) CanReceiv(6,nWait 1,0.0%,769) CanSender(5,nWait 7,0.0%,329) CanClock(7,delaying,0.0%,346) TMC(4,nWait 6,9.2%,53) MAIN(2,running,87.5%,444) IDLE(0,ready,1.2%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:48:49 ago, cause: power up
Last software reset at 2025-04-09 12:10, reason: User, Expansion spinning, available RAM 19224, slot 0
Software reset code 0x6012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
MCU temperature: min 40.6, current 44.0, max 44.3
Supply voltage: min 21.7, current 23.7, max 23.8, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.2, current 12.3, max 12.3, under voltage events: 0
Heap OK, handles allocated/used 297/281, heap memory allocated/used/recyclable 6144/5008/80, gc cycles 59
Events: 1 queued, 1 completed
Driver 0: standstill, SG min 0, mspos 600, reads 60927, writes 6 timeouts 0
Driver 1: standstill, SG min 0, mspos 1016, reads 60927, writes 6 timeouts 0
Driver 2: standstill, SG min n/a, mspos 8, reads 60933, writes 0 timeouts 0
Driver 3: standstill, SG min 0, mspos 280, reads 60927, writes 6 timeouts 0
Driver 4: standstill, SG min 0, mspos 184, reads 60928, writes 6 timeouts 0
Driver 5: standstill, SG min 0, mspos 520, reads 60927, writes 6 timeouts 0
Date/time: 2025-04-09 12:59:37
Slowest loop: 57.87ms; fastest: 0.04ms
=== 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 6, maxWait 203822ms, 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 1659, completed 1659, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 272], 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 -1 -1 -1 -1, ordering errs 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 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 22635, received 58478, lost 0, errs 0, boc 0
Longest wait 3ms for reply type 6024, peak Tx sync delay 274, free buffers 50 (min 48), ts 11735/11735/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 20833/20833
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x24cfc
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.4 (2024-11-25 17:32:26, 64-bit)
HTTP+Executed:
> Executing M122
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 9
Full transfers per second: 53.22, max time between full transfers: 45.8ms, max pin wait times: 32.9ms/6.1ms
Codes per second: 3.93
Maximum length of RX/TX data transfers: 6217/944

config.g

; General preferences
M453                                                        ; set CNC mode
M550 P"A1000-0"                                             ; set name of controller
G90                                                         ; set absolute coordinates
G4 P1000                                                    ; 1s delay for CAN comms
; Drives
; Motors are wired to Duet A-A, B-B - motor directions are flipped here
M569 P0.0 S0                                                ; physical drive 0.0 goes forwards
M569 P0.1 S0                                                ; physical drive 0.1 goes forwards
M569 P0.2 S0                                                ; physical drive 0.2 goes forwards
M569 P0.3 S1                                                ; physical drive 0.3 goes reverse
M569 P0.4 S1                                                ; physical drive 0.4 goes reverse
M569 P0.5 S1                                                ; physical drive 0.5 goes reverse
M569 P1.0 S0                                                ; physical drive 1.0 goes forwards
M569 P1.1 S0                                                ; physical drive 1.1 goes forwards
M569 P1.2 S0                                                ; physical drive 1.2 goes forwards
M569 P2.0 S1                                                ; physical drive 2.0 goes reverse
M569 P2.1 S1                                                ; physical drive 2.1 goes reverse
M569 P2.2 S0                                                ; physical drive 2.2 goes forwards
M569 P3.0 S0                                                ; physical drive 3.0 goes forwards
M569 P3.1 S0                                                ; physical drive 3.1 goes forwards
M569 P3.2 S0                                                ; physical drive 3.2 goes reverse
 
; Set motion system queue parameters
M595 P100 R50 Q0                                            ; set motion system queue 0 to 100 steps
M595 P100 R50 Q1                                            ; set motion system queue 1 to 100 steps
 
; Set drive mapping
M584 X0.0 Z0.1 R0                                           ; set linear drive mapping for gantry
M584 A0.2 B0.3 C0.4 D0.5 R0                                 ; set linear drive mapping for cartridges
M584 Y1.2 W3.0 R0                                           ; set linear drive mapping for slitter and duckbill
M584 'A2.0 'B2.1 'D2.2 'E1.0 'F1.1 R1                       ; set rotary drive mapping for napkin table and slitter feeding
 
; Set microstepping interpolation
M350 X16 Z16 A16 B16 C16 D16 Y16 W16 I1                     ; configure microstepping with interpolation for linear motors
M350 'A16 'B16 'D16 'E16 'F16 I1                            ; configure microstepping with interpolation for rotary motors
 
; Set axes scale values
M92 X60.00 Z507.00 A1520.50 B1520.50 C1520.50 D1520.50 Y54.00 W53.75                ; set steps per mm
M92 'A20.90 'B8.88 'D10.50 'E9.00 'F9.00                                            ; set steps per degree
 
; Set max speed change values
M566 X400.00 Z400.00 A400.00 B400.00 C400.00 D400.00 Y400.00 W400.00                ; set maximum instantaneous speed changes (mm/min)
M566 'A450.00 'B900.00 'D500.00 'E450.00 'F450.00                    		        ; set maximum instantaneous speed changes (mm/min)
 
; Set max speeds
M203 X40000.00 Z20000.00 A5000.00 B5000.00 C5000.00 D5000.00 Y30000.00 W7000.00     ; set maximum speeds (mm/min)
M203 'A30000.00 'B35000.00 'D5000.00 'E40000.00 'F40000.00                          ; set maximum speeds (mm/min)
 
; Set accelerations
M201 X3000.00 Z1500.00 A500.00 B500.00 C500.00 D500.00 Y2000.00 W1000.00            ; set accelerations (mm/s^2)
M201 'A2000.00 'B2000.00 'D1000.00 'E5000.00 'F2000.00                              ; set accelerations (mm/s^2)
 
; Set motors currents and idle factor
M906 X2000 Z1400 A3000 B3000 C3000 D3000 Y1500 W1500 I5                             ; set motor currents (mA) and motor idle factor in per cent
M906 'A3500 'B2800 'D2800 'E1500 'F2800 I5                                          ; set motor currents (mA) and motor idle factor in per cent
 
; Set idle timeout
M84 S30                                      						                ; Set idle timeout
 
; Axis Limits - minimum
M208 X-2 Z-85 A-5 B-5 C-5 D-5 Y-2 W-2 S1                                            ; set linear axis minimum
M208 'A-5 'B-30 'D-5 'E-100 'F-30 S1                                                 ; set rotary axis minimum
 
; Axis Limits - maximum
M208 X601 Z50 A200 B380 C380 D380 Y195 W200 S0                                      ; set linear axis maximum
M208 'A400 'B10000 'D180 'E10000 'F10000 S0                                          ; set rotary axis maximum
 
; Endstops
M574 X1 S1 P"!^3.io4.in"        ; 
M574 Y1 S1 P"!^2.io4.in"        ; 
M574 Z1 S1 P"!^3.io5.in"        ;
M574 A1 S1 P"!^3.io0.in"        ;
M574 B1 S1 P"!^3.io1.in"        ;
M574 C1 S1 P"!^3.io2.in"        ;
M574 D1 S1 P"!^3.io3.in"        ; 
M574 W1 S1 P"!^0.io6.in"        ; 
M574 'A1 S1 P"!^2.io0.in"       ; 
M574 'B1 S1 P"!^2.io1.in"       ;
M574 'D1 S1 P"!^2.io2.in"       ; 
M574 'E2 S1 P"!^0.io8.in"       ; 
 
; Inputs - for use with M581/2 commands
M950 J0 C"!^0.io0.in"	        ; 
M950 J1 C"!^0.io1.in"	        ; 
M950 J2 C"!^0.io2.in"           ; Spare
M950 J3 C"!^0.io3.in"           ; 
M950 J4 C"!^0.io4.in"           ; spare
M950 J5 C"!^0.io5.in"           ; spare
M950 J7 C"!^0.io7.in"           ; 
M950 J10 C"!^1.io0.in"	        ; 
M950 J11 C"!^1.io1.in"	        ; 
M950 J12 C"!^1.io2.in"	        ; 
M950 J13 C"!^1.io3.in"	        ; 
M950 J14 C"!^1.io4.in"	        ; 
M950 J15 C"!^1.io5.in"	        ; 
M950 J23 C"!^2.io3.in"	        ; spare
M950 J25 C"!^2.io5.in"	        ; Napkin Cartridge Present
 
; Thermister configuration (if installed)
M308 S0 P"temp0" Y"thermistor" T100000 B4261    ; sensor 0
M308 S1 P"temp1" Y"thermistor" T100000 B4261    ; sensor 1
 
; Outputs - for use with M42 commands
; Board 0
M950 P0 C"0.io0.out"	        ; 
M950 P1 C"0.io1.out"	        ; 
M950 P2 C"0.io2.out"	        ; 
M950 P3 C"0.io3.out"	        ; 
M950 P4 C"0.io4.out"	        ; Spare
M950 P5 C"0.io5.out"	        ; Spare
M950 P6 C"0.io6.out"	        ; 
M950 P7 C"0.io7.out"	        ; 
M950 P8 C"0.io8.out"	        ; Spare 
; Board 1
M950 P9  C"1.io0.out"	        ; Spare 
M950 P10 C"1.io1.out"	        ; Spare 
M950 P11 C"1.io2.out"	        ; Spare 
M950 P12 C"1.io3.out"	        ; Spare 
M950 P13 C"1.io4.out"	        ; Spare 
M950 P14 C"1.io5.out"	        ; Spare 
; Board 2
M950 P15 C"2.io0.out"	        ; Spare 
M950 P16 C"2.io1.out"	        ; Spare 
M950 P17 C"2.io2.out"	        ; Spare 
M950 P18 C"2.io3.out"	        ; Spare 
M950 P19 C"2.io4.out"	        ; Spare 
M950 P20 C"2.io5.out"	        ; Spare 
; Board 3
M950 P21 C"3.io0.out"	        ; Spare 
M950 P22 C"3.io1.out"	        ; Spare 
M950 P23 C"3.io2.out"	        ; Spare 
M950 P24 C"3.io3.out"	        ; Spare 
M950 P25 C"3.io4.out"	        ; Spare 
M950 P26 C"3.io5.out"	        ; Spare 
 
; Fan configuration (if installed)
; 4 Wire Fan Configuration
M950 F0 C"!0.out4+out4.tach" K2
; 3 Wire Fan Configuration
;M950 F0 C"0.out4+out4.tach" K2
 
; Turn on fan to initial setting
;M106 P0 S1 B0.5
 
; NeoPixel RGBW LED Strip configuration
M950 E0 C"led" T2 Q3000000

I have 3 boards addressed 1, 2, 3. 2 and 3 seem to do it most of the time. The CAN cable goes from 6HC to B3, then B2, then B1 with B1 terminated. I have switched the cable to 6HC, B1, B2, B3 with B3 terminated, I have swapped/replaced boards and CAN cables, and the issue persists. With 45 minutes of a power up, the problem will happen. I have to power down and back up and the machine can run again.

I have not made any electrical or software changes in the last week. I even rolled back to an older software change made 3 weeks ago, just in case, to no avail.

So, other than actually pushing the reset button, what else causes the 3HC to report a push button reset as the cause for the last reset?

@droftarts @chrishamm

I can confirm that the re-racking occurs whenever a G92 is executed. No need for a G28 X or M98 P"homex.g".

I can send a G92 X0 (or any other axis letter) and watch it occur in the DWC.

I've gone a few days now and the multiple motion systems is working well. I'll call this one closed.

Thanks for the assist!

1 6HC, 3 3HC, Pi5, latest DuetPi, 3.6.0-rc2 on all boards, CNC mode

The re-racking issue mentioned here Re: 3.6.0-beta.3 in CNC Mode Issues seems to still be an issue.

I have 14 axes and now it's just the last 4 that re-rack. Previously it was any axis over #6 that would re-rack.

Here's a video:
8c201daf-c529-41a4-8c3b-bd18f347af42-Duet Home All 2.mp4