Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Acc-24E2 EOT Limts
My PowerPmac system has 5 linear motors with overtravel limit switches connected to ACC-24E2 axis expansion cards. DeltaTau GPL direct PWM drives are being used to drive the motors.

I've use MotorSetup in the IDE to configure the motors, drives, and axis expansion cards. The motors run fine, but hitting an EOT sensor will not disable the drives.

The motor[x].pLimits all appear to point to the correct gate channel. If I monitor the EOT switches in the Motor status window, they change state correctly and the LimitStop flag will go high when one is hit. But if I jog a motor onto the limits, the drive will not disable. I need to kill it manually from the terminal. I first noticed this while I was setting up the motors, I was issuing small open loop commands from the terminal (#1out5) to test my commutation, and if the motor hit and EOT switch, the drive stayed active and the motor appeared to 'lock' into position on the EOT switch. Even if I hit the correct switch for the direction I was commanding (pos EOT for positive open loop commands and vise-versa).

Not sure what I'm missing, but shouldn't the drives always disable if an EOT is hit??


By default setting, the drives will not be disabled when an over-travel limit is triggered, instead the motor comes to a controlled stop and it will not move in the direction of over-travel limit which is set, but it will stay in closed loop mode and holds position.

In the newer firmware, Motor[x].FaultMode bit 2 will select whether to kill the motor upon over-travel limit trip or to keep the motor closed loop and come to a controlled stop. (This will be available in Jan 2011 release of the firmware)

Quote:Bit 2 (value 4) controls the action when this motor hits a hardware limit in closed-loop enabled mode when it has not already hit a software limit. If this bit is set to the default value of 0, the motor is “aborted” (decelerated to a closed-loop stop according to Motor[x].AbortTa and Motor[x].AbortTs). If it is set to 1, the motor is “killed” (open-loop, zero command output, amplifier disabled). The idea behind killing the motor in this case is that this should only occur when position information is lost, meaning that a controlled stop is not possible.

Sina Sattari
Hardware Engineering Manager
Delta Tau Data Systems, Inc.
Hello Sina,

Thanks for the clarification. My biggest concern is making sure the motors are protected as I continue to setup my system.

Now that you mentioned the new firmware and IDE, any word as to when it will be released?


We are doing our best to release it before the end of the month.

Sina Sattari
Hardware Engineering Manager
Delta Tau Data Systems, Inc.
Already in the firmware is the choice of killing (disabling) or aborting (controlled stop) when you hit an EOT limit (HW or SW) in open-loop mode. If bit 1 (value 2) of Motor[x].FaultMode is set to 1, the motor will be killed. If the bit is set to 0 (the default), the motor will be aborted. Different people want different things here, but remember that a controlled stop will virtually always be quicker and take less distance.

In closed-loop mode, generally you want to do a controlled stop on hitting an EOT limit. It is quicker, and easier to recover from (you can just jog it out in the opposite direction). With the software limits (set by Motor[x].MinPos and Motor[x].MaxPos) the motor is always brought to a controlled stop, in both the old and the new firmware. If it is possible ahead of time to see that such an event is coming, the commanded move will be brought to a stop at the limit position (not begin to decelerate as the limit is passed). For example, a "J+" indefinite jog command is automatically converted to a "jog to Motor[x].MaxPos" definite jog if the SW limits are active.

The new feature Sina mentioned in the upcoming firmware is really intended for those (rare) cases where the feedback has failed so that the SW limits cannot detect the overtravel (and no other limit such as following error has been tripped). In this case, it is not likely that a controlled stop is feasible, so it is best to disable the motor. In normal operation, you would hit the SW limit (which should be set for a position just inside the HW limit) and come to a controlled stop. In this case, even if you hit the HW limit during the abort deceleration, the motor would stay enabled.

Forum Jump:

Users browsing this thread: 1 Guest(s)