jog initial conditions

Hi,

My understanding is that the current motor velocity, acceleration, and jerk is calculated for the initial condition for a jog call. I've also gathered that these are calculated from the encoders position updates somehow so if there is encoder noise, this can throw off these calculations and send the jog off on a faster than intended trajectory.

1) Can someone tell me from what registers are the velocity, accelerations and jerk values are being calculated from?

2) A more specific question, if I change the value of the Motor[x].HomePos just before a jog is called, could this mess up the velocity, acceleration, and jerk calculations?

3) The resultant of these calculations, are they stored in the Motor[x].Desired. Trajectory Substructure Elements?

Much thanks!

windell

Your first understanding is basically correct; your second is not.

If the motor is executing a trajectory move (jog or home), the initial states for the new command come from the Motor[x].Desired sub-structure coefficients (and time within the move section). This all commanded trajectory information, and is unaffected by actual position issues like encoder noise.

You can change Motor[x].HomePos before commanding a jog move without messing up the derivatives. This is what PMAC does itself when the trigger is found in a homing search move. It writes to HomePos, then commands a move relative to the trigger position.

Pending trajectory move sections are stored in the Motor[x].New sub-structures, ready to be copied into the Desired sub-structure as the move execution progresses from one section to another.

Thanks Curt for explaining so clearly.

1) Here is my scenario.

If a motor is currently running on a jog that is close to completing as it is getting close to the new position so its decellerating, then

a) the encoders are switched to a different one,

b) the servo gains are changed while acting on that encoder

c) the HomePos is changed for that motor

d) a jog command to a position is issued to a new position

Would any of the stuff before the jog cause the derivatives to be miscalculated for the second jog?

It would seem that from your previous response that the answer is no, but I just wanted to make sure that I was understanding right.

2) The reason I'm asking is that for our telescope application, sometimes (once in >1000) jogs, a jog is issued behind another jog and the acceleration of its trajectory is way faster than what is specified for the Jog.Ta and Jog.Ts values. It causes too much current to be drawn and we abort the motion. I want to note that the previous jog hasn't yet finished, so were pretty much updating the end point for the move by reissuing the jog.

What is happening between the two jog calls is that we switch encoders, change the servo gains, and modify the HomePos for that motor.

a) We switch encoders because we want the finer resolution when we get close to our target, but for big movements, we stay with a courser resolution.

b) We change gains when we're close because we want a tight loop for velocity, but when were moving to a new target we ease off on the gains since the following error isn't critical.

c) We modify the HomePos because the previous incremental encoder builds up error as it is mounted to the telescope via friction drive, so we do an absolute encoder (can't slip) read and adjust HomePos for the motor so that the motor position is now consistent with the absolute encoder read. Pretty much we zero out any incremental encoder error this way.

3) Say the motor is at a stop, but in closed loop and then a jog is called to move that motor to a new location. How does it calculate the Desired sub-structure coefficients? Do these come from the velocity of the encoder values or the velocity of the motor position for this first point? I'm really trying to figure out how the initial position, and velocity and acceleration for the trajectory is calculated when the motor was not commanded to go anywhere.

I apologize if I'm asking my questions in multiple ways. I'm really trying to get as low level as possible to remove as many assumptions as possible.

Your first understanding is basically correct; your second is not.

 

If the motor is executing a trajectory move (jog or home), the initial states for the new command come from the Motor[x].Desired sub-structure coefficients (and time within the move section). This all commanded trajectory information, and is unaffected by actual position issues like encoder noise.

 

You can change Motor[x].HomePos before commanding a jog move without messing up the derivatives. This is what PMAC does itself when the trigger is found in a homing search move. It writes to HomePos, then commands a move relative to the trigger position.

 

Pending trajectory move sections are stored in the Motor[x].New sub-structures, ready to be copied into the Desired sub-structure as the move execution progresses from one section to another.

When you change encoders, are they scaled in the conversion table so that their effective scaling is the same when use by the motor? Otherwise the acceleration values change with the square of the scaling change, and jerk values with the cube.

Have you tried using the incremental encoder for the inner velocity loop and the absolute encoder for the outer acceleration loop? That is common in these telescope applications.

Have you tried using the load absolute encoder as feedback for a virtual motor whose servo output is cascaded to modify (offset) the position of a real motor that uses the motor incremental encoder as feedback? A couple of telescope guys have told me this gives the best results.

If the motor is at a closed-loop stop when the jog command is issued, starting velocity, acceleration, and jerk are all 0.0.

1) We do have the different encoder scaling factors such that the scaling is the same as seen by the motor. For the absolute encoder we keep the value at 1, and for the incremental we pretty much set the scale factor to counts_absolute/counts_incremental. So with no slip, they should read the same value.

2) Haven't tried putting the different encoders for the inner and outer loops. That does look like an attractive option. I'm troubleshooting an existing operational system so changing the way we use our encoders in the inner and outer loops might be somewhat of an uphill battle for me. I would need to be sure that this issue is caused by the encoder switching in order to get permission to modify how were using the encoders in the feedback loop.

3) This sounds like a position estimation scheme by using the virtual motor. It does sound interesting and I can see its benefits, but we haven't done anything to this exotic level.

4) In between two jogs what would the velocity, acceleration, and jerk be? Would the last trajectory velocity, acceleration, and jerk values be passed to be the initial conditions for the next consecutive jog?

When you change encoders, are they scaled in the conversion table so that their effective scaling is the same when use by the motor? Otherwise the acceleration values change with the square of the scaling change, and jerk values with the cube.

 

Have you tried using the incremental encoder for the inner velocity loop and the absolute encoder for the outer acceleration loop? That is common in these telescope applications.

 

Have you tried using the load absolute encoder as feedback for a virtual motor whose servo output is cascaded to modify (offset) the position of a real motor that uses the motor incremental encoder as feedback? A couple of telescope guys have told me this gives the best results.

 

If the motor is at a closed-loop stop when the jog command is issued, starting velocity, acceleration, and jerk are all 0.0.

You are probably going to have to use data gathering each time you do this change in order to catch the occasional problem.

To answer your question 4: Yes, it does use the present state as the initial state for the first section of the new move.