Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Correcting for offset under external timebase
I have an external time base signal generated by a timing card that is fed into Delta Tau and used by a coordinate system for control of a motor. I am also using the Triggered Time Base feature to start an indefinite jog for that motor upon receipt of a separate single "go" pulse from a timing card.

To test how accurate this master/slave setup is working, I used the Position Compare feature of Delta Tau several times per revolution and fed the EQU output pulses back to the timer card where they are timestamped.

When I first ran my test, I noticed that the timestamped position compare pulses were about 40ms off what I would have expected. If I adjust the starting position of the motor to compensate for this, the offset goes away.

My question is whether the existence of this offset is normal or not. I was expecting no offset to exist since I am using the Triggered Time Base.
A couple of things to look at:

First, do you have significant following error in your servo loop for the motor? The time base feature ties the commanded trajectory very tightly to the external signal, but the compare pulses are generated off the actual position. There is potentially a difference here. You should make sure your velocity feedforward gain is set to minimize following error at speed. You will probably want to make sure your servo loop integrator is active during the move by setting Motor[x].Servo.SwZvInt to 0. This will ensure zero average steady-state error during the move.

Second, have you accounted for the acceleration time in the jog profile? If your acceleration time were 80msec (whether specified directly or from speed/accel rate) and your calculations assumed that the commanded jog profile instantly hit top speed, you would think you were 40 msec behind.
The tests I ran were at a speed of 8.192 mu/msec (1 rev/sec), and the FE peaks at +/- 8 mu. JogTa=-10 JogTs=-50. I used position loop interactive tuning to set the velocity feedforward.

I understand that the motor cannot hit top speed at the instant the time base is activated via receipt of the start trigger. However, I need the motor to "catch-up" so that it arrives at specified positions in each revolution within some tolerance from the theoretical arrival time relative to the receipt of the time base start trigger. My understanding is that the servo loop would do this, and thus eventually catch-up to where it should be.

I expect to see some difference (<5 ms) between actual and theoretical time of arrival at each position as the motor is rotating due to the latency of the triggers (start trigger and capture pos triggers) between the timing card and the Delta Tau. However, a difference of 40ms seems to0 large, and it gets worse the higher the JogSpeed.

I did notice that the difference between actual and theoretical timestamps remains pretty much constant (+/- 1ms) for a move at a specified JogSpeed.
Yes, you have an 80 msec acceleration ramp on your jog move (8.192mu/msec * 10msec^2/mu). So in the first 80 msec of motion, the commanded profile only advances as far as it would in 40 msec at top speed. Hence, you are a constant 40 msec behind what you want. Since this is in the commanded profile, which provides the set point to the servo, the servo cannot overcome this.

Set JogTa and JogTs to 0 to get a pure step in commanded velocity. Of course, the physical system cannot track this perfectly, but now the servo loop can cause it to catch up. You may have to play with some servo loop settings to handle the initial transient reasonably.
Thanks Curt, that did the trick.

I am curious now, what if the motor load is large/delicate such that I need to gradually bring it up to speed (Ta) or minimize jerk (Ts). What approach can I use that will still allow the servo to eventually sync up with the external signal?
Assuming that what you want is to end up tracking the signal as if you could have accelerated immediately to your target speed, since you will spend some time below this speed to achieve a properly controlled acceleration, you will then need to spend some time above this speed in order to catch up. Typically, this is done with an initial programmed move slightly above the tracking speed, followed by a move or moves at the tracking speed. The "overage" in the initial move should match what the lag would be due to the acceleration slope (a bunch of fun algebra). This needs to be done with blended programmed moves, as it is not feasible with jog moves.
If all you want to do is to move at a constant speed proportional to the input frequency, you can just use the "position following" function for the motor. The following function has special features to permit this kind of controlled syncing to the master. If you set Motor[x].MasterMaxSpeed to a non-zero value (higher than you need to move) to activate the limiting, and Motor[x].MasterMaxAccel to a non-zero value (that you intend to use), then when you engage the following with the master signal going at a high frequency, the motor will automatically accelerate at the specified limit rate, overspeed until it catches up, and then decelerate at the limit rate to achieve proper position lock.

However, I think that what you will want to do in your application will be more complex than this, so the more flexible external time base with programmed trajectories will be your preferred strategy.
Thanks Curt. Position following may work for us, but let me ask you a couple more questions:

1) Is there any support for "triggered" position following. That is, upon receipt of a trigger the following would be enabled.

