Solved Motor brake not working on expansion board
-
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 -
@mike_b M569.7 is supported on expansion boards too, since version 3.5.0 AFAIR.
-
-
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
-
@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?
-
@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 runningM17
disengages the brake (i.e., the voltage across40.out6
reads ~24V with current ~0.2A), and while runningM18
engages the brake (voltage across40.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)
-
@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 delayTry this for your command. It may at least get rid of the error:
M569.7 P40.0 C"out6"
Ian
-
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
-
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.
-
@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
-
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
-
@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
-
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 @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!
-
-