@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!

@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.

@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.

@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.

@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!

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.

@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

When we started this project 2 years ago, we put everything into the /sys folder because of the M98 info. I just wanted to make sure we weren't missing out on any fun by not having them in the /macros folder. We do not need them to show up in the DWC so I'll leave my files where they are.

Thanks, gents!

I'm reading the SD Card Structure documentation and I have some questions about the folder structure.
Do macro files have to be put in the /macros folder?
Does DWC/DSF treat any file in the /macros folder different than any other folder?

For example, I have 50+ macro files in several folders in the /sys (system) folder and my macros folder is empty.
Are the files under the /sys folder treated any differently that if the files were in the /macros folder?
Or is the /macros folder (and the other folders) just to keep some separation and order to the files on the SD card?
My system is working fine the way I have my folders and files under /sys, I just didn't know if they HAVE to be under /macros because of some extra processing or treatment by DWC/DSF (other than them showing up under Macros in the DWC Dashboard).

My setup is 6HC in CNC mode with 3 3HC, Pi5, latest DuetPi image, 3.6.0-rc2 on all boards
This is a non-printer application

Couple of typos in the SD documentation
https://docs.duet3d.com/User_manual/RepRapFirmware/SD_card

SD card structure
/macros user-defined macro files ?

Troubleshooting SD Card issues

SD Card
slowed down printing ?

@dwuk3d @droftarts

Modified test macro:

;M606 S1

M596 P0
M400

M596 P1
M400

M596 P0
G90 G1 X0 A0 F2000
M400

M596 P1
M400
G90 G1 A100 F2000
G90 G1 A0 F2000

M596 P0
G90 G1 X200 F3000
G90 G1 X0 F3000

M596 P1
G90 G1 A100 F2000
G90 G1 A500 F5000
G90 G1 A100 F2000

M596 P0
G90 G1 X200 F3000
G90 G1 X0 F3000
G4 P1000
echo "X stopped"
G90 G1 X200 F3000
G90 G1 X500 F5000
G90 G1 X100 F3000
G90 G1 X500 F5000

M596 P1
G4 P1000
echo "A stopped"
G90 G1 A500 F5000
G90 G1 A100 F3000
G90 G1 A500 F5000
G90 G1 A100 F2000
G90 G1 A500 F5000
G90 G1 A100 F3000

M596 P0
G90 G1 X100 F5000
G90 G1 X500 F5000
G90 G1 X100 F5000
M400

M596 P1
M400

M596 P0
G90 G1 X0 A0 F4000
M400

So, I am playing with the number of move commands and adding in G4 P1000 with echo between the motion systems. I wanted to see if a G4 in one motion system would affect the other motion system and it does not. Again, as expected per the multiple motion system documentation. I am trusting but verifying...

Everything works as desired as long as I don't let either motion system "run dry" of commands. If one motion system runs out of commands, the axis sits and waits until the next M596 Px and gets more to do... totally understandable and expected per the documents.

Also of note, running with or without M606 S1, the functionality seems to be the the same, just no M606 error without the M606 S1.