Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Jog behavior in motion programs
#1
I am finding the documentation unclear on this topic. In the software reference it says, "If the top-level program is a motion program, the initial commanded acceleration profile for all motors must complete before the next command in the motion program is executed." for all jog commands.

However I am finding that indefinite jog moves (jog+/jog-) behave this way, while jog= and jog: wait until the jog is complete before moving to the next line. Is this an error in the manual? Specifically, do I need to have a while(Motor[x].InPos == 0) {} after a definite jog in a motion program if I want to wait for it to end before continuing?
Reply
#2
Thank you for finding and reporting this. Yes, the manual is in error on this for the definite jog moves.

Remember also that if software overtravel limits are enabled for a motor, an indefinite jog command (jog+ or jog-) is automatically converted to a definite jog command to the software limit.

The key factor is the state of the Motor[x].Desired.TimerEnabled bit. It is this bit that must go to 0 before the motion program will process the next line. This bit is 1 if the motor is presently executing a move section of definite time. This is always true for the acceleration and deceleration sections of any jog move. It is also true for the constant velocity section of a definite jog move, including those automatically converted from indefinite jog moves. It is NOT true for the constant velocity section of an indefinite jog move.

The Motor[x].InPos status bit requires that the TimerEnabled bit must be 0 as one of the conditions for it to be set to 1, but it also requires that the Motor[x].DesVelZero bit be set to 1 and that the following error be below the InPosBand threshold. These last two conditions are not used for the automatic sequencing logic.

You can add the explicit logic you suggest if you want to consider the following error threshold as well. You could also set the Coord[x].InPosTimeOut value greater than 0 if you want PMAC to do this automatically.
Reply
#3
Thanks, that clears it up!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)