tl;dr - I think that the automatic restart when saving config.g through DWC should include a restart of any attached expansion boards.

Separate from that, I think that the config tool should include the "G4 S1 ;wait for expansion boards to start" recommended on the wiki (https://duet3d.dozuki.com/Wiki/Duet_3_Tool_Board#Section_Startup_Time ) in the exported config.g file, when any expansion board is configured.

I chose the "config tool" forum category as it relates to part of that, but I'm happy to have this moved wherever is better.

Firmware info:

M115 B121
Duet TOOL1LC firmware version 3.2.2 (2021-02-12)
M115
FIRMWARE_NAME: RepRapFirmware for Duet 3 Mini 5+ FIRMWARE_VERSION: 3.2.2 ELECTRONICS: Duet 3 Mini5plus Ethernet FIRMWARE_DATE: 2021-02-11

Slightly longer version - changing the M950 J parameter for a button on an attached 1LC expansion board, by editing config.g, saving and allowing the automatic board restart, can lead to erratic behavior and an error report from firmware. In my testing I had set 'M950 J0 C"!121.button0"' at one point, but changed it later to J2; when config.g was saved, and the automatic restart permitted, the firmware reported "Error: M950: Pin 121.button1 is not free". My current understanding is that this was caused by the Duet3 restarting, but the 1LC not restarting - when the Duet came back up and ran config.g, the M950 command found that 121.button0 wasn't free.

All of the below is super rambly and better summarized above, so can be ignored; but, it might be useful for someone searching in the future...

This is a bit of a post-mortem on some diagnostics I was doing this morning, while getting a 1LC setup on a printer running a Duet3 Mini5+.

I went through the general procedures, updated toolboard firmware, etc., and wanted to setup triggers to extrude and retract on the toolboard buttons. I don't have a perfect history of the configuration changes that were made, but I was playing around with M950 and M581 in config.g, as well as the trigger#.g files, trying to get the buttons to work how I wanted.

The final hurdle I had was a report, after saving config.g and permitting the restart, that "Error: M950: Pin 121.button1 is not free" (and same for 121.button0). I spent quite a bit of time searching around trying to figure out how to resolve this - config.g had no other mentions of button0 or button1, couldn't figure out how to free up the pin, etc. I eventually had the idea to try a full emergency stop to restart everything, and that finally resolved the issue - no "pin X is not free" messages, and the buttons on the 1LC now work as desired.

I think the final "bug" form was that the 1LC was not restarting when the main Duet3 restart was triggered by saving config.g, so pin "121.button1" was actually still defined as far as the 1LC was aware; I'm sure the internal mapping is a bit more complicated than that, but it matches my experience.

I was able to repeat the issue by changing the "J" parameter number for one of my M950 commands to a different number, saving config.g and restarting - this reported a "pin is not free" error on the one that I had changed.

For posterity and clarity, some other information that might help others searching for this:

First, I think that a way to partially resolve this is by adding "M999 B121" (substituting your 1LC/etc. board number for "121") to the beginning of config.g, before the "G4 S1" that was recommended when using an expansion board. I haven't tested this, and I'm not sure if there are other potential issues from this change (especially based on the various notes on the wiki for 1LC rev 0.6 boards), but it might be worth testing.

Second, to get some information together in a single place for anyone looking to implement the same setup:

config.g relevant commands:

M950 J2 C"!121.button0"
M950 J3 C"!121.button1"
M581 T2 P2 S1
M581 T3 P3 S1

That configures trigger2 for the "front" ("left", "button0", etc.) button, and trigger3 for the rear button.

trigger2.g:

M117 "Toolboard Button 0 Pressed!"
M120
M83
G1 E10 F300
M121

trigger3.g is the same but with a retraction instead.

@PaulHew that message could be from an incomplete hostname change - on a Pi, I always change the hostname in /etc/hostname and /etc/hosts (last line, 127.0.1.1 or 127.0.0.1 - whichever was originally "raspberrypi" or the default hostname); when I've forgotten the /etc/hosts change, I think I remember seeing errors like yours.

For anyone else who comes across this post looking to fix updating firmware on their Duet3 Mini5+ in SBC mode - my Mini5+ was running RRF 3.2.2 (either that's what it came with, or that's what the SBC image installed - don't recall), and no amount of playing with the apt update && apt upgrade cycles or packages would work. So I took @droftarts information, downloaded the "Duet3_SBCiap32_Mini5plus.bin" from /opt/dsf/sd/firmware on the Pi (using WinSCP), and then uploaded it through the DWC. This finally let me update the firmware.
I'm not saying this was the correct choice, and that it won't cause issues down the line, but...firmware updating has been very frustrating, and I'm extremely relieved I finally got this going.

As the title says - it'd be useful (for me, for my specific current goals - I recognize I don't speak for everyone X) ) to be able to specify the output filename that M956 writes to, similar to how M374 works (https://duet3d.dozuki.com/Wiki/Gcode#Section_M374_Save_height_map ). The "P" parameter is already in use for M956, so "F" is probably my vote for the parameter code, and of course for backwards compatibility and ease of use, no specified "F" value means "use the default timestamp output name".

In addition/alternatively, it'd be useful if the accelerometer output file had more information about the machine state when the file was recorded - at the very least if there were any input shapers enabled, and if so, their configuration for the recorded test. That would make it a lot easier to compare the results of different tests, without needing to take notes on the arbitrary filenames generated, or to uniquely name each file (which yes is my first suggestion here, but for plenty of people and uses, that'd be overkill; it also doesn't help if you want to go back and look at your tests that you didn't think at the time were worth documenting thoroughly).

