Re: Do you think NI can fix my PLL? -- Details

Tim Wescott wrote:
CC wrote:
3. For a PLL, one is usually controlling a VCO, which produces a frequency (speed) directly proportional to input voltage. One also usually expects that the VCO response, ie., the frequency response of the phase, is not burdened by zeros/poles close to the desired PLL BW, so one can treat it simply as Kvco/s.

If a motor is put in a speed servo, then it would behave more like a true VCO than the first two cases. As long as the PLL BW was safely removed from the response rolloff (likely to be complex poles) of the speed servo, one can treat it as well as Kvco/s.

That's true, except that the motor's mechanical time constant is going to be pretty darn slow; unless you want to _really_ slow down your PLL response it's going to be almost as troublesome as it would be sitting at s = 0 in your current drive case.

But a linear system is at least a linear system. Basically, there needs to be some plan for elucidating if what I have at present is just a mediocre motor characterization, poor choice of loop compensation, or trouble with the slight nonlinearities of the drive.

Can you say anything from experience about the implications of "slight nonlinearities" such as let's say a -25%/+50% variation in DC transfer gain, coupled with a 10-20% variation in transient response on the rising edge vs. the falling? Does it seem that such nonlinearities would make it impossible to get a decent loop going?

Of course there needs to be a speed feedback path for #3 to work. As we know, there are issues with that. For my fast wheel, there is an encoder available, which would need an F-to-V converter. For the slow wheel, there would only be the possibility of getting 3 pulses/rev from the halls.

Could you use an external encoder on the slow wheel? They're certainly out there. You could even have the outside of the wheel notched and stick your own opto on it. For that matter, if you're going external, what about a tach?

> I was going to suggest just using the encoder output for PLL with a
> significantly higher sampling rate, then using a 'D' term in your loop
> closure. But that still leaves the question of what the amp is doing to
> the signal, which gets back to maybe a frequency to voltage converter
> being the right answer.

The most promising prospect here is to drill a ring of additional holes in the slow wheel at a radius where there are no present slits (we already have the image and speed sensor slits.) I am sure there is some available real estate. The practical problem for now is whether doing that, and then developing the mechanics and electronics is a time sink.

I don't think an encoder on the opposite side from the motor is possible, due to space constraints in the apparatus and also that the front of the wheel housing is a bearing holder. The substantial mechanical mods needed here would probably be more time consuming than drilling holes and adding a little LED and photodiode detector attachment.

So for SLOW wheel:

Step 1: Try another iteration of double-checking the motor+drive characterization (for a 1st order effort should need just effective motor voltage constant Kv and the time constant ? ). Feed these numbers into a PLL compensation scheme and see what we get. If it at least meets the very loose jitter requirements for the slow wheel (see update to specs below) then it is good enough for now. Switch focus to fast wheel.

Step 2: If it fails to meet jitter specs then we debate speed servo vs. modifying to add another fine resolution position sensor.

To summarize we have two different wheels. Here are the parameters and possibilities for each:

SLOW:

motor: Maxon EC 22mm 50W series, model 167130 32V, no tach or encoder
possible; only 3 pulses/rev from hall sensors
speed: 3000RPM
power: <<50W probably about 10-20W needed
voltage: only needs about 2.5V to reach this speed

jitter requirement: 1-1.5 degrees (have to check mechanicals on the large slit in the slow wheel vs. the narrow slit in the fast wheel)

This jitter is constrained by how much the slow slit can be out of alignment before it obstructs the view of the fast wheel's slit.

options:

1. Not sure if it can be put into a speed servo with only 3pp/rev feedback to undergo F-to-V. If so, this would be worth trying.

2. Since power is low, a linear drive wouldn't be too large or hot. Since time is in short supply, a big construction project for drive electronics is to be avoided. If a commercial linear amp ready made is available then the approach suggested above to do the commutation ourselves is viable. This might be the best method if the lack of finely resolved feedback is a showstopper. Thus this would be a true voltage drive motor PLL.


FAST:

motor: Maxon EC Powermax 30mm 200W, model 305014 32V
incl. encoder 500 pulses/rev (200kHz max)
speed: 24000RPM (motor maximum permissable is 25000RPM)
power: a lot, probably between 100-200W
voltage: need about 52Vrms to do this
current: would need 4A for 200W at 24000RPM

jitter requirement: about 0.58-0.72 degrees. This is constrained by how much error is tolerable in the Q-switch timing of the YAG laser. The Q-switch needs to be within about 4-5 us of the correct 200us timing. this may need to be a little tighter still, if they are using injection seeding on the YAGs. Have to check this out.

Of course, the two jitters add, so the slow may actually need to be better than I am estimating at this point.

options:

1. Speed servo using 500pp/rev encoder via F-to-V LM2907 and Advanced Motion Controls B15A8 drive. Advantage is small drive and avoids wasted capital for items already obtained. Should be fairly expedient. Wrap PLL around speed servo. What are the gotchas yet unanticipated?

2. Building a linear drive of this magnitude at this stage of the game is something I seriously want to avoid. Look into commercial options for plain linear amps?

The Aerotech linear drive is a possibility. However, if that works with the encoder to make a speed servo, what is the advantage over the PWM? One thing is that it might take the encoder directly instead of needing me to implement another circuit.

Need to find out if the Aerotech can operate open-loop.



Thanks for your input, folks!



--
_____________________
Christopher R. Carlen
crobc@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
SuSE 9.1 Linux 2.6.5
.

Relevant Pages

  • Re: Transformer attenuators
    ... and this may be used to limit the LF response. ... "Core saturation happens when the magnetic field in the core ... the applied voltage polarity remains the same for a ... *Magnetising current* is directly responsible for flux density. ...
    (rec.audio.tubes)
  • Re: 5U4GB vs. GZ34/5AR4
    ... is such a pain for you, no response is better than an insulting one. ... headroom, faster response, tighter bass, and more voltage with a GZ34. ... With slower recovery times, you get a natural ... The supply voltage drops when the note is played, ...
    (alt.guitar.amps)
  • Re: Log amp - why cant I stabilise it?
    ... > response in the audio range, ... You also have to rectify the input voltage, ... temperature stability will be poor, ... differential amp for log functions, you can do it with the same number of ...
    (sci.electronics.design)
  • Re: A FAQ for Xmas
    ... area of unity, infinite sum of all possible cosines, a height which is not discussed but which appears to be greater in magnitude than any voltage appearing in your circuits. ... In the systems that you deal with, what experimental evidence do you have that there are pulses with the attributes of Diracians upon which to base your theory? ... Having delta_t equal to 0 brings up mathematical difficulties, so we recognise that the important thing here is not E or delta_t alone, but the product E.delta_t, which is of course an impulse. ... As long as we know the value of the impulse, and as long as delta_t is short, the precise value of E and delta_t do not matter because the response of the system will be the same. ...
    (comp.dsp)