Recommendation for accessing enable pins for stepper brakes
-
I am working on a printer that uses stepper motors with integrated brakes on the Z axis to keep the bed from falling when powered off.
The plan is to have the stepper enable signal drive an external mosfet that will power the brake solenoid (disabling the brakes) whenever Z stepper motors are enabled.
I am looking for some advice on how I can connect a circuit for this purpose. I would like to avoid having to patch in a wire directly to the surface mounted stepper driver chips. The printer is using a Duet Wifi with expansion board. I noticed the header for the expansion has enable pins on the 0.1" headers, so I'm thinking of maybe soldering a wire to the back of those headers to connect the stepper enable to the mosfet gate.
Is there any issue with configuring the Z motors to be run from the expansion board? This machine has 4 stepper motors just for the Z axis, which I think I will drive with 2 separate drivers, having 2 motors in parallel per driver.
Also, as I understand the enable pin are active low, so I'm unsure the best way to differentiate between the board being unpowered and the stepper enable pins being active.
-
If using external drivers, this will be easy, like you have described - using the expansion header.
When configuring the stepper motors and their drivers, you have the option to make the enable pins for specific drivers run inverted from the norm (active low) - so if that is what your drivers use, it will be easy. Alternatively, you might want to build a simple signal inverting circuit (or use a Logic Inverter chip) in parallel to the stepper's enable pin (so the signal from the Duet Expansion, drives the enable for the driver as well as getting inverted for the brakes).As to the steppers in parallel, you just need to ensure your drivers can give double the current you need. Alternatively, you can perhaps try placing them in Serial, like the Duet does on its Z driver. This simply makes it easier and all current run through both (you just preferably need 24V). Stepper motors work with constant current, and does not really worry too much about voltages.
An alternative, would be to use a pin from the Expansion header - any that can be re-assigned - and then simply modify your homing files to always turn this pin on, when performing a Home action. On default firmware, moves can't happen before that axis is Homed. If you disable the brakes just before performing a Home, and then keep it disabled, it should work. If you do want to be able to disable the motors completely, and have the brake engage at that time, perhaps write a macro for that (otherwise, on my setups, I never disable the motors - I just let them go into the idle mode with reduced current [using the internal stepper drivers] or shut my printer down).
What type of linear motion does your Z axis use, that you need brakes? Is it perhaps belt driven?
-
Enabling/disabling the stepper drivers individually is done using commands sent over the SPI bus. There is also a common ENN signal connected to all the drivers on both the Duet and the DueX, but it transitions from high to low as soon as the power is good, so it wouldn't be suitable for driving a brake.
You could use a circuit to detect whether the drivers are supplying any voltage to the motor phases from the driver outputs, and activate the brake if there is none.
Alternatively, the firmware could be modified to change the state of an output pin depending on whether or not the Z motor drivers are enabled.
-
More details about the steppers and brakes:
The stepper motors being used are OK42STH47-1684BZ
I'm using 24V power for the motors, and the brakes also are for 24V. The product specs don't include the brake current, so I just measured the brake coil resistance which is 228 Ohms. At 24V, it should only be ~100mA per brake. So it seems that a single fan output(rated at 1.5A) should easily be able to handle 4 parallel brakes in terms of current draw. Should I be concerned about the inductive back-emf being an issue though?@Jacotheron
The linear motion is using openbuilds lead screws which have a moderately high helix (2mm pitch, 4 start, 8mm lead, 8mm diameter), and a large heavy bed that can potentially back drive them.@dc42 Thanks for the info. I think I would like to modify the firmware to support these brakes, so I'm starting to look into what I would need to change. I haven't looked at the inner workings of the code until now, but it seems that I would need to modify Platform::EnableDrive and Platform::DisableDrive to set one of the Fan outputs when the corresponding axis is being set.
I am debating whether to just do a quick bespoke hack to set the pin in those functions versus actually try to implement a reusable/configurable feature.
If it were to be configurable, I'm thinking it would require a new G-code (M-code) to map an axis drive to a brake output pin. That or modify and existing code with an added parameter, but I'm not sure if there is an appropriate command to tack something like that onto.
Also not sure the best approach for where to store that kind of mapping data, probably add new Brake.h and Brake.cpp files for this?
-
@thehans said in Recommendation for accessing enable pins for stepper brakes:
@dc42 Thanks for the info. I think I would like to modify the firmware to support these brakes, so I'm starting to look into what I would need to change. I haven't looked at the inner workings of the code until now, but it seems that I would need to modify Platform::EnableDrive and Platform::DisableDrive to set one of the Fan outputs when the corresponding axis is being set.
I am debating whether to just do a quick bespoke hack to set the pin in those functions versus actually try to implement a reusable/configurable feature.
If it were to be configurable, I'm thinking it would require a new G-code (M-code) to map an axis drive to a brake output pin. That or modify and existing code with an added parameter, but I'm not sure if there is an appropriate command to tack something like that onto.
Also not sure the best approach for where to store that kind of mapping data, probably add new Brake.h and Brake.cpp files for this?I agree, I can't think of an existing M-code that can be extended in a natural way, so it needs a new one. Something like:
Mxxx Xaa Ybb ... I0
where aa is the logical pin number used to drive a brake for the X axis, and so on (typically, only the Z axis would be specified). A negative value for aa would mean that there is no brake on that axis (the default). I0 would mean the pin output needs to be high to turn the brake on, I1 would mean it needs to be low.
As the functionality is so simple, I'm not sure it is worth creating separate files to implement this feature. Also the splitting of functions between modules is about to be reshuffled to implement the object model, and that will probably involve a new Axis class which is where this new functionality would belong. So I suggest you just add it to the Platform class for now. To configure it from the M-code, add a new function to the Platform class with a signature similar to Platform::ConfigureStallDetection and call that from the GCodes2.cpp file
-
Why not drive the brakes with motor voltage from the PSU, where the unpowered state is to activate the braking action? I'm thinking of a circuit like a relay that has a normally open/normally closed operation.