2) If #1 is not possible, then it seems the best we can do is monitor for I/O and have a PLC enable following upon receipt of the trigger. Would this mean that slave position lock to master could be off slightly?

3) We will need to keep our master signal running, but change the gear ratio (MasterPosSf) occasionally. If we do this, and limit with SlewMasterPosSf, will the following algorithm automatically re-establish position lock (i.e. by over speeding, and then slowing down)?
To answer your questions:

1) While there is not a specific triggered position following function, you could use the triggered time base entry as the master encoder for position following. For the slave motor, Motor[x].pMasterEnc = EncTable[n].a (not EncTable[n].DeltaPos.a). While the entry is in the frozen or armed states, there is no change in the output value. For the entry scale factor on this one, you probably will not want to divide by an RTIF factor. For the slave motor, Motor[x].MasterPosSf is set to the number of motor units you want per table entry output unit.

2) Without this, if you use a software-based "trigger", you could be off by up to one period of the software routine that is monitoring. It is easy to get this down to a servo cycle. I don't know if that would be good enough.

3) You cannot guarantee recovering a position lock if you control the rate of change of the gear ratio with SlewMasterPosSf, because we don't keep track of how far the master moves each servo cycle as the ratio is changing. That is why I did not suggest that for the startup of following. Instead, disable the slew rate control by setting SlewMasterPosSf to 0, so you get a step change in the gear ratio, but limit the response with MasterMaxSpeed and MasterMaxAccel, so it can recover and re-establish position lock, as it does on the start.
Thanks Curt. I was able to make position following work with the trigger capture. I also tested changing the gear ratio successfully.

However, for my application, changes in gear ratio have to occur at a precise time, and therefore I am left with s/w monitoring of I/O to trigger each change. Based on my tests, this introduces a slip in the position following, relative to the time at which the gear ratio change trigger was generated. Is there a more accurate way to switch rates? Either via external trigger processing in hardware or at a predefined position?

For this application, the continuously rotating stage cannot be stopped to transition from one rate to the next (i.e. cannot freeze master signal again, and use trigger capture). After a change in rate, the rotation must return to a position locked state. However, that position is defined by mater signal change since the precise time at which the rate changed.

I am thinking I may need to use external reference pulses (separate from the master signal), and use the position capture feature of the delta tau to make position adjustments via custom motion program.

This is the kind of feature that made me skeptical that you could just use position following. I agree that you will probably need to use external time base with programmed trajectories, and the position capture feature to register the time for change triggers.
Looks like I have a working solution now. Here is what I did...

1) The timing card is always generating the same 32KHz signal which is fed into an open encoder channel on Acc24E3. Another pin of the timing card is connected to the user flag of the rotating stage channel. This will be used to generate a reference pulse after start and after gear ratio change, and process it using position capture (see below).

2) Start motion program
-Rapid move to reference position
-Config position capture for user flag of channel
-Config and enable following to master signal at initial gear ratio.
-Loop checking for poscapt flag to go active...

3) Schedule timing card to generate a single pulse at reference time that corresponds to when rotating stage should be at reference position.

4) When pulse occurs, loop in motion program detects it via poscapt, compares the homecapt value to the reference position, makes offset correction.

From this point on the slave is position locked to the master based on the reference pulse/position. I didn't use triggered time base because I wanted to use the same approach for the synching after start as I do when synching after rate change....

5) User requests rate change...which is passed down to running motion program and applied as gear ratio change. Once applied, rotation rate is correct, but not in sync with reference time/position.

6) Repeat steps 3 and 4

Another approach I considered was to have the timing card master signal be the desired rate, and have the gear ratio always be 1. Thus I would not have to pass rate changes to the motion program, but instead just re-program the timing card to a new signal rate. However, rates such as 1/8192 could not be exactly programmed to the timing card. This raised the question as to whether position lock gets worse if I use a slower master signal (one I can exactly represent in timing card) and a higher gear ratio. Any thoughts on that?

Long-term position lock to the master frequency does not get any worse with a lower frequency. Ultimately we are just counting pulses.

However, the cycle-to-cycle quantization noise (which completely cancels out over the long term) does get worse, and this can lead to rougher motion. It may require some detuning of the feedback gains, which could hurt your ability to reject disturbances. You would probably notice first that you cannot use feedforward as aggressively (but Power PMAC has a new low-pass filter into the feedforward section that is meant to ameliorate this).

Forum Jump:

Users browsing this thread: 1 Guest(s)