Motor brake not working on expansion board

dc42

@mike_b M569.7 is supported on expansion boards too, since version 3.5.0 AFAIR.

mike_b

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?

mike_b

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

dc42

@mike_b in what way does it fail? Does it return an error message, or return no message but the brake doesn't get activated when you use M17 and M18 to enable and disable the motor?

What is the response if you send M569.7 P40.0 after sending the original M569.7 command?

Have you verified that the port, wiring and brake are OK by configuring the port as a GpOut port instead and using M42 to turn the brake on and off?

What expansion board are you using?

Have you tried doing the same thing using 3.6.0-alpha.5 firmware?

mike_b

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

droftarts

@mike_b I don't know if this is a documentation mistake or a not, but the examples for M569.7 in the gcode dictionary don't use the CAN address in the pin name. See https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m5697-configure-motor-brake-port

Examples
M569.7 P40.0 C"out1" ; driver 0 on board 40 uses port out1 on board 40 to control the brake
M569.7 P0.2 C"out9" S20 ; driver 2 on mainboard uses port out9 to control the brake, with 20ms delay

Try this for your command. It may at least get rid of the error:

M569.7 P40.0 C"out6"

Ian

mike_b

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

It sounds to me that the code that supports a main board as an expansion board is returning an error code but otherwise working correctly. @droftarts please log a Github issue for this. We can probably fix it in the 3.5.3 release.

@mike_b yes the CAN address in the port name is optional.

droftarts

@dc42 said in Motor brake not working on expansion board:

@droftarts please log a Github issue for this. We can probably fix it in the 3.5.3 release.

Done.

Ian

mike_b

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

droftarts

@mike_b dc is on holiday this week, so won't have been able to fix this yet. That he's answering forum threads is down to the weather, I expect!

Ian

mike_b

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!

mike_b

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

Motor brake not working on expansion board

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