3.5.0-rc.1 Brakes not engaging
-
@p8blr motor solenoid brakes are normally engaged until current is applied to the solenoid. So if you power up the machine and don't execute any movement commands, they should be engaged. If you then send M17 Z then VIN should be applied to the brake solenoids and the Z brakes should disengage. If you then send M18 Z then the Z brake solenoids should be turned off and the brakes should re-engage after a short delay.
M17/M18 with no parameters should have the same effect because they turn all axis motors on or off. A movement command implicitly does the same as M17 if the motor was idle.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 To be clear, these are "power-off" brakes, which is to say that they apply the brake when power is not applied, and release when powered. You are correct, when the machine starts up, and no movement commands are sent, the brakes are not powered, and when I execute a movement then the brakes are powered. That portion works correctly. What I'm saying is that when I send the machine a M18, the brakes stay powered and I would prefer that they lose power (brakes applied).
-
Bumping this thread. I hope my clarification makes sense.
-
@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
Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth
-
-
@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)