As the title says - it'd be useful (for me, for my specific current goals - I recognize I don't speak for everyone X) ) to be able to specify the output filename that M956 writes to, similar to how M374 works (https://duet3d.dozuki.com/Wiki/Gcode#Section_M374_Save_height_map ). The "P" parameter is already in use for M956, so "F" is probably my vote for the parameter code, and of course for backwards compatibility and ease of use, no specified "F" value means "use the default timestamp output name".

In addition/alternatively, it'd be useful if the accelerometer output file had more information about the machine state when the file was recorded - at the very least if there were any input shapers enabled, and if so, their configuration for the recorded test. That would make it a lot easier to compare the results of different tests, without needing to take notes on the arbitrary filenames generated, or to uniquely name each file (which yes is my first suggestion here, but for plenty of people and uses, that'd be overkill; it also doesn't help if you want to go back and look at your tests that you didn't think at the time were worth documenting thoroughly).

@dc42 Great, thanks for confirming that, I'll work on switching over.

@Nuramori flagging you so you see this - from my understanding of your logs, I think you're running in SBC mode as well.

@dc42 Thanks for pointing that out, commenting the toolboard reset does indeed remove the input handle errors; if the input handle error is the worst that happens, though, I might just keep it in there, as I added the toolboard reset to deal with the issue I posted about here: https://forum.duet3d.com/topic/22612/mini5-and-1lc-revealed-minor-firmware-default-config-bug . Though now that you've explained more about the boot/definition process, the actual issue from that post might be that the M950 command isn't correctly deleting the manually defined pins on the toolboard...

Removing the toolboard reset did not resolve the M956 error, however - same result:

5/21/2021, 8:49:09 AM	G1 X-50 G4 S2 M956 P121.0 S1000 A0 G4 P10 G1 X50 F20000
Error: M956: Accelerometer not found

Accelerometer is still detected by the M122 B121:

