How to best handle Z-axis brake?

More
8 years 5 months ago #111318 by Sparky961
The machine I'm working with has a ballscrew on the Z axis and no counterbalance. For the uninitiated, this means that with loss of power the Z axis drops VERY quickly unless the brake is applied.

The complicating factor is the use of Allen Bradley Ultra 3000 series drives and A/C servos in "self sensing" mode. At power up, the drive needs to move each motor a certain amount to commutate. The drives are set up as step/direction followers so this is essentially an open loop stepper system. The drives and setup can't be changed.

The brake needs to be disengaged during commutation, but I have yet to find an output signal from the drive that tells me it's trying to commutate. I hate to rely on a dumb timer or some other assumption at power up but maybe this is my only choice?

Please Log in to join the conversation.

More
8 years 5 months ago #111339 by Sparky961
The following are snippets from the solution I used. I'm not entirely satisfied with it, but so far it seems to be robust and I can't figure out anything to do that causes the Z axis to drop out of control. As I proceed with this project I'll be carefully watching it and thinking about any edge cases that are unsafe.
Code:
loadrt xor2 addf xor2.0 servo-thread loadrt lut5 addf lut5.0 servo-thread # Used to delay Z brake release before drive is commutating loadrt timedelay addf timedelay.0 servo-thread setp timedelay.0.on-delay 5 setp timedelay.0.off-delay 0

Note: I've never fully embraced HAL, so ignore my arrow directions if they don't make any sense. One day it will all click, I'm sure.

Z_Fault comes from the drive and signals a variety of faults. Whatever the fault, the brake is engaged until things are sorted out.

Z_Commutation_Complete is a signal output by the drive when it's done commutating. This could have been so much easier if I had a signal that told me it WAS commutating and had control of the axis.

Z_Reset is a Mesa card output connected to the drive reset input (on reset the drive does NOT hold the axis in place)

machine-is-enabled is unaltered from linuxcnc

z_brake_delay is a time delayed signal activated either by reset or drive enable. Immediately upon drive enable or reset the drive does not have control of the axis so the brake can't be disengaged. But soon after (about 5 seconds) it has control of the axis and is trying to move it to find out where it is. It can't do this with the brake engaged. So 5 seconds after reset or enable this signal goes high to disengage the brake so long as there is no fault, no reset, and the machine is enabled.
Code:
# Z Axis is more complicated due to commutation and the brake to prevent gravity runaway net machine-is-enabled => xor2.0.in0 net Z_Reset => xor2.0.in1 net z_enable_xor_reset xor2.0.out => timedelay.0.in net z_brake_delay <= timedelay.0.out setp lut5.0.function 0x220000 net z_brake_delay => lut5.0.in-0 net Z_Fault => lut5.0.in-1 net Z_Commutation_Complete => lut5.0.in-2 net Z_Reset => lut5.0.in-3 net machine-is-enabled => lut5.0.in-4 net z_brake_release <= lut5.0.out net z_brake_release => hm2_7i76e.0.7i76.0.0.output-10

Feel free to point out any potential improvements or major flaws.

Please Log in to join the conversation.

Time to create page: 0.094 seconds
Powered by Kunena Forum