Best posts made by MGJosh

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