3.5.0-rc.1 Brakes not engaging

[dc42]

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

[p8blr]

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

[p8blr]

Bumping this thread. I hope my clarification makes sense.

[p8blr]

@dc42 Checking in again because it's been a while since you last responded. Please see my clarification.

[dc42]

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

[Amagatth]

@p8blr hey , i have the same probleme , did you find a solution ?

[p8blr]

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

[Amagatth]

@p8blr i found the same result , but reboot printer take some MS to active brake and the head go down during this time

[timschneider]

@dc42
this is still persistent in 3.5.2

my brake is on out8 of Duet3 6HC in SBC mode

Product				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.2 

the 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 EngageBrake and DisengageBrake are 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 mode PinAccess::write0 and 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;
#endif

if this is not forwared to the Spin() Method - the brake will get disengaged again.

[timschneider]

@p8blr
@Amagatth
I dont need the PWM feature and recompiled the latest 3.5-dev without SUPPORT_BRAKE_PWM
Now, the brake is engaging and disengaging as expected.

Duet3Firmware_MB6HC.bin

[dc42]

@timschneider thanks for the update. I have created https://github.com/Duet3D/RepRapFirmware/issues/1023.

dc42 created this issue 2 Jul 2024, 15:06 in Duet3D/RepRapFirmware

closed M17 doesn't re-engage motor brake #1023

[droftarts]

Also @Amagatth, regarding your thread https://forum.duet3d.com/topic/35935/controle-nema-23-brake, see @dc42's post above.

Ian

[T3P3Tony]

@Amagatth @p8blr which boards are you using, both and mainboards and expansion boards, and which ones have motor brakes connected.

[Amagatth]

@timschneider thx i try to put your file but i am on 3.5.2 it work ?

[timschneider]

@Amagatth
yes this is for 3.5.2 and the brake connected to MB6HC

anyhow, 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

Duet3Firmware_MB6HC.bin

@p8blr
this is the file for the 6XD with WriteAnalog(0.0)
Duet3Firmware_MB6XD.bin

[Amagatth]

@timschneider thx for the file i apply it

[Amagatth]

@Amagatth it work ! now m18 engage break !

[p8blr]

@T3P3Tony

(1) 6XD
(5) 3HC
(2) 1XD
raspberry pi 5 in sbc mode

Z motors and brakes on 6XD (out3-6)

[p8blr]

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

[timschneider]

@p8blr
hi maybe you try the 3.5.3 rc-1 the fix is included

https://github.com/Duet3D/RepRapFirmware/releases/tag/3.5.3-rc.1

https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-RC#reprapfirmware-353-rc1-changes-since-352

M17 did not energise the motor brake solenoid (issue 1023)