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

Question

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?

Answer 1

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?"