5/21/2021, 8:57:39 AM	M122 B121
Diagnostics for board 121:
Duet TOOL1LC firmware version 3.3RC2 (2021-05-11 14:59:50)
Bootloader ID: SAMC21 bootloader version 2.3 (2021-01-26b1)
Never used RAM 3140, free system stack 0 words
Tasks: Move(notifyWait,0.2%,147) HEAT(delaying,29.7%,81) CanAsync(notifyWait,0.0%,66) CanRecv(notifyWait,1.9%,79) CanClock(notifyWait,2.8%,66) ACCEL(notifyWait,0.0%,61) TMC(notifyWait,139.2%,57) MAIN(running,55.7%,349) IDLE(ready,0.0%,26) AIN(delaying,17.5%,62), total 247.1%
Last reset 164:55:34 ago, cause: software
Last software reset data not available
Driver 0: position 0, 80.0 steps/mm, standstill, SG min/max 0/0, read errors 0, write errors 1, ifcnt 79, reads 53027, writes 9, timeouts 288, DMA errors 0, failedOp 0x72, steps req 0 done 0
Moves scheduled 0, completed 0, in progress 0, hiccups 0, step errors 0, maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0
Peak sync jitter 12, peak Rx sync delay 594, resyncs 803, no step interrupt scheduled
VIN: 24.4V
MCU temperature: min 35.0C, current 37.8C, max 46.9C
Ticks since heat task active 70, ADC conversions started 593734064, completed 593734063, timed out 0, errs 0
Last sensors broadcast 0x00000002 found 1 75 ticks ago, loop time 0
CAN messages queued 7124992, send timeouts 0, received 5343723, lost 0, free buffers 36, min 36, error reg 110000
dup 0, oos 0, bm 0, wbm 0
Accelerometer detected: yes, status: 00
I2C bus errors 0, naks 0, other errors 0

I'm not sure if you saw above, but I am running in SBC mode - does the accelerometer tuning work in SBC mode on this firmware set?

5/21/2021, 9:00:51 AM	M115 B121
Duet TOOL1LC firmware version 3.3RC2 (2021-05-11 14:59:50)
5/21/2021, 9:00:48 AM	M115
FIRMWARE_NAME: RepRapFirmware for Duet 3 Mini 5+ FIRMWARE_VERSION: 3.3RC2 ELECTRONICS: Duet 3 Mini5plus Ethernet FIRMWARE_DATE: 2021-05-11 14:55:40

FWIW, http://www.id2db.com/genuine10.php reports both probes' serial numbers as legitimate. I think there's some confusion in this discussion about which probe is new vs old, but either way, I have a new v3.1 that looks basically identical to A7X... (corner notches on PCB, no "A&T" letters on injection molded housing body), and an older V3.0 and a V3.1 that looks very similar to 9CR... (square corners, no "R" on BLTouch on PCB). I'm also very confident that mine are all genuine.

That is all - I can't really help with the main issue, but thought providing some info from my own stock of probes would at least better inform that part of the discussion (it's easy to dismiss a failure as a crappy clone, vs. a legitimately failed BLTouch, which does happen too). I'm also not saying definitively both are real, just that right now my vote would be that both are legit.

I'm seeing the same error response, but with the M956 command when trying to actually read from the accelerometer.

I saw in multiple places notes that the accelerometer only works with the Duet3 running in standalone mode - is this still the case? https://duet3d.dozuki.com/Wiki/Accelerometers is one place ; if that's still true, I expect my issue (and possibly Nuramori's) is from running in SBC mode. If it's just a dumb configuration mistake, please let me know X)

Error (by itself here, but the same error happens when using the example "move, wait and test" gcode snippet):

5/14/2021, 11:56:16 AM	M956 P121.0 S1000 A0
Error: M956: Accelerometer not found

M122 B121 and M122 responses, not long after a reset for testing:

