Motion Control and Motor Drives

cancel
Showing results for 
Search instead for 
Did you mean: 

Why are my steppers misbehaving in closed loop mode, but work fine in open loop

I have a 7344 controlling a 4 axis prototype machine, which is configured with 50,000 steps/rev and linear encoders providing 50800 counts per inch. The physical properties of the machine are less than perfect (prototype!), so there is a considerable amount of backlash in the hardware (about 0.008" - 0.010").

The observed behaviour is as follows: when repeatedly blending in the X,Y plane using vector space 1 in closed loop mode, an axis will be driven (uncommanded) to the zero encoder reading (home position) occasionally (about 1 move in 600). I have kept a log of the commanded positions being passed to the controller (via the flex_load_vs_position function) and a move to zero is not being com
manded. The application is single-threaded, so there is no chance of race conditions. The ready state of the board is being confirmed by means of the flex_check_blend_complete function call before any blend is commanded. The programmed relationship between steps and counts/revolution have been independantly confirmed as being correct.

An A-B-A test with the only change being to initialise the X & Y steppers in open loop instead of closed loop then 'works' - although the physical positioning of the hardware is unsatisfactory due to the physical characteristics of the prototype machine already mentioned, hence the necessity to run closed loop.

I am inclined to interpret the evidence as suggesting that the 7344 is causing an 'occasional' uncommanded move to zero as a result of some interaction between pull-in moves and commanded position on a system where there is a considerable degree of 'elasticity' between the commanded position and the achieved position allied to a rapid-fire de
livery of blend moves.

This problem can be replicated under versions 5.0.1 and 5.2 of the FlexMotion software.

I can clearly run without bumping into the problem by running open loop, but unfortunately that is not acceptable in this situation. Any ideas, anyone?
0 Kudos
Message 1 of 7
(3,501 Views)
The motor will stop when it hits the home/zero position. Now because of the closed-loop and backlash if the pull-in move goes out of the move complete window and hits the home switch the motion will stop. You can over come this by increasing the move complete window.

Is there any chance that the encoder is messing up, because the motion controller had been tested for consistency at way more higher specs and I don't expect this behavior.

Pavan B
Applications Engineer
NI
0 Kudos
Message 2 of 7
(3,501 Views)
Hi, and thanks for coming back so promptly. I think I need to give you some more information - sorry if it turns into a long post!

The system behaviour when it 'misbehaves' is that it starts the anomolous behaviour well clear of any home or limit switch (>6"). When it 'goes wrong', it then slews one or both axes to the zero position. Having arrived at the zero position, it then carries on with the next blend without killing the motor.

The initialisation functions include a seek to home switch, a search for the nearest index point, and a zeroing of the encoder count at the index pulse: hence the zero point is a little displaced from the home microswitch.

I believe that once the system has 'gone wrong', it is stopping at the zero point *not* the home switch.


I have carried out some further tests that may be of help:

If I place a large (1 sec) inter-blend delay in the calling functions, the anomalous behaviour is not noticed. However, the start/stop nature of each move means that this test is knocking the bejezus out of a rather fragile prototype machine, so I can't do this too often!

The encoder positions are being read back on each move cycle and monitored, and they are not showing any anomolous behaviour, so I don't think they are the culprit. I have placed a 'scope on the quadrature encoder inputs and the edges are good and sharp with no real indications of noise.

I could test with a blend factor other than -1 if you think that might be illuminating?
0 Kudos
Message 3 of 7
(3,501 Views)
Hi, and thanks for coming back so promptly. I think I need to give you some more information - sorry if it turns into a long post!

The system behaviour when it 'misbehaves' is that it starts the anomolous behaviour well clear of any home or limit switch (>6"). When it 'goes wrong', it then slews one or both axes to the zero position. Having arrived at the zero position, it then carries on with the next blend without killing the motor.


The initialisation functions include a seek to home switch, a search for the nearest index point, and a zeroing of the encoder count at the index pulse: hence the zero point is a little displaced from the home microswitch.


I believe that once the system has 'gone wrong', it is stopping at the zero point *not* the h
ome switch.


I have carried out some further tests that may be of help:


If I place a large (1 sec) inter-blend delay in the calling functions, the anomalous behaviour is not noticed. However, the start/stop nature of each move means that this test is knocking the bejezus out of a rather fragile prototype machine, so I can't do this too often!


The encoder positions are being read back on each move cycle and monitored, and they are not showing any anomolous behaviour, so I don't think they are the culprit. I have placed a 'scope on the quadrature encoder inputs and the edges are good and sharp with no real indications of noise.


I could test with a blend factor other than -1 if you think that might be illuminating?"
0 Kudos
Message 4 of 7
(3,501 Views)
could you please call tech support via ni.com/ask
0 Kudos
Message 5 of 7
(3,501 Views)
Hi, we noticed the same problem in a XY table using steppers in closed loop during blending moves. But unlike your application, we have 2 threads calling FlexMotion API. At a random series of blended moves, one of the axis goes to zero position (encoder) and then go back to exactly to the previous position. Subsequent blended moves are not afected. We could't identify the cause, but operating in open loop we didn't noticed this effect. Please let me know if you have identified the cause of this behaving.
0 Kudos
Message 6 of 7
(3,501 Views)
How strange???
0 Kudos
Message 7 of 7
(3,501 Views)