Problem with changing modes in a motion program

I've been struggling with an issue that's been generating large spurious commands to a motor.

 

I have a motion program running in spline mode. It runs with a short move time (5 milliseconds), set up as follows:

 

spline (brMoveTime) spline (brMoveTime) spline (brMoveTime);

 

When the desired motion is complete, the code switches to linear mode using the following lines:

 

linear //revert to standard move mode

tm (brMoveTime); //; set move time

ta (brMoveTime);

ts (0);

 

A general function is then called to move the motor back to zero in linear mode:

 

linear; //just in case!

tm (stepTimeB); // set move time

ta (1000 * brVel / pmBrMaxAccel);

ts (0);

brPosition = 0; //set current commanded position

W(brPosition)

 

(The move time is calculated depending upon the size of the offset to be removed).

 

Using the code above, the commanded position (Motor[7].DesPos) can be seen to move to zero in the expected way, but then it simply blows up and goes to a huge negative value.

 

I've spent a considerable amount of time examining my code and found nothing obvious (to me) wrong. Eventually, on a hunch and thinking back to similar issues with UMAC, I added a "dwell 0" before the linear command (ie to separate the spline mode moves from the linear mode moves.

 

This has fixed the problem! Why? It seems pretty unsafe to me. I've never spotted anything in the manuals which says that you need to employ tricks like this when changing the mode - but maybe I've missed something?

Is there any chance of some response from DT on this?

Blending Spline mode into any other mode was never an intended move sequence. PMAC may attempt to do so but the velocities and accelerations do not match the move equations for each mode at the mode boundaries. There should always be a dwell of at least zero time between these modes. We do mention this in the Power PMAC training and this requirement will be added to the next release of the Power PMAC software and user’s manuals.

OK, thank you for clarifying that. I agree that it needs to be made clear in the manuals.