5/14/2021, 11:55:33 AM	M122 B121
Diagnostics for board 121:
Duet TOOL1LC firmware version 3.3RC2 (2021-05-11 14:59:50)
Bootloader ID: SAMC21 bootloader version 2.3 (2021-01-26b1)
Never used RAM 3140, free system stack 0 words
Tasks: Move(notifyWait,0.0%,153) HEAT(delaying,0.2%,81) CanAsync(notifyWait,0.0%,66) CanRecv(notifyWait,0.0%,79) CanClock(notifyWait,0.0%,66) ACCEL(notifyWait,0.0%,61) TMC(delaying,2.8%,57) MAIN(running,92.0%,349) IDLE(ready,0.0%,26) AIN(delaying,4.9%,62), total 100.0%
Last reset 00:02:41 ago, cause: software
Last software reset data not available
Driver 0: position 0, 80.0 steps/mm, standstill, SG min/max 0/0, read errors 0, write errors 1, ifcnt 69, reads 15357, writes 9, timeouts 0, DMA errors 0, steps req 0 done 0
Moves scheduled 0, completed 0, in progress 0, hiccups 0, step errors 0, maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0
Peak sync jitter 9, peak Rx sync delay 210, resyncs 0, no step interrupt scheduled
VIN: 24.5V
MCU temperature: min 38.8C, current 39.5C, max 39.5C
Ticks since heat task active 85, ADC conversions started 161830, completed 161829, timed out 0, errs 0
Last sensors broadcast 0x00000002 found 1 90 ticks ago, loop time 0
CAN messages queued 1944, send timeouts 0, received 1467, lost 0, free buffers 36, min 36, error reg 0
dup 0, oos 0, bm 0, wbm 0
Accelerometer detected: yes, status: 00
I2C bus errors 0, naks 0, other errors 0
5/14/2021, 11:55:29 AM	M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.3RC2 (2021-05-11 14:55:40) running on Duet 3 Mini5plus Ethernet (SBC mode)
Board ID: W53WL-F396U-D65J0-40KM2-LA03Z-RAFMP
Used output buffers: 1 of 40 (10 max)
=== RTOS ===
Static ram: 102476
Dynamic ram: 92608 of which 0 recycled
Never used RAM 48620, free system stack 194 words
Tasks: SBC(ready,4.8%,300) HEAT(delaying,0.0%,356) Move(notifyWait,0.1%,338) CanReceiv(notifyWait,0.0%,773) CanSender(notifyWait,0.0%,371) CanClock(delaying,0.0%,353) TMC(notifyWait,0.7%,115) MAIN(running,93.5%,566) IDLE(ready,0.1%,29) AIN(delaying,0.8%,266), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:02:42 ago, cause: software
Last software reset at 2021-05-14 16:52, reason: User, none spinning, available RAM 45732, slot 2
Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
MCU revision 3, ADC conversions started 162712, completed 162711, timed out 0, errs 0
Step timer max interval 753
MCU temperature: min 38.2, current 38.4, max 39.1
Supply voltage: min 23.8, current 24.3, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Driver 0: position 0, standstill, SG min/max 0/0, read errors 0, write errors 1, ifcnt 40, reads 8530, writes 11, timeouts 0, DMA errors 0
Driver 1: position 0, standstill, SG min/max 2/2, read errors 0, write errors 1, ifcnt 38, reads 8530, writes 11, timeouts 0, DMA errors 0
Driver 2: position 0, standstill, SG min/max 0/0, read errors 0, write errors 1, ifcnt 38, reads 8530, writes 11, timeouts 0, DMA errors 0
Driver 3: position 0, standstill, SG min/max 0/0, read errors 0, write errors 1, ifcnt 35, reads 8529, writes 11, timeouts 0, DMA errors 0
Driver 4: position 0, standstill, SG min/max 0/0, read errors 0, write errors 1, ifcnt 29, reads 8532, writes 9, timeouts 0, DMA errors 0
Driver 5: position 0, assumed not present
Driver 6: position 0, assumed not present
Date/time: 2021-05-14 16:55:28
Cache data hit count 388839009
Slowest loop: 1.22ms; fastest: 0.08ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 0.0MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.5
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by 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
Code queue is empty.
=== CAN ===
Messages queued 1451, send timeouts 0, received 1939, lost 0, longest wait 2ms for reply type 6049, peak Tx sync delay 259, free buffers 17 (min 16)
=== SBC interface ===
State: 4, failed transfers: 0
Last transfer: 3ms ago
RX/TX seq numbers: 5736/5736
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x10c14
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.3-rc2
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 35.61
Codes per second: 0.39
Maximum length of RX/TX data transfers: 3260/736

In case it helps, config.g (M955 added now, but earlier testing with it only sent manually had the same behavior):

; Configuration file for Duet 3 Mini 5+ (firmware version 3)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.2.3 on Mon Mar 15 2021 11:42:33 GMT-0400 (Eastern Daylight Time)

