Solved Motor brake not working on expansion board
-
-
Hi @jay_s_uk, unfortunately I don't see
Duet3_CANiap32_Mini5plus.bin
in the link provided. Am I missing something? -
@mike_b DSF should handle the SBC IAP file, they aren't part of a normal release
-
@jay_s_uk When you say "DSF should handle the SBC IAP file" do you mean that I'll be able to find the .bin file in the DSF git repo?
-
@mike_b when you sudo apt update/upgrade, everything gets pulled down and automatically updated. so I suppose I should say the DSF repository (not git)
-
@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 -
@dc42 How do we update to this if we're running in SBC mode? The M997 commands don't work.
-
@p8blr you can't at the moment
-
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? -
@mike_b just wait for @chrishamm to respond. You can usually upgrade to RC versions but it's obviously not working so be patient
-
Hey @jay_s_uk Thanks for your feedback! I truly appreciate everyone’s input and am happy to wait for a response Thanks again!
-
@mike_b It's now available via the package feeds, apologies for the delay.
-
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