Properly stopping pvt mode & issuing a jog

Hi All,

 

Thanks in advance for your help. Below is a description of a bug I'm working on and some questions I have. I know that I've asked this question before, but through the process, I didn't feel that I got quite a clear answer, so I'm reposting with a clarified explanation to try and get the best possible help.

 

Thanks in advance for your help!

sincerely,

windell

 

First some background.

 

Attached is a motion program for one of the axes of our telescope. All macros are mapped to p-variables that interface with a C program, but I think they're names describe them pretty well.

 

Step 1:

We start this motion program using the "r" command. There it waits the while loop until the "P_PVT_HA_READY" flag goes high. This flag goes high once we have two position commands (we're calling them "buffers 1 & 2 are filled") for the same axis. The two position commands are linearly interpolated into 10 intermediate points which are stored in p-variables. these commands are sent to the pvt function via the motion program in an infinite while loop as more position commands come in and the buffers are loaded.

Step 2:

Then when we want to stop the pvt mode and issue a jog(do a large movement over to another star), we just issue an "abort" for the motion program.

Step 3:

then we change encoder feedback to use the absolute encoders.

Step 4:

then we issue the "jog" to the new star position

 

 

Problem description:

Where we are having a problem is the transition between stopping pvt mode and then issuing a jog. Sometimes (1 in 500 times) the jog doesn't create the trajectory properly and over accelerates the telescope axis even if the JogTa and JogTs variables have been untouched.

 

Questions:

1) By aborting the motion program, we're abruptly stopping it in the middle of issuing pvt commands. Is this a bad thing to do? What is a better way to do this? Is it possible to get an example?

 

2) When stopping the pvt mode, should I have the motion program have a flag in the while loop that issues something like the following:

X(current_position):0

before ending the motion program?

 

3) if the motion program is ending abrupting via the abort command, then there is little time between the previous pvt command and the following jog command. Would it be good to put a delay in between stopping the motion program and issuing a jog say 10 ms?

 

4) Blending isn't necessarily a requirement, but when going between pvt and jog, it would be nice to do this smoothly to prevent discontinuities in the currents, how do I do this properly? Do you have an example?

 

thanks,

windell

ha_pvt_p1.pmc

Check your Motor[x].AbortTa and Motor[x].AbortTs as these will govern the deceleration during an abort.

 

You could, instead of aborting the program, signal a flag that causes the motion program to enter a PVT-sculpted deceleration trajectory, and then allow the program to end naturally after the deceleration. This way you have custom shape control over the "abort". You'll have to add some logic for this in your program.

 

I already gave you an example of blending PVT with linear trajectories in your last post. Linear mode and jog moves share the shame shape, so you could just use linear mode within a motion program instead of breaking out and using a jog. My example was a motion program -- you can only blend between PVT and linear smoothly within the same motion program. This is impossible if you are aborting the program. I suggest you restructure your process such that instead of aborting and jogging, you just advance in your motion program to a Linear move that goes to the next star.

 

Here's some pseudocode to get you started:

 

while(1)
{
while(PvtTracking)
{
	// Do PVT moves to track star, then when finished, set PvtTracking = 0
}

// PVT Decel Section
pvt (decel_time)
x(decel_position):(pvt_to_linear_transition_speed)

// Load next_star_position and blend into transition move
Linear F(pvt_to_linear_transition_speed)
x(next_star_position)
PvtTracking == 1 // Set PvtTracking = 1 to resume PvtTracking; use synchronous assignment (==) to start tracking right as next PVT move is sequenced
}

Thank you Charles. I really appreciate your patience. Also thank you for the pseudocode. I believe that I can use it to help with stopping the motion program.

 

I did a check of the AbortTa ad AbortTs variables and they're set fine and don't change at all over time.

 

Part of my problem is that I didn't make the connection that a linear and jog share the same shape. How do you limit the acceleration between two What we really like about the jog command is that sending it creates a constant acceleration trajectory between the endpoints. This is a hard requirement for me. I did a read of the command in the software manual and it didn't mention anything about setting the acceleration profile for a linear command.

 

Question:

1) Lets say that we throw out the idea of blending the motion because you say that only linear mode can blend with pvt. It doesn't seem that I can limit the acceleration easily using a linear mode unless I write my own trajectory profile function (maybe i'm overlooking something?).

 

1) How do I properly do the transition between and pvt and jog? Sometimes we're locked in our own world over here so how you've seen it done before is fine.

 

2) For example, do I send X(current_position):0 and then stop the motion program (or just raise a flag to hold the motion program in while loop or something until pvt mode goes on again)

 

3) Then would I wait a certain amount of time before sending a jog or I can send it immediately?

 

Please keep in mind that this problem occurs only 1 in 500 transitions on average between pvt and jog so it is an intermittent problem and occurs when the trajectory of the jog doesn't shape properly and overacclerates the telescope. In fact right now we have not had a problem in the past few nights, but it always comes back. Upon checking the logs, all the position values are correct, the problem is occurring in the trajectory generation for the jog.

 

 

 

 