; General preferences
G90                                          ; send absolute coordinates...
M83                                          ; ...but relative extruder moves
M550 P"duet35m3"                           ; set printer name

; Network
;M552 S0                                      ; disable network

M999 B121
G4 S3 ;wait for expansion boards to start


; Drives
M569 P0.0 S1                                 ; 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 backwards
M569 P0.3 S1                                 ; physical drive 0.3 goes forwards
M569 P121.0 S0 ;toolboard extruder motor (maybe) - flipped from original setup because I basically made a crossover motor cable... - josh 4/7/2021
M584 X0.0 Y0.1 Z0.2 E0.3                     ; set drive mapping
;M584 X0.0 Y0.1 Z0.2 E121.0                     ; set drive mapping (toolboard, maybe)
M350 X16 Y16 Z16 E16 I1                      ; configure microstepping with interpolation
M92 X80.1 Y80.1 Z1007.70 E471.50 S16           ; set steps per mm
M566 X300.00 Y900.00 Z60.00 E600.00          ; set maximum instantaneous speed changes (mm/min)
M203 X18000.00 Y18000.00 Z1200.00 E1800.00      ; set maximum speeds (mm/min)
M201 X1200.00 Y1200.00 Z10.00 E2000.00          ; set accelerations (mm/s^2)
M906 X400 Y400 Z1500 E800 I60                 ; set motor currents (mA) and motor idle factor in per cent ; changed X and Y from 800 to 1200 to test perimeter quality - Josh 4/28/2021; changed to X400 Y400 for further testing - Josh 4/29/2021
M84 S30                                      ; Set idle timeout

; Axis Limits
M208 X-4 Y0 Z-15 S1                          ; set axis minima
M208 X205 Y255 Z212 S0                       ; set axis maxima

; Endstops
M574 X1 S1 P"io0.in"                         ; configure active-high endstop for low end on X via pin io0.in
M574 Y1 S1 P"io1.in"                         ; configure active-high endstop for low end on Y via pin io1.in
M574 Z2 S1 P"io2.in"                         ; configure active-high endstop for high end on Z via pin io2.in

; Z-Probe
M558 P0 H5 F120 T6000                        ; disable Z probe but set dive height, probe speed and travel speed
M557 X15:190 Y15:195 S20                     ; define mesh grid

; Heaters
;M308 S0 P"temp1" Y"thermistor" T100000 B4138 ; configure sensor 0 as thermistor on pin temp1
M308 S0 P"temp1" Y"thermistor" T100000 B4072 ; configure sensor 0 as thermistor on pin temp1
M950 H0 C"out0" T0                           ; create bed heater output on out0 and map it to sensor 0
M307 H0 B0 S1.00                             ; enable bang-bang mode for the bed heater and set PWM limit
M307 H0 R0.164 C781.6 D19.38 S1.00 V23.8
M140 H0                                      ; map heated bed to heater 0
M143 H0 S120                                 ; set temperature limit for heater 0 to 120C
M570 H0 S120 ; added by Josh 3/15/2021 to prevent bed heating timeout.


;M308 S1 P"temp0" Y"thermistor" T100000 B4138 ; configure sensor 1 as thermistor on pin temp0
;M950 H1 C"out1" T1                           ; create nozzle heater output on out1 and map it to sensor 1
;M307 H1 B0 S1.00                             ; disable bang-bang mode for heater  and set PWM limit
;M143 H1 S280                                 ; set temperature limit for heater 1 to 280C

;below four lines copied for implementing toolboard control - 4/7/2021 Josh
M308 S1 P"121.temp0" Y"thermistor" T100000 B4138 ; configure sensor 1 as thermistor on pin temp0
M950 H1 C"121.out0" T1                           ; create nozzle heater output on out1 and map it to sensor 1
M307 H1 B0 S1.00                             ; disable bang-bang mode for heater  and set PWM limit
M143 H1 S280                                 ; set temperature limit for heater 1 to 280C




