Do you think NI can fix my PLL?

I don't know. I haven't worked with much off-the-shelf stuff, and I don't know just how it's messing you up (or for that matter if there isn't something else going on). With your time crunch, slapping an encoder on the thing and seeing what happens may not be a bad way to go, but if the drive is interfering with smooth motor operation what's to say it won't continue to do so?

I think it's also because it's easier to limit current, and certainly more visible to your 'main' controller.

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.

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.

Electronically commutated

The design I did for Bosch was for the A/C blower in Mercedes vehicles. Up to 20 amps consumption.

Of course I was doing a custom chip, ultimately processed at National Semi in Scotland. Startup WAS a nasty problem, particularly with a blower cage that can be spinning the wrong direction when power is applied... but I'm clever ;-)

"Working" always trumps "theory".

...Jim Thompson

At 24K RPM, 3-phase, the timing between phases is just shy of a millisecond.

EC = electronically commutated

...Jim Thompson

-- | James E.Thompson, P.E. | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona Voice:(480)460-2350 | | | E-mail Address at Website Fax:(480)460-2142 | Brass Rat | |

Hello Chris,

That would be pretty easy, basically a precise pulse generator (_not_ the usual 555 thingie) whose pulse length is set to the shortest possible interval at the highest motor speed (minus some margin), and a non-leaking integrator.

How about measuring the time between two consecutive pulses and outputting a DC voltage proportional to that? Could be done via a counter and a DAC. The DAC would update at every pulse and the counter would be reset at that same time, to clock up the next episode. Or you could do it analog.

As suggested earlier I think you do have to check the quality of the PWM part and anything before that if you decide to go with a commercial motor controller unit. If they used an old one-shot as the PWM source that might be a concern. Take a good look at this with a scope.

Just FYI: The old National LM331 is a chip that I found to be remarkably clean in V/F and F/V applications.

Another option is to call the engineers at the company that made the motor controller, briefly describing what you want to do and asking them whether their product would be capable enough for that. They should know.

That's what the 'brushless' is in this case, unless electronically commutated means something even more specific.

The problem calls for an analog solution. If neccessary linearize the VCO. And to start with, measure the open loop response of the system, then do the math.

Rene

Oddly, I haven't touched a 555 since I was a kid. I use a few HC221 and HC123 when I need a reliable one-shot and can tolerate a few % variation in timing mostly due to cap tempco. Never had a problem with these.

I was thinking of using LM2907 with one phase of the 500pp/rev encoder signal directly. This should be easy enough.

Oh I see, by setting a constant pulse width for each encoder tick, then high speed->high duty cycle / low speed->low duty. So low-pass filtering that gives a smooth result.

I don't get why an integrator would be desired. That would accumulate V(t)*dt until saturation.

A low-pass filter != an integrator.

Actually I have a good digital F->V converter. In case you ever need an off-the shelf instrument, this is a really nice little gadget:

It has been indispensable in measuring the AC response of the motor. I can scope frequency vs. control voltage. Something like an LM2907 isn't good for this because to get the ripple down you need to kill the BW.

Perhaps the Ectron F->V should be fed 3pp/rev from the halls. I am also curious how close to 50% duty the hall signals are. It is remotely possible that I could get 6 pp/rev fairly evenly spaced.

Another nice F->V converter on the market:

Thanks as always for the input.

Good day!

Hello Chris,

I haven't either. But I must confess that I also used the 121 in the old TTL days. Not anymore, and I hope that can be chalked up to teenage sins :-)

But mind it's linearity error. +/-1% isn't exactly something to write home about.

Sorry, I meant integrator plus S&H. A lowpass will still let substantial ripple pass. Ideally you'd want nice steps where each level corresponds to the velocity, like the output of a DAC. That makes filtering a lot easier. So an integrator would start integrating, then hold and store when the one-shot time is up. Now it is reset and waits for the next pulse. You will be up to one pulse behind in phase when doing that, something that may matter in a clutch application.

Sweet. Even has selectable filters.

A good sample and hold helps.

Man, you guys must have a very comfy R&D budget over there.

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?

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.

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.

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.

Thanks for your input, folks!

Those should be quite easy, if that's all that's going on. You'd have to make somewhat conservative loop tuning, but you wouldn't have to back it off that much. The real question is how jitter do you get running open loop compared to what you get in closed loop. If you're not getting any significant jitter at all then you should be able to make a really slow loop and be done with it.

If you _are_ getting open loop jitter you need to deal with it. Then you need to ask what the frequency content of the jitter is, what the achievable bandwidth of the loop is, and what (if anything) you can do to reduce the amplitude of the jitter.

-- snip --

Well then I guess I'm still a sinner. But I do avoid the "pulses running all over the place" design method rightly castigated in AoE.

Oh yeah, that's not so hot.

Pardon my density, but all I see happening here is that I integrate the pulses, which are always the same width.

Oh wait, I think I get it. I integrate the not-pulse time! So I get a measure of the period of each cycle, with a small error equal to the width of the one-shot pulses. Then hold the integrator value in the S&H over the duration of the pulses, while the integrator also resets.

Right?

Now I have to go see how the LM2907 works again. I didn't try to understand it actually the last time I used one. Just needed a quick hack.

Heh, heh. Yeah. There was actually a dearth of equipment when I started. I've built things up quite a bit over 7 years. But haven't asked for anything over about $13k. Still no decent spectrum analyzer, but at least a trio of good scopes, a logic analyzer which I haven't used yet :-( and 3 function gens including one of those new Tek models with the graphical screens. A nice new Kronhite 8-pole Bessel filter. Still a bit low on power supplies. They get borrowed almost as fast as I buy them.

Well it will be easy enough to take another look at the open loop jitter. But it leads me to wonder, how does one know if the jitter is electrical or mechanical in nature? There is jitter introduced by bearings, etc.

I'll check this out next week!

Hello Chris,

Yes, sorry, I have worded it wrong. But that's what I meant. The one-shot time doesn't produce an error, only an offset.

You can get this all in a chip but I was never thrilled with their performance versus a discrete solution. Maybe Analog Devices has something nice, they are usually the ones who push the envelope.

Beats me. This is a pretty impressive thread about a rather nasty problem. My guess would be that the dead time in the PWM drive is the source of the problem, but I've not worked on comparabe hardware, and consequently my intuitions aren't worth much.

Initially one doesn't know, so one invents ways to test. I would expect that you'd be able to feel any jitter-inducing torques on your bearings by hand -- you could work out the dynamics to make an estimate of the torques involved. If you just _had_ to measure it you could set yourself up with a triple-pole single throw switch, get the motor spinning fast then cut it out of the circuit & try to estimate the 'jitter' as the wheel slowly spins down.

Note that from a purely control standpoint the source of the jitter doesn't matter -- from the control standpoint the only things that matter are the jitter's power spectrum and the amount that you can modify the loop's response to jitter. Stepping back from this a bit, though, if you have too much jitter what matters is how to reduce it (which is when you decide you want to know where it's coming from) and how you make a control loop that can be pushed to higher bandwidths.

"Teching"?

Being a technician... aka designing and building all the stuff the PhD candidates couldn't manage ;-)

...Jim Thompson

-- | James E.Thompson, P.E. | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona Voice:(480)460-2350 | | | E-mail Address at Website Fax:(480)460-2142 | Brass Rat | |

What is wrong with just saying, "I was working as a technician."? There is nothing wrong with being a technician, if your really good at it.

Seems everyone else knew what I said ;-)

...Jim Thompson