Check your Motor[x].AbortTa and Motor[x].AbortTs as these will govern the deceleration during an abort.

 

You could, instead of aborting the program, signal a flag that causes the motion program to enter a PVT-sculpted deceleration trajectory, and then allow the program to end naturally after the deceleration. This way you have custom shape control over the "abort". You'll have to add some logic for this in your program.

 

I already gave you an example of blending PVT with linear trajectories in your last post. Linear mode and jog moves share the shame shape, so you could just use linear mode within a motion program instead of breaking out and using a jog. My example was a motion program -- you can only blend between PVT and linear smoothly within the same motion program. This is impossible if you are aborting the program. I suggest you restructure your process such that instead of aborting and jogging, you just advance in your motion program to a Linear move that goes to the next star.

 

Here's some pseudocode to get you started:

 

while(1)
{
while(PvtTracking)
{
	// Do PVT moves to track star, then when finished, set PvtTracking = 0
}

// PVT Decel Section
pvt (decel_time)
x(decel_position):(pvt_to_linear_transition_speed)

// Load next_star_position and blend into transition move
Linear F(pvt_to_linear_transition_speed)
x(next_star_position)
PvtTracking == 1 // Set PvtTracking = 1 to resume PvtTracking; use synchronous assignment (==) to start tracking right as next PVT move is sequenced
}

Linear and jog have identical acceleration profiles. You govern the shape with TA and TS according to the attached slide:

 

 

There is no continuous transition between PVT and jog. The best way to do it is if your motion program receives the "stop" flag, you can use PVT to decelerate to 0 like you described. You should wait for the motion program to end (Coord[x].ProgRunning=0) and the motors to reach their in-position state (Motor[x].InPos=1) before beginning your jog moves. You can poll these from a PLC or host computer before commanding the jog.

Thank you very much Charles! I'm happy to hear that the linear and jog have identical acceleration profiles! I'll try the pvt to jog idea first and see if that fixes our problem.

 

I do think transitioning from pvt to linear is a much better and smooth idea. It would require me to change our code a fair bit though so I'll try the change with less risk first.

 

thanks again!

windell

Also of note – when you abort a PVT sequence in progress PMAC will decelerate to a stop. If the jog move starts before this occurs PMAC will use the current velocity, acceleration and jerk for the starting point of the jog move. You may want to verify that the stop is complete - not just that the program is complete.

Also of note – when you abort a PVT sequence in progress PMAC will decelerate to a stop. If the jog move starts before this occurs PMAC will use the current velocity, acceleration and jerk for the starting point of the jog move. You may want to verify that the stop is complete - not just that the program is complete.

In your logic around the start of the jog command I would wait for inposition and desired velocity zero after the ABORT before starting the jog. This plays into what Steve mentioned above. I have had the issue you describe only the resulting profile was a lot worse. It has to be a timing issue since it only happens 1 in 500 times.

Please note that checking for both in-position (Motor[x].InPos==1) and desired velocity zero (Motor[x].DesVelZero==1) is redundant, as desired velocity zero is included in the InPos bit per page 803 of the PPMAC SRM.

Thank you very much Charles, Steve, and CNCguru.

 

Charles-I just took a look at the entry in the SRM and I see what you're saying. Thank you for pointing the InPos flag out to me.

 

Steve-Right now It looks like most of the time not waiting for the InPos flag to go high has been ok. What you're saying about using the current velocity, acceleration, and jerk is interesting since I believe we're doing this a lot. I'm trying to investigate why rarely, the trajectory isn't coming out right.

 

Question: The velocity, acceleration, and jerk that is used for the jog trajectory, are theses values the last values from the trajectory of the abort slowing the telescope down or are these from the measurements that the encoders are giving at the time of the jog. The reason I'm asking is I'm wondering if encoder noise could be causing the velocity, acceleration, and jerk calculations to be wrong and is causing the trajectory planning to be wrong for a fraction of the jogs that are sent soon after the pvt.

 

Cncguru-The decision that I've put in before the jog is the following

 

while(GetInPos(pHAAxis) == 0);

where GetInPos is a function that looks at that in position bit.

 

This is a bit awkward, since the time for this while loop could take a variable amount of time depending on how long it takes the telescope to decelerate to a stop. I just implemented it in my code and sometimes it takes a whole 1 second to complete, which is a bit slow for me (I need to respond to incoming commands on a 50 ms basis). How did you implement your decision to move on and send the jog?

Note that Motor[x].InPos waits for the motor to be within the in-position band, Motor[x].InPosBand. This is 0 by default, meaning there needs to be literally 0 following error before the motor is considered "in position", so you may want to widen it a bit.

The starting conditions are based on "actual" so noise in the feedback could be a consideration.