; Fans
;M950 F0 C"out5" Q500                         ; create fan 0 on pin out5 and set its frequency
;M106 P0 S0 H-1                               ; set fan 0 value. Thermostatic control is turned off
;M950 F1 C"out6" Q500                         ; create fan 1 on pin out6 and set its frequency
;M106 P1 S1 H1 T45                            ; set fan 1 value. Thermostatic control is turned on

; Fans
; the below four lines copied for implementing toolboard control - 4/7/2021 Josh
M950 F0 C"!121.out1+out1.tach" Q500                         ; create fan 0 on pin out5 and set its frequency
M106 P0 S0 H-1                               ; set fan 0 value. Thermostatic control is turned off
M950 F1 C"121.out2+out2.tach" Q500                         ; create fan 1 on pin out6 and set its frequency
M106 P1 S1 H1 T45                            ; set fan 1 value. Thermostatic control is turned on




; Tools
M563 P0 D0 H1 F0                             ; define tool 0
G10 P0 X0 Y0 Z0                              ; set tool 0 axis offsets
G10 P0 R0 S0                                 ; set initial tool 0 active and standby temperatures to 0C

; Custom settings are not defined

; Miscellaneous
T0                                           ; select first tool


M950 J2 C"121.button0" ; removed the "!" from the beginning of this pin name so that now the toolboard buttons trigger on press, not release - this way I can check the state at the end of the trigger file and keep extruding/retracting if the button is still pressed. 5/11/2021 Josh
M950 J3 C"121.button1"
M581 T2 P2 S1
M581 T3 P3 S1

M955 P121.0 I05 ; configure toolboard v1.1 accelerometer - 5/14/2021 Josh

And finally the result of running config.g; I didn't see these "input handle" errors during my previous resets today, but they may have been silent - I have seen them before, but I think only when the Duet3 Mini5+ and Toolboard firmware versions didn't match perfectly:

5/14/2021, 12:02:15 PM	M98 P"config.g"
Board 121 resetting
Heater 0 allowed excursion 15.0°C, fault trigger time 5.0 seconds
Warning: Board 121 does not have input handle 2080
Warning: Board 121 does not have input handle 20c0
5/14/2021, 12:02:15 PM	Accelerometer 121:0 with orientation 5 samples at 1344Hz with 10-bit resolution

@PaulHew that message could be from an incomplete hostname change - on a Pi, I always change the hostname in /etc/hostname and /etc/hosts (last line, 127.0.1.1 or 127.0.0.1 - whichever was originally "raspberrypi" or the default hostname); when I've forgotten the /etc/hosts change, I think I remember seeing errors like yours.

