How to best handle Z-axis brake?

More
30 May 2018 14:22 - 30 May 2018 14:57 #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?
Last edit: 30 May 2018 14:57 by Sparky961. Reason: Added info regarding step/direction open loop setup

Please Log in or Create an account to join the conversation.

More
31 May 2018 02:37 - 31 May 2018 02:38 #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.
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.
# 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.
Last edit: 31 May 2018 02:38 by Sparky961.

Please Log in or Create an account to join the conversation.

Moderators: cncbasher
Time to create page: 0.064 seconds
Powered by Kunena Forum