Posts made by mike_b

I'm so sorry to hear this. May he rest in peace. I only discovered his YouTube videos a few weeks ago, and it's heartbreaking to know there won't be any new ones. My condolences to his family and friends.

@o_lampe did you build one with duet3 hardware?

@jay_s_uk thanks again, this is super helpful!

@jay_s_uk just curious, any limitations on the spindle/VFD I should be watching out for when using a duet3 board?

@jay_s_uk awesome, I guess I'll pull the plug and go for it. Thanks!

Hi everyone, I'm thinking about building the PrintNC DIY CNC router and wanted to ask if anyone here has experience with it. If you've built one, I'd love to hear about your experience using Duet hardware with the machine. Specifically, I'm curious if the Duet3 Motor23 CL closed-loop steppers would be a good option for this build. I've always wanted to experiment with closed-loop steppers, but I've never had a project where they seemed necessary. What do you think of these motors for the PrintNC?

Hey @Zseven, I use an mini5+ as an expansion board, let me know if there is anything I could help you with

Hey @droftarts and @dc42 - FYI this issue is fixed in the alpha firmware linked by Andy Everitt in the github issue for this bug: https://github.com/Duet3D/RepRapFirmware/issues/1039 Thanks again for all your help on this!

droftarts created this issue in Duet3D/RepRapFirmware

closed [Bug]: Motor brake reports error when configured on mainboard used as expansion board #1039

@dc42 Great question! Unfortunately, I can’t give a definitive answer at this point without conducting more thorough testing, I’m not entirely sure about the exact sequence of events. Let me get back to you this weekend

Hey @droftarts, thanks for the heads up, and @dc42, enjoy your holiday! I just wanted to take a moment to express how impressed I am with the incredible hardware and software you guys create. My experience with the Mini 5+, 1LC, and magnetic filament monitor has been fantastic! The documentation is top-notch, and the forum is always such a helpful and well-organized place to find support. I know it can be tough and disheartening when all you hear are problems, so I wanted to share my appreciation for all your hard work and dedication. It really shows!

Hey @jay_s_uk, awesome, it worked, thanks for your help!

Hi @droftarts and @dc42, not sure if this is helpful or not, but just wanted to come here to say that this bug is also present in the latest alpha release I'm testing:

Product                 Short Name           Version 
Duet 3 Mini 5+ 	        Mini5plus 	     3.6.0-alpha.5+1
Duet 3 Expansion        Mini5plus Mini5plus  3.6.0-alpha.5+1
Duet 3 Expansion        TOOL1LC TOOL1LC      3.6.0-alpha.5
Duet Software Framework DSF 	             3.6.0-alpha.2
Duet Web Control 	DWC 	             3.6.0-alpha.2 

Hi @dc42 running the following setup:

Product                 Short Name           Version 
Duet 3 Mini 5+ 	        Mini5plus 	     3.6.0-alpha.5+1
Duet 3 Expansion        Mini5plus Mini5plus  3.6.0-alpha.5+1
Duet 3 Expansion        TOOL1LC TOOL1LC      3.6.0-alpha.5
Duet Software Framework DSF 	             3.6.0-alpha.2
Duet Web Control 	DWC 	             3.6.0-alpha.2 

And unfortunately this does not resolve the bug. I am still unable to set a custom idle current on the expansion board; i.e. the idle current remains at the default value, irrespective of what I set in my M906 command. Here are some extra bits of info that might be helpful:

• first, despite the idle current actually being set to the default initially -- I can tell this because my build plate drops; I have a belt driven z-axis with brakes -- running M906 without any parameters reports the desired idle current:

 11/09/2024, 07.42.26 	M906
                        Motor current (mA) - X:1200, Y:1200, Z:1200, E:500, idle factor 75%

• second, the interesting part is that despite the idle factor being set to the default initially, it appears as thought eventually, the motors do enter the desired 75% idle current, I can tell this because the build plate wont crash again. I'm not sure exactly how to verify this, I guess I could use my voltmeter to test current into the motor?

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