For anyone else who comes across this post looking to fix updating firmware on their Duet3 Mini5+ in SBC mode - my Mini5+ was running RRF 3.2.2 (either that's what it came with, or that's what the SBC image installed - don't recall), and no amount of playing with the apt update && apt upgrade cycles or packages would work. So I took @droftarts information, downloaded the "Duet3_SBCiap32_Mini5plus.bin" from /opt/dsf/sd/firmware on the Pi (using WinSCP), and then uploaded it through the DWC. This finally let me update the firmware.
I'm not saying this was the correct choice, and that it won't cause issues down the line, but...firmware updating has been very frustrating, and I'm extremely relieved I finally got this going.

@war4peace
I'd say first check that your Y gantry is moving the correct direction - if you hit the Y endstop while Y is homing, then command a 10mm move, you can tell which direction the firmware thinks the gantry should be moving. As you've got a CoreXY I imagine the configuration is a bit more complicated than on the Cartesians I'm used to, but https://duet3d.dozuki.com/Wiki/Gcode#Section_M667_Select_CoreXY_or_related_mode and https://duet3d.dozuki.com/Wiki/Gcode#Section_M569_Set_motor_driver_direction_enable_polarity_and_step_pulse_timing should be enough to figure out how to get the motor logic switched around.

Because this is CoreXY I don't actually have a strong intuition for how the motors all work together, so I'm not even sure if a single motor moving the wrong direction can flip just the Y gantry movement...

Separately (but maybe related?) - is there a reason you used "io2.in" for your Y endstop, instead of the "io0.in" from the build instructions?

Finally, in the likely case my reply didn't help much - can you post your full config.g file for anyone else to check?

tl;dr - I think that the automatic restart when saving config.g through DWC should include a restart of any attached expansion boards.

Separate from that, I think that the config tool should include the "G4 S1 ;wait for expansion boards to start" recommended on the wiki (https://duet3d.dozuki.com/Wiki/Duet_3_Tool_Board#Section_Startup_Time ) in the exported config.g file, when any expansion board is configured.

I chose the "config tool" forum category as it relates to part of that, but I'm happy to have this moved wherever is better.

Firmware info:

M115 B121
Duet TOOL1LC firmware version 3.2.2 (2021-02-12)
M115
FIRMWARE_NAME: RepRapFirmware for Duet 3 Mini 5+ FIRMWARE_VERSION: 3.2.2 ELECTRONICS: Duet 3 Mini5plus Ethernet FIRMWARE_DATE: 2021-02-11

Slightly longer version - changing the M950 J parameter for a button on an attached 1LC expansion board, by editing config.g, saving and allowing the automatic board restart, can lead to erratic behavior and an error report from firmware. In my testing I had set 'M950 J0 C"!121.button0"' at one point, but changed it later to J2; when config.g was saved, and the automatic restart permitted, the firmware reported "Error: M950: Pin 121.button1 is not free". My current understanding is that this was caused by the Duet3 restarting, but the 1LC not restarting - when the Duet came back up and ran config.g, the M950 command found that 121.button0 wasn't free.

All of the below is super rambly and better summarized above, so can be ignored; but, it might be useful for someone searching in the future...

This is a bit of a post-mortem on some diagnostics I was doing this morning, while getting a 1LC setup on a printer running a Duet3 Mini5+.

I went through the general procedures, updated toolboard firmware, etc., and wanted to setup triggers to extrude and retract on the toolboard buttons. I don't have a perfect history of the configuration changes that were made, but I was playing around with M950 and M581 in config.g, as well as the trigger#.g files, trying to get the buttons to work how I wanted.

The final hurdle I had was a report, after saving config.g and permitting the restart, that "Error: M950: Pin 121.button1 is not free" (and same for 121.button0). I spent quite a bit of time searching around trying to figure out how to resolve this - config.g had no other mentions of button0 or button1, couldn't figure out how to free up the pin, etc. I eventually had the idea to try a full emergency stop to restart everything, and that finally resolved the issue - no "pin X is not free" messages, and the buttons on the 1LC now work as desired.

I think the final "bug" form was that the 1LC was not restarting when the main Duet3 restart was triggered by saving config.g, so pin "121.button1" was actually still defined as far as the 1LC was aware; I'm sure the internal mapping is a bit more complicated than that, but it matches my experience.

I was able to repeat the issue by changing the "J" parameter number for one of my M950 commands to a different number, saving config.g and restarting - this reported a "pin is not free" error on the one that I had changed.

For posterity and clarity, some other information that might help others searching for this:

First, I think that a way to partially resolve this is by adding "M999 B121" (substituting your 1LC/etc. board number for "121") to the beginning of config.g, before the "G4 S1" that was recommended when using an expansion board. I haven't tested this, and I'm not sure if there are other potential issues from this change (especially based on the various notes on the wiki for 1LC rev 0.6 boards), but it might be worth testing.

Second, to get some information together in a single place for anyone looking to implement the same setup:

config.g relevant commands:

M950 J2 C"!121.button0"
M950 J3 C"!121.button1"
M581 T2 P2 S1
M581 T3 P3 S1

That configures trigger2 for the "front" ("left", "button0", etc.) button, and trigger3 for the rear button.

trigger2.g:

M117 "Toolboard Button 0 Pressed!"
M120
M83
G1 E10 F300
M121

trigger3.g is the same but with a retraction instead.

@dc42 Thank you for the quick reply. I'll follow up with Filastruder.

@bearer Thanks for digging further there - like I said, I went with the first datasheet I found, should have dug deeper to find the actual Duet2 BoM and find the real part number...

Glad to see it's not an issue with the Duet2 PCB itself - I apologize in general for the loose implication.

That being said, those dimensions (±0.125mm centering of the part with recommended pad dimensions and "max" contact tab dimensions) feel kinda...difficult, but that's to someone who lives on the macro scale I guess X)

Thank you both again for your time and information.

Have a good afternoon,
Josh

Good afternoon.

The short version is as the title says, we have a Duet2 Ethernet with some strange behaviors - my current theory is that D13 (SS14M according to the 1.04b .pdf), meant to block power from the onboard 5V rail going back out on the USB port, is soldered offset enough that one of the tabs is shorting the PCB pads together, effectively bypassing the diode.

The serial number for this board is 128.1632, purchased from Filastruder. We're not certain the exact order date - we received a batch recently, but this might actually be from one of several previous orders, so could be a year old (+however long Filastruder had it). That being said, it was only removed from the packaging and installed within the past three weeks.

Is it possible to determine the manufacture/ship date from the serial number, to determine if this is eligible for a RMA? Even if it's not eligible for a RMA, I thought that this would be valuable to post.

The long version:

System: We use a Duet2 and Duex5 in a printer, with a 24VDC PSU (beefy MeanWell) as primary power; there's also a smaller 5V PSU (MeanWell, stepping down the 24VDC) providing power to a Pi and LEDs. The Pi connects to the Duet2 via USB (direct) and Ethernet (via an USB-Ethernet adapter). The Pi has other peripherals attached, including a USB LCD.

Issue: We first noticed that the LCD screen would remain powered up after the Pi itself had shut down in preparation for shutting the entire machine down. On other identically-configured machines, the LCD would shutdown after the Pi fully goes down. This in itself isn't critical, but the LCD turning off is our recommended indicator for when it's safe to flip the main power switch, and it being stuck on "shutting down" indefinitely looks bad.

Investigation: I started by checking if anything on the Pi OS was weird, check the 5V PSU wiring/setup, and then moved on to testing various combinations of the USB peripherals attached. Unplugging the USB cable going to the Duet was the final one that then let the LCD shutdown when the Pi did.

After that, I started checking the Duet more in depth. I hacked up a USB extension cable to measure the voltage on the power and ground wires of the cable, with it just plugged into the Duet, and found ~5VDC; on a different printer, using the same meter, cable, etc., I saw ~0.1VDC.

During this I also noticed that the USB Power LED next to the USB port on the Duet2 was lit, even without a USB cable connected; on a different printer/board, that LED is not lit when the USB cable is not connected.

I had the board swapped out, and started inspecting it under the microscope. U3, commonly mentioned in 5V issues on the forum, looks fine. D13 looks fine in general, but did look offset even without the microscope; under the microscope, I was eventually able to see what looks like a large amount of material under D13 - it looks like the solder pads for it are quite large. While I can't see under the chip directly, and don't know exactly what the tabs on the chip look like, I suspect that one of the tabs is bridging the two pads.

I have an album of some of the better pictures from the inspection; order is probably mixed up, but I eventually used some isopropyl alcohol and a scalpel to scrape away some of the flux around D13 for better visibility; I also took some pictures with the area still flooded with IPA, as it did some useful lensing for certain angles.

https://photos.app.goo.gl/8Jup6ALZdTQkZfok7

Conclusion: Without taking the board to be x-rayed (which is actually an option...), I think that D13 shorting the pads of the PCB is the most likely cause of the issues we saw, as it both fits the symptoms (this is the diode meant to block 5V back out on USB, and that isn't occurring) and has physical evidence pointing towards that defect.

Final notes: For my own curiosity, is this something that's been seen before? I'm not at all comfortable with KiCAD, so can't guarantee I'm measuring correctly, but it looks like the gap between pads for D13 (on the V1.04a schematic I already had downloaded) is ~0.6mm, while the datasheet for the SS14M recommends 2.41mm (https://www.mouser.com/datasheet/2/395/SS12 SERIES_P15-1114294.pdf ). Though that assumes that again, I'm measuring correctly, and that I found the correct datasheet in my first Google result for the part number...

Thank you for your time. If there's anything else I can provide here - the other pictures, results from some other tests, or other information - please let me know.