Hey @jay_s_uk when you say "you can't at the moment" do you mean you can't at the moment because of a bug? Or do you mean you can't update to an -rc release in SBC in general? I ask because there does seem to be a version 3.5.3-rc1 in the repo here so I'm not really sure what the issue is. Could you help me understand?

Hi everyone, I’m looking to test the latest 3.6.0-alpha release and would appreciate any general advice from the community on how to do this properly. I want to avoid making any mistakes and thus causing unnecessary work for the developers.

For context, my setup:

• two Mini5+ boards (the first as the main board and the second as an expansion)
• one 1LC toolboard, and
• all in SBC mode.

When I tested the 3.5.3-beta release, I followed the official procedures by switching to the unstable repo, modifying /etc/apt/sources.list.d/duet3d.list, and then running sudo apt update && sudo apt upgrade.

However, I'm unsure about the correct steps for testing the -alpha release. Should I simply download the firmware files to the SBC and the expansion board's SD card? And if I do that, will I also need to update the Duet Control Server or Duet Web Server as part of the process? Thanks in advance!

EDIT: I edited the duet3d.list file to point to unstable-3.6 but running apt list -a duetruntime seems like only 3.6.0~alpha.2 is available:

$ sudo apt list --upgradable
Listing... Done
duetcontrolserver/unstable-3.6 3.6.0~alpha.2 arm64 [upgradable from: 3.5.3~rc.1]
duetpimanagementplugin/unstable-3.6 3.6.0~alpha.2 arm64 [upgradable from: 3.5.3~rc.1]
duetpluginservice/unstable-3.6 3.6.0~alpha.2 arm64 [upgradable from: 3.5.3~rc.1]
duetruntime/unstable-3.6 3.6.0~alpha.2 arm64 [upgradable from: 3.5.3~rc.1]
duetsoftwareframework/unstable-3.6 3.6.0~alpha.2 arm64 [upgradable from: 3.5.3~rc.1]
duettools/unstable-3.6 3.6.0~alpha.2 arm64 [upgradable from: 3.5.3~rc.1]
duetwebcontrol/unstable-3.6 3.6.0~alpha.2 all [upgradable from: 3.5.3~rc.1]
duetwebserver/unstable-3.6 3.6.0~alpha.2 arm64 [upgradable from: 3.5.3~rc.1]
libcamera-ipa/stable 0.3.1+rpt20240906-1 arm64 [upgradable from: 0.3.1+rpt20240829-1]
libcamera-tools/stable 0.3.1+rpt20240906-1 arm64 [upgradable from: 0.3.1+rpt20240829-1]
libcamera0.3/stable 0.3.1+rpt20240906-1 arm64 [upgradable from: 0.3.1+rpt20240829-1]
reprapfirmware/unstable-3.6,unstable-3.6 3.6.0~alpha.2-3 all [upgradable from: 3.5.3~rc.1-1]

Hi @dc42, I realize this is an old thread, but I was wondering if the fix for this bug (commit here) is included in 3.5.3-rc.1? If it is, I can confirm that the issue persists, as I still can't change the idle current on motors connected to my Mini5+ board, which I'm using as an expansion board. Would you like me to test this on the 3.6 alpha release?"

Hi @droftarts thanks for the suggestion. Unfortunately getting the same error message:

9/7/2024, 6:16:58 PM	M569.7 P40.3 C"out6"
                        Error: M569.7:

EDIT: also, is the CAN address in the port name was optional? Snippet from the docs: The CAN address does not need to be specified in the port name, but if it is then it must be the same as the driver CAN address

@dc42 thank you so much for all your debugging suggestions. Every time I run the following command:

M569.7 P40.0 C"40.out6"

I'm presented with this error:

9/7/2024, 3:37:01 PM	M569.7 P40.0 C"40.out6"
                        Error: M569.7:

I do not get this error message when running the equivalent command on the main board. Because of this, I just assumed the brake wasn't functioning on the expansion board. For context, I’m using two Mini5+ boards - the first as the main board and the second as the expansion board with a CAN address of 40.

However, the good news is that, despite the error showing up every time, the brake actually works! I tested it using a multimeter on 40.out6, and running M17 disengages the brake (i.e., the voltage across 40.out6 reads ~24V with current ~0.2A), and while running M18 engages the brake (voltage across 40.out6 drops to ~0V).

In conclusion, seems like the only bug here is the error message appearing when running the command.

Now that the brake is working, the erroneous error message isn’t much of a concern for me. However, please let me know if there’s anything you’d like me to test - I'd be more than happy to assist in any way I can. For example, if you think it’s helpful, I could try installing 3.6.0-alpha.5 and see how it performs.

EDIT: apologies, forgot to answer one of your questions: the response I get after sending M569.7 P40.0 after sending he original command is as follows:

9/7/2024, 3:57:07 PM	M569.7 P40.0
                        Driver 40.0 uses brake port 40.(out6,laser,vfd)

Hey @dc42 in case it's helpful, I am reiterating the issue here:

in 3.5.2 and 3.5.3-rc.1 this command fails:

 M569.7 P40.0 C"40.out5" S25 

while a similar command on the main board works fine:

M569.7 P0.0 C"out5" S25 

Hey @dc42, hmm, ok, I'm now very confused... this entire thread is about fixing this issue, since, as you yourself said at the very top of this thread:

@mike_b this is a known issue, fixed in 3.6.0-alpha and in the forthcoming 3.5.3 release.

Or am I missing something?

Thanks @chrishamm, my entire system is now running 3.5.3-rc.1 as shown here

Unfortunately @dc42 I'm getting the same bug as before:

05/09/2024, 14.02.03 -Error in start-up file config.g line 156: M569.7:
05/09/2024, 14.02.03 -Error: M569.7:

Interestingly, I don't see these errors after power cycling the board and the SBC. That error only shows up when I do an emergency stop or chose "restart mainboard" or "run config file" after editing the config file. Although I guess I'm not getting those messages after a power cycle because DWC starts up only after the error, so doesn't show up in the console?

@dc42 also, I just realized that my particular issue was never mirrored on github - or mentioned in the release notes - so now I'm wondering if this issue got confused with this one?

Looking through the changelogs of previous releases, I see this limitation mentioned for 3.4.0RC1 but it's never mentioned again:
M569.7 (configure driver brake port) is supported, initially on the main board only

Hey @jay_s_uk Thanks for your feedback! I truly appreciate everyone’s input and am happy to wait for a response Thanks again!

Hey @jay_s_uk when you say "you can't at the moment" do you mean you can't at the moment because of a bug? Or do you mean you can't update to an -rc release in SBC in general? I ask because there does seem to be a version 3.5.3-rc1 in the repo here so I'm not really sure what the issue is. Could you help me understand?

@jay_s_uk ah, Ok, got it, thank you! So I guess that mean I'll have to figure out my second issue https://forum.duet3d.com/post/344169, for some reason, despite switching to the unsteady deb repo (i.e deb https://pkg.duet3d.com/ unstable-3.5 armv7 in my sources, running apt update/upgrade doesn't get me 3.5.3-rc