Receiveing a "Following Error" when clicking HALT on MAX, motor does not energize

[dre99gsx]

I recently encountered this strange situation. When turning the following error on (value other than 0, say 200, etc), and I move a motor until it encounters this following error, its axis will be killed by default.

That poses a problem since an un-energized motor in my situation may cause some damage (it may drop down some parts on our fixture). I need to keep the motor energized after a following error.

I've tried using the STOP vi after any following error occurs, but I've noticed it may take 3 or 4 iterations of STOP to re-energize the motor.

Better yet, in MAX, if I constantly move the motor shaft by hand, back and forth, and try clicking "HALT", I will continuously see the "Following Error" light turn on, and the motor never energizes. It is constantly killed, even though I'm clicking on HALT.

Any advice would be appreciated.

[Jim Laudie]

What you'll want to do is make sure that your Following Error parameter under Trajectory Settings for the board in MAX is set to 0. This will disable the following error trip functionality and your motor should never be killed as a result of following error.

You mentioned that you're trying to reenergize the motor (I'm assuming after the controller has already tripped the motor due to your having exceeded the maximum following error). Really the only way to disable the "killed" status of the axis is to reinitialize the controller. You also mentioned some behavior in MAX that I'm not sure happened before or after the motor had been tripped.

So I'd recommend that you start by disabling the trip functionality and see if that takes care of things. Best of luck...

Jim Laudie
Applications Engineer, National Instruments

[dre99gsx]

Thanks for the reply. Unfortunately, I need the following error functionality to detect motor jams and slips. I can see a way around this by turning following error to 0 after a jam (or a following error has been detected), then send a "STOP" command, which re-energizes and motor and clears the status bits, then re-send the following error back to its original value for the next move.

I just wished there was an easier way around this. But, it seems to me that the HALT button on MAX (or even using the Stop.vi) is using the following error function, when it should avoid the following error altogether whether it is set at 0 or some value.

[Jim Laudie]

Thanks for the reply. Unfortunately, I need the following error functionality to detect motor jams and slips. I can see a way around this by turning following error to 0 after a jam (or a following error has been detected), then send a "STOP" command, which re-energizes and motor and clears the status bits, then re-send the following error back to its original value for the next move.

I just wished there was an easier way around this. But, it seems to me that the HALT button on MAX (or even using the Stop.vi) is using the following error function, when it should avoid the following error altogether whether it is set at 0 or some value.

I can see why you're interested in keeping the following error trip functionality set up. I'm still unclear on a few of the things you've described. For example, you mention that you "turn the following error to 0 after a jam." What do you mean by that? A jam means that a following error has been detected? And when we say "detected," do you mean that you've found an error but that it wasn't enough error to kill the motors? Or were the motors killed? And when they're killed, I'm thinking that you can't just magically get the motors going again by sending a stop command. And how do you "re-send the following error back to its original value?" I think that by understanding your approach better, I might be able to offer an alternative. Thanks for your patience...

Jim Laudie
Applications Engineer, National Instruments

[dre99gsx]

Not a problem... here is how the system is functioning:

a) Following error set to 500. (I want to kill the motor if it jams or experiences a following error greater than 500)
b) Motor begins to move.
c) It experiences a jam - following error shoots to 501
d) NI-Motion kills the motor, motor loses all power. (At this point, I need to maintain power in the motor, otherwise, the motor will drop from its vertical location).
e) I send a "STOP" command with Labview (Or using MAX by clicking on HALT). 2 times out of 10, the motor re-energizes using this command.

But, for the other 8 times, the motor attemps to HALT (and re-energize), but experiences another following error (somehow), which causes it to get killed again. At this point, I can keep rotating the motor shaft by hand, and pressing the HALT button on MAX. The motor never re-energizes and I keep getting a following error.

Now, the only solution I could think of is this:

** from above **
d) ..... motor is killed from a following error / jam ....
e) I reset the following error using a set_following_error.vi to 0 (thus, turning off the following error functionality).
f) Then, I send the STOP.vi command to re-energize the motor
g) Then, set the following error again using the same .vi as above, back to a value of 500.

This would work, but it will use up more processing cycles.

[Jim Laudie]

Hey, wanted to get back to you on something I'd mentioned earlier regarding the halt command. I'd stated that the only way to get past the killed state of the motors was to reinitialize the controllers. This isn't correct and I'm sorry for any misunderstanding on that. I had failed to clarify that the halt command will indeed reenergize the motors.

The halt basically will, first, move the set point or target destination to the current position of the motor and, second, reenergize the coils (because they'd been previously de-energized by the inhibit line going active due to your having exceeded the maximum following error). So, in the situation where you're continually moving the shaft of the motor and pressing halt on the controller, the command is resetting the set point to the current position of the motor. But because of your continual motion, the motor has moved more than your maximum following error by the time the coils are energized. The controller then finds itself in a state of having exceeded the maximum following error and the inhibits are fired again, hence the unresponsive nature of the halt.

In considering your situation and bouncing some ideas past R&D, we think that your best solution is to implement some sort of a brake on your axis. The whole idea behind monitoring the following error is for safety purposes. With a brake you'll be able to continue monitoring the following error and see the exact behavior you desire. What you'd need to do is wire the inhibit line to the brake such that when the following error trips the motor and the inhibits are fired, they will activate the brake and you'll hold position. You can then call halt to reenergize the coils and the brake will release at the same time.

Another way you could accomplish this would be to use an axis or stage with more friction. If the friction were sufficient to hold the load of the stage, then when the motors are de-energized when exceeding the following error, the slippage would be none to minimal.

The brake seems to be the best approach for you. I hope this is helpful to you and again apologize for being unclear on the halt command's characteristics in my previous post. Please let me know if you have any further questions and we'll get you the help you need.

Best of luck,

Jim Laudie
Applications Engineer, National Instruments