Dynomotion Forum

Tom,

This is a weird scenario that might be causing some freezing issues we’ve been chasing for some time now on our current KFLOP system.

There are many Move() commands as well as coordinated motion move commands that execute absolute moves and immediately followed by a while loop that waits for the move to complete.

For example:

Move(axis_x,5000);
while(!CheckDone(axis_x))
{ //wait for motion completion}

Using Kmotion to observe the Axis status, we noticed that after a motion command has been executed, the Done flag on the respective axis does not get checked. And since the loop condition never gets met, we’re clearly stuck in the while loop forever. To manually get out of the loop, simply disabling the axis from within Kmotion’s Axis window and re-enabling it allows it to end the while loop since it triggers the Done flag.

In our observation, we’ve finally narrowed it down to points AFTER a motion completes its move (it physically gets to the desired position successfully).

Are there any known cases that might cause the CheckDone() function to not return a value when in fact it is done with the intended motion?

Is the method of the while loop condition the proper way to check for the case?

As a redundant or alternative option to the CheckDone() function, are there any other suggestions to break the loop? Perhaps using absolute position of the encoder feedback to confirm and break? Additionally there are instances of COORDINATED MOTION, and using position checks might be difficult as all 3 axes positions need to constantly be polled and fall between a range.

We’re running 4.34i

Thanks in advance Tom.

Hi mekanisms,

I'm not aware of any such issue.

Here are some thoughts and possibilities:

#1 - maybe a bug in your code corrupting something?

#2 - are multiple Threads commanding motion? Commanding two moves at the same time from different Threads could corrupt things.

#3 - commanding a MoveExp instead of a Move will never complete.

#4 - are you sure you always use valid Axis numbers?

#5 - a zero velocity, acceleration, or jerk might cause such a result

#6 is feedhold somehow active?

A Move is performed by creating and executing an array of Trip States (+Jerk, Acceleration, -Jerk, constant velocity, -Jerk, decelerate, +Jerk). Each Trip State consists of a data structure TRIP_COEFF which is basically a polynomial and amount of time to execute the state before going to the next state. When the array of states is completed the pointer to the Trip States will become null. CheckDone basically checks this for null. When you have the problem you might write a program and run it in a separate Thread to print out this pointer and if not null then also print the data structure members for a clue to see why it never finishes. See the definitions in KMotionDef.h for:

TRIP_COEFF *pcoeff; // pointer to coeff that interrupt routine uses, NULL if done

HTH