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?
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:
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?
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:
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?
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 ?
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.
My system is not a printer, so I don't run job files. I have 50+ macro files that perform each part of my process that I call as needed when needed via a custom python GUI running on the Pi. The custom GUI continuously reads the object model and based on the current state of the sensors connected to the Duet 6HC, I execute the required macros to perform an assembly process.
My motion queues are set to 100 steps each. So, I believe with the M606 S1, the queues are "filling", switching between each other, and "filling" with more commands. I do not see any motion stutter or stopping/waiting of one axis over the other. Granted, I only have 3 commands per motion system, then 2 per while switching between them. I'll try to tax them a bit more with more motion commands to see if/when the queues are affected by quantity of commands.
When I run the above macro, line 15 (G90 G1 A100 F2000) starts a second or two before line 20 (G90 G1 X200 F3000) starts. So the two motion systems don't start simultaneously but it's close enough for what I am trying to do (reduce cycle time by running independent processes simultaneously).
Now, if I do this (at line 15 start P1 with 1 move, switch to P0 and start it with some moves, then go back to P1 and add the removed moves (old lines 16 and 17) to it's queue (lines 23 and 24)):
M606 S1
M596 P0
M400
M596 P1
M400
M596 P0
G90 G1 X0 A0 F2000
M400
M596 P1
M400
G90 G1 A100 F2000
M596 P0
G90 G1 X200 F3000
G90 G1 X0 F3000
G90 G1 X200 F3000
M596 P1
G90 G1 A0 F2000
G90 G1 A100 F2000
G90 G1 A500 F5000
G90 G1 A100 F3000
M596 P0
G90 G1 X500 F5000
G90 G1 X100 F3000
M400
M596 P1
M400
M596 P0
G90 G1 X0 A0 F4000
M400
the 2 axes start pretty much simultaneously. So, it's safe to say there will be a lag before the 2nd queue starts when filling up the 1st queue with it's initial moves/commands, which is totally understandable.
I just need clarification on what the M606 error is all about. What "file" is it referring to?
Here is my test code:
testma.g
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
G90 G1 A100 F2000
M596 P0
G90 G1 X200 F3000
G90 G1 X0 F3000
G90 G1 X200 F3000
M596 P1
G90 G1 A500 F5000
G90 G1 A100 F3000
M596 P0
G90 G1 X500 F5000
G90 G1 X100 F3000
M400
M596 P1
M400
M598
M596 P0
G90 G1 X0 A0 F4000
M400
Everything works as expected but I get:
as soon as I run the macro. The axes perform the motions in the macro but I get the M606 No file is selected error right away and then the green "complete" or "file processed" message.
My start.g and stop.g files exist but are both empty. I thought it was trying to call one of those so I created them but left them blank.
I've read this a couple of times now:
https://docs.duet3d.com/User_manual/RepRapFirmware/Multiple_motion_systems
I still can't figure out what M606 error is all about.
System is 6HC in SBC mode, CNC mode, and I am sending M98 P"testma.g" from the DWC
Well, holy fork!
I totally missed the addition of the M606 command in the firmware changelogs. I'll give the above suggestions a shot.
As usual, self-inflicted wounds do the most damage...
@dc42 I can confirm 3.6.0-rc2 multiple motion system works with the code adjustments.
@dc42 But as is stands, M400 waits for both motions systems to stop motion and also prevents one from loading up the second motion system with moves to be executed independent of the first motion system. Could M598 be a "wait for all motion systems to stop and then release axes"? Per the description in the documentation, that's what it should do, but it doesn't unless you wrap some M400's around it.
As you suggest, if M400 was a wait just for that motion system and the processor kept reading code to allow moves in the other motions system, that could work. We would just need a list of G/M codes that stop the processor from further reading code to be processed by the second motion system. I.e., a G4 Px does the same thing as M400 if it's in M598 P0 or P1; further processing stops until the wait is over, then it continues.
I hope to get to my testing today.
@dc42 now that worked but it also caused axis X to wait until A finished it's move to 0mm before axis X started it's move to 0mm.
Macro:
M400
M598
M596 P1
G90 G1 A100 F2000
M596 P0
G90 G1 X200 F3000
M400
M598
M596 P1
G90 G1 A0 F2000
M400
M596 P0
G90 G1 X0 F3000
M400
M598
M596 P0
G90 G1 X100 A100 F2000
But........
Following your logic... if I do this, it works as desired:
M598
M596 P0
G90 G1 X0 A0 F2000
M400
M598
M596 P1
G90 G1 A100 F2000
M596 P0
G90 G1 X200 F3000
M400
M596 P1
G90 G1 A0 F2000
M596 P0
G90 G1 X0 F3000
M596 P1
M400
M598
M596 P0
G90 G1 X100 A100 F2000
G90 G1 X0 A0 F4000
M400
M598
So I switch back to P1 after starting P0 on it's move to 0mm and issue M400. Once all axes are stopped, issue M598, then go back to P0 and add axis A back in. In all of the instances where I use multiple motion systems, I know if P0 will finish before P1 or vice-versa, so I can add this workaround to my macros.
I'll upgrade one of my runtime systems to 3.6.0-RC2 in the next day or so to see if the code change will solve the issue.
Will we get back to where M400 waits for both motion systems to stop, and then M598 will release the axes?
My setup:
1 6HC - @ 3.6.0-rc.2 (was 3.5.4)
3 3HC - all @ 3.6.0-rc.2 (was 3.5.4)
System has 13 stepper axes across the 4 boards (X, Y, Z, A, B, C, D, W, a, b, d, e, f)
System is set to CNC mode M453. This is a non-printer application
RPi 4, 4GB in SBC mode
I'm still having trouble getting multiple motion system to work again. Everything is fine in 3.5.4. Ever since 3.6.x, it has stopped working.
It seems the Duet will not release multiple motion axes after moves are complete. The DWC always reports out:
Error: in file macro line 18: G1: Drive A is already used by a different motion system
when trying to move an axis in a new motion system that it wasn't previously attached to.
I've got a test board set up with 2 axes and I'm running a very simple motion test.
config.g
; General preferences
M453 ; set CNC mode
M550 P"A2000-xx" ; 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 forward
M569 P0.2 S0 ; physical drive 0.1 goes forward
; 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 R0 ; set linear drive mapping for gantry
M584 A0.2 R0 ; set linear drive mapping for gantry
; Set microstepping interpolation
M350 X16 A16 I1 ; configure microstepping with interpolation for linear motors
; Set axes scale values
M92 X250 A250 ; set steps per mm
; Set max speed change values
M566 X400.00 A400.00 ; set maximum instantaneous speed changes (mm/min)
; Set max speeds
M203 X10000.00 A10000.00 ; set maximum speeds (mm/min)
; Set accelerations
M201 X3000.00 A3000.00 ; set accelerations (mm/s^2)
; Set motor currents and idle factor
M906 X2000 A2000 I5 ; set motor currents (mA) and motor idle factor in per cent
; Axis Limits - minimum
M208 X-200 A-200 S1 ; set linear axis minimum
; Axis Limits - maximum
M208 X1000 A1000 S0 ; set linear axis maximum
Test program:
M400
M598
M596 P1
G90 G1 A100 F2000
M596 P0
G90 G1 X200 F3000
M400
M598
M596 P1
G90 G1 A0 F2000
M596 P0
G90 G1 X0 F3000
M400
M598
M596 P0
G90 G1 X100 A100 F2000
When I run the program, X goes to 100mm and A goes to 200mm, both starting pretty much at the same time but stopping at different times because of the feed rates.
X and A then return to 0mm, again, starting pretty much simultaneously, but stopping at different times because of the feed rates. All expected behavior.
When the system tries to add axis A back to motion system 0 on line 20, I get:
and the program stops so axis X nor axis A move to 100mm.
I didn't see any change in the documentation for coding multiple motion systems, so let me know if I am using the M595, M596, and M598 incorrectly.
I am able to run any desired test pretty quickly on my test board so let me know if there is anything else I can do to help debug the issue.