3.5.0-rc.1 Brakes not engaging
-
@dc42 Checking in again because it's been a while since you last responded. Please see my clarification.
-
@p8blr thanks for the reminder. It's our intention that when you send M18 the brake solenoid is first turned off (to apply the brake), than after a short delay to allow the brake to engage the signal is sent to disable the driver. As the brake may take a little while to engage, if the delay is not long enough then there might be a small amount of motor movement before the brake engages. Is this what you are seeing, or is the brake solenoid continuing to receive power long after the M18 command is executed, and before any other movement commands are sent?
Please try the firmware build at https://www.dropbox.com/scl/fo/tjznycpk7bv7sj71p0ssl/h?rlkey=096p4nvgmigyrb20jj8olg3wu&dl=0 and test which this is still not working.
-
@p8blr hey , i have the same probleme , did you find a solution ?
-
@Amagatth Unfortunately no. I never had a chance to test @dc42 's firmware build, and by the time we got a chance to look at this issue again, we'd upgraded to the latest firmware. I can report that the latest firmware 3.5.1 does not resolve the issue. A M18 does not engage the brakes, the only way I've found to do that is to turn the printer off and on again. This is an issue for large 3D printers, as some have locking doors with a safety system to de-energize the servos when opened, so the brakes not engaging is unsafe (particularly for something like a Z-axis that may drift due to gravity).
There is also the issue of a M18 causing strange homing behavior with the printer which I've reported here:
https://forum.duet3d.com/topic/35836/strange-behavior-after-re-homing-printer/3?_=1719417263446
No response or fix for that yet though. @Phaedrux are these issues perhaps related? -
undefined Phaedrux marked this topic as a question
-
@p8blr i found the same result , but reboot printer take some MS to active brake and the head go down during this time
-
@dc42
this is still persistent in 3.5.2my brake is on
out8of Duet3 6HC in SBC modeProduct Short Name Version Duet 3 MB6HC MB6HC 3.5.2 Duet 3 Expansion MB6XD MB6XD 3.5.2 Duet Software Framework DSF 3.5.2 Duet Web Control DWC 3.5.2the brake is configured with
M569.7 P2 C"out8"brake is engaged when not powered
brake is disengaged when powered- after power on, the brake is engaged (not powered)
M569.7 P2 C"out8"in config.g - after G92 Z300, nothing changed
- after G91 G1 Z-0.05, the brake is disengaged (powered)
- after M17 Z, the brake is still disengaged (powered)
- after M18 Z, the brake is still disengaged (powered)
- after doing
M569.7 P2 C"out8"again, the brake is now engaged (not powered) - so the logic is now inverted - after M18 Z, the brake is still engaged (not powered)
- after G92 Z300, still engaged
- after G91 G1 Z-0.05 still engaged (it is not possible to move the axis or disengage the brake)
- reapplying
M569.7 P2 C"out8"will not change the logic again - applying
M569.7 P2 C"!out8"will change the logic again
so it seams, that the functions
EngageBrakeandDisengageBrakeare not working as expected.
I've tried to find the bug in the code, but was unable to get it. The functions are pretty straigt forward. The only thing that caught my attention was the pin access modePinAccess::write0and the new PWM voltage divider.if (!brakePorts[driver].AssignPort(gb, reply, PinUsedBy::gpout, PinAccess::write0)) { return GCodeResult::error; }but anyhow I don't know if this should be PinAccess::pwm
Another thing is the following inside EngageBrake
#if SUPPORT_BRAKE_PWM currentBrakePwm[driver] = 0.0; #endifif this is not forwared to the Spin() Method - the brake will get disengaged again.
- after power on, the brake is engaged (not powered)
-
-
@timschneider thanks for the update. I have created https://github.com/Duet3D/RepRapFirmware/issues/1023.
closed M17 doesn't re-engage motor brake #1023
-
Also @Amagatth, regarding your thread https://forum.duet3d.com/topic/35935/controle-nema-23-brake, see @dc42's post above.
Ian
TronXY X5S with Duet 3 MB6HC and Roto toolboard : Cartesian bed-slinger with Duet 3 Mini 5+ WiFi and 1LC : RRP Fisher Delta v1 with Duet 2 Maestro : Polargraph with Duet 2 WiFi
-
-
@timschneider thx i try to put your file but i am on 3.5.2 it work ?
-
@Amagatth
yes this is for 3.5.2 and the brake connected to MB6HCanyhow, I've applied the patch from @dc42 on RRF to use WriteAnalog and this works.
src/Platform/Platform.cpp | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/Platform/Platform.cpp b/src/Platform/Platform.cpp index 874b75ac..f3c2f560 100644 --- a/src/Platform/Platform.cpp +++ b/src/Platform/Platform.cpp @@ -2732,8 +2732,10 @@ void Platform::EngageBrake(size_t driver) noexcept { #if SUPPORT_BRAKE_PWM currentBrakePwm[driver] = 0.0; -#endif + brakePorts[driver].WriteAnalog(0.0); +#else brakePorts[driver].WriteDigital(false); // turn the brake solenoid off to engage the brake +#endif } void Platform::DisengageBrake(size_t driver) noexcept@p8blr
this is the file for the 6XD with WriteAnalog(0.0)
Duet3Firmware_MB6XD.bin -
@timschneider thx for the file i apply it
-
@Amagatth it work ! now m18 engage break !
-
-
@timschneider I tried that file but it seems to have messed everything up. Now what do I do?
@dc42 When will this issue be fixed? I've also noticed that remapping drives do different axes messes up the brake control as well. Only a reboot will fix.
-
@p8blr
hi maybe you try the 3.5.3 rc-1 the fix is includedhttps://github.com/Duet3D/RepRapFirmware/releases/tag/3.5.3-rc.1
M17 did not energise the motor brake solenoid (issue 1023) -
@timschneider I just setup a new image again and M997 S2 F"unstable" doesn't work, sudo apt update, sudo apt upgrade doesn't update the firmware, neither does M997 B0. How do I do this? I don't see any documentation of the sort.
-
@dc42 M997 S2 V"3.5.3-rc.1" gives "could not find reprapfirmware package....." on a brand new image. Why is this happening?
-
have you switched from the stable to the unstable package feed?
