Motor[x].inPos for moving motor

[andyf]

The IDE help manual indicates that Motor[x].inPos will be zero if the motor is moving. However, if I perform an indefinite jog, or position follow a master signal, the inPos flag seems to toggle correctly based on FE and set tolerance. Is this a mistake in the help manual, or am I missing something?

[Sina.Sattari]

Please see the following post: http://forums.deltatau.com/showthread.php?tid=430

[andyf]

Thanks for directing me to that post. Based on that information, I would still expect that inPos=0 when I am performing an indefinite jog or position following. During these moves, the desVel > 0, and desVelZero=0, so the conditions for inPos (according to manual) are not met. Please clarify.

 

Basically, I am trying to understand if I can rely on inPos functionality to alert me when following error is out of tolerance for a motor that is continuously moving.

[Sina.Sattari]

andyf,

 

We have discovered that the Motor[x].InPos does not follow the same logic as we had previously in Turbo/Non-Turbo PMACs. We have fixed this discrepancy between the documentation and firmware which will be available in the next official release of the firmware sometime in March 2012. With this fix, the Motor[x].InPos status bit is only set high if:

 

1.) The motor must be in closed-loop control;

2.) The motor desired velocity must be zero;

3.) The motor must not be executing any move or dwell of definite time;

4.) The magnitude of the following error must be less than or equal to this parameter;

5.) The above four conditions must all be true for (Motor[x].InPosTime+1) consecutive servo cycles.

 

If you're not able to proceed with your project without this fix, Delta Tau would be able to provide you with a pre-release version of the firmware which includes this fix.

 

Regards,

 

 

[andyf]

Thanks Sina.

 

Regarding #3 in your reply. Would a delay for a specified time cause inPos to go inactive?

[curtwilson]

Yes, the execution of a "delay" command in a motion program causes the move timer to be active, which means that the InPos status bit cannot be true.

 

An easy way to verify this for yourself: bring up the motor or coordinate system status window in the IDE, then type into the terminal window something like:

 

&1 cpx delay 10000

 

You should see the in-position bit go false for 10 seconds.

[BoneSkier]

That seems like a side-effect of the "delay" command. I don't see why they are related, and it further seems like this will throw off logic that may be looking to see if motors are in position.

[curtwilson]

It's an intended part of the feature. The in-position featrue is intended as an asynchronous function, enabling the user to take some action as soon as the motor (or all motors in a coordinate system) has pulled within a desired tolerance at the end of a move, without knowing ahead of time how long this is going to take. This is logically at odds with a timed delay.

 

The typical use of the in-position function in a motion program is:

 

X10; // Move command

dwell 0; // Stop lookahead pre-calculation

while (Coord[1].InPos == 0) {} // Wait for in-position

LaserOn = 1; // Action when achieve in-position

 

Even if we permitted InPos to go true during a delay, allowing the changing the 3rd line of this example to:

 

while (Coord[1].InPos == 0) delay 10;

 

it would not provide any better functionality than what we have -- and would slow down the response due to the delay time.