Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
execution of PVT position commands
#1
Hi,

I working on making my motion program more robust and I'm trying to find out the particulars about when each position command executes for PVT.

Background:
I've attached my motion program for reference.

There are comments in the motion program to try and help you out with what I'm doing. Essentially the motion program waits until a global flag is raised from the main C program and executes once. The main C program loops around at about 1 kHz. The position commands update at 20 Hz.

Question:
1) When the PVT move command are read from the motion program, are they read in all at once, and then executed internally one at a time? Or are they read one at a time and the next one is read when the previous move has completed?

2) If the motion program is looping at 1 kHz (as governed by that flag), the motion program will essentially be sending dulplicate positions a lot (the positions only change at 20 Hz). How does the PMAC deal with this? The current motion program seems to be working, but is there a better way to do this?

thanks so much!
windell


Attached Files
.pmc   ha_pvt_p1.pmc (Size: 2.51 KB / Downloads: 14)
Reply
#2
The key thing to understand about PMAC motion program execution is that it is automatically sequenced by the move. When it actually calculates equations of commanded motion from a move command in the program, putting these equations in the execution queue, it suspends calculations.

Calculations do not resume until execution of moves from the queue depletes the queue enough that a flag is set for the motion program to fill the queue again.

So if you have a motion program calculating a series of 50-msec moves, you will get a burst of calculations from the program every 50 msec, even if these calculations take less than a millisecond (which is typical). This is true whether the moves are in an in-line sequence or there is a single move command inside a loop.
Reply
#3
Thanks very much Curt. I think I'm getting what you're saying, but I want to clarify.

All my calculations for the position commands are being done in a C program that is running in parallel to the motion program. This C program modifies a bunch of global variables that the motion program has access to. The positions are sent to the PMAC by a remote computer at precisely 50 ms intervals. The PMAC does extrapolations into 5 smaller, 10 ms, moves based on the incoming positions from the remote computer. These 5 smaller increments are stored in global variables which are then access by the motion program.

1) So I'm pretty much trying to figure out the timing of the PVT move commands motion program. Specifically, when do they pull the value from the global variable and use it in the move?

From your explanation, it seems that when the previous PVT move finishes, the next move will lookup the global variables for the next move and then execute that move etc. Am I correct on this?

So if there are 10 PVT commands in the "PVT_TRACKING" part of the loop and the motion time for each of those commands are each 10 ms then it will take 100 ms for that loop to come back around?


2) The global variable for the linear commands is updated by the C program at 50 ms intervals. If my response to (1) above is true, then what happens when the linear command is moving for several seconds and the global variable is updating every 50 ms?

From your response above, I'm gathering that the linear move mode will not evaluate the next global variable update until the previous linear move is complete? If this is true, is the global variable evaluated just before the deceleration part of the linear move command? I'm trying to see if the linear move mode updates its end position in real time like a jog move that is issued every 50 ms.

thanks very much, Curt! I apologize if these are really dumb questions that can be answer in the manuals. I've taken a look and so far to me its a bit unclear.



(09-13-2015, 01:24 PM)curtwilson Wrote: The key thing to understand about PMAC motion program execution is that it is automatically sequenced by the move. When it actually calculates equations of commanded motion from a move command in the program, putting these equations in the execution queue, it suspends calculations.

Calculations do not resume until execution of moves from the queue depletes the queue enough that a flag is set for the motion program to fill the queue again.

So if you have a motion program calculating a series of 50-msec moves, you will get a burst of calculations from the program every 50 msec, even if these calculations take less than a millisecond (which is typical). This is true whether the moves are in an in-line sequence or there is a single move command inside a loop.
Reply
#4
You have basically got it. When execution of a programmed move in the queue finishes and advances into the next move, an internal flag is set for the program calculation to resume and compute the next move to put into the queue. If variables are used to compute this next move, it uses the values of these variables at this moment, having no way of knowing what former values of these variables were.

For linear moves, which can have multiple sections, the internal flag is set at the beginning of the blend from move N to move N+1, with move N+1 already in the queue. The queue must be longer than you think it is (so this point is not just at the final "blend" deceleration to stop) so that proper blending from one move to another within the set constraints can always be achieved.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)