pause in blend motion routine

[ctsnc]

I am using a blend motion routine (derived from the example that ships with the board) to blend 3 sets of x-y points on two axes on a PCI-7344. The rountine works great except when I ask for movement in only the x direction or only the y direction. In both cases there can be pauses of 3 seconds or more between blend moves. If I have movement in the x and y direction, then there is never a pause. Why would this occur? For example if I am at 0,0 and the next set of points to belnd through is 100,0, then I will get a pause. However, if I the next point is 100,100, then there will be no pause. The stepper motors are being run closed loop at 10,000 steps/rev with 10,000 counts/rev on the encoders.

[Jochen]

I did some tests with a similar setup but I couldn't reproduce this problem with NI-Motion 6.1.3. (Which version are you using?). Also I haven't heard of a problem like that with earlier software versions.

Do you get the delay also when you are running open loop?
Are you using blend factor -1?

Best regards,

Jochen
NI-Germany

[ctsnc]

The blend factor is 0. Do you believe -1 could yield better results? I have not tested this in open loop. I have also noticed that when I request very small vector moves that I get the pause. I am wondering if it may be a problem with using a combination of 10,000 steps/rev, a small number or 0 steps to move, closed loop, and the velocity requested for the move?

[Jochen]

With blend factor 0 the axes decelerate to a stop and start the next move immediately after that. With blend factor -1 the acceleration phase of the next move starts as soon as the deceleration phase of the first move begins. In this case the axes don't stop between each move which is the main reason why blending is used. The disadvantage of this method is the fact that corners in the move profiles get rounded. The degree of this rounding depends on the acceleration/deceleration values.

Here is one possible scenario why the wait occurrs:

A short move is executed and during this move you load new trajectory parameters but this process isn't finished by the time you send the new blend command. In this case the move decelerates to a stop. In thi
s case the 7344 tries to reach exactly the target position you have specified for the move. As the resolution of your encoder is very high there is a good chance that the target position isn't reached exactly. Thus the board starts some pull-in moves until the position is reached (by default after three pull-in moves the board gives up). If your program would have been able to send the next blend command fast enough this sequence would have been skipped.

The pull-in moves are only executed when there is a difference between the encoder position and the calculated position. Thus they are only executed in closed loop systems.

Possible solutions:
1. Configure the "Move Complete Criteria" in the axes' trajectory settings in MAX to accept some displacement (deadband parameter)

2. Reduce the velocity for short moves or don't use very short travel ranges at all (this might not be possible).

3. If nothing of this helps or don't use blending at all. Use buffered contouring
instead (please refer to the shipping examples).

Best regards.

Jochen
NI-Germany

[ctsnc]

Thanks for the suggestions. I will try them and let you know.