Do you think NI can fix my PLL?

Hello Mike,

And in the message body he writes "I have considered contracting out the PLL design to a well known control expert outside of my company".

Sorry if it rubbed you the wrong way. It was just examples, not advertising. Besides, I am not "the" expert on this stuff anyway.

Um, perhaps I didn't word things clearly enough. I am looking at hiring a consultant who is a control expert, who will help me to correctly design the analog system. A co-worker is trying to find a way to get it done using NI.

Thanks for the reply, Chris. Sounds like a fun system, and I think you are the most competent person around to handle the problems. Might be hard to find an ouside consultant who has the foggiest idea what you are doing:)

I'm surprised Labview has it's own operating system. I thought it was tied to Windows.

Still don't trust their approach. They have not demonstrated talent at any methods other than vendor lockin in the past. Regards,

Mike Monett

The PM motor was driven with a linear amp, a transistor boosted power op-amp, like you speak of below. The drive for the brushless motor is an analog PWM drive. Thus, it's speed reference input is analog, rather than digital. I selected this because I anticipated that a sampled reference input would cause trouble, both due to sampling rate and resolution.

The PWM frequency is 33kHz, and the analog BW of the drive's reference input is 2.5kHz. This is miles above the 1 or so Hz that might ultimately be the PLL BW.

The drive is operated open-loop, meaning that it doesn't look at the motor speed at all. It just outputs a voltage proportional to the reference input voltage. This is how I did the PM motor. The PLL loop compensation filter took care of the rest.

Considering the tremendous inertial load on the motor, a 136mmx2.54mm aluminum disk, I think it's unlikely that torque jitter introduced by the high PWM frequency.

There is another wierdness about the drive however. It appears to actually operate in current mode. That is, when configured for open-loop operation, internally there is still a current loop closed. The PWM duty feedback is then fed to an outer loop, which tells the current loop what current to produce to satisfy the outer PWM duty loop. That is how it keeps itself always inherently current limited. It also has some 2x peak current capability, so if the outer loop whether it be speed or PWM duty commands an excessive current, it will deliver

The point is that in open-loop mode, from the user's perspective you are just setting the voltage on the motor according to the reference input. But internally there are two loops. I have not been able to measure the actual dynamic response of the voltage change at the motor terminals in response to changing the ref input. That is because the differential PWM signals are difficult to measure. I have been able to use a scope to get RMS measures of the PWM signal for static conditions, which is how I determined there are some nonlinearities in the DC transfer. But my only HV differential probing ability is via a Tek probe that needs to be powered by the scope. So I can't filter it before it gets to the scope to see how the average looks when applying a square wave to the ref input for instance.

You can get the data here:

Some of the details of how the current limit works are hidden on the diagram, and there are also a typo or two. Took me a good while to figure out how this drive works!

Hello Chris,

That's how I understood you. Both ways can work. I'd call someone like Tim. If he isn't available I am pretty sure he can suggest another consultant. I don't do much in control gear and the folks I have worked with are far away from California.

The first is OK. The second is going to be a challenge, especially when locking two wheels together.

Different inertia? Loss of damping or friction when the brushes are gone?

Maybe this has nothing to do with it, but whenever I tried cascading two pll's I always got into trouble. When one loop is locked to another, it seems to need a bandwidth 5 to 10 times higher than the first loop. Otherwise it goes crazy trying to follow the first one. It may appear stable at the beginning, but eventually it starts building up an undamped response until it limits. So I'd be wary of considering the problem solved until evey little nit has been uncovered:)

Anyway, keep posting. Each reply gives more information that might lead someone to the answer. Regards,

Mike Monett

Hello Mike,

I believe what Chris means with their FPGA solution is this:

As far as I understand LabView realtime modules do not run on the PC but on connected NI hardware. That does get expensive though.

Oh good. I can make snippy comments about NI now.

the drive itself will be horribly non-linear open-loop, with the worst performance around zero speed. if you do some googling on dead-time compensation, you will see why. At low speeds both the switch Vce (or Vds) and interlock time create huge errors in the actual output voltage waveform.

years ago I made up some little 8th-order bessel filters, 50R in-and-out. These plugged nicely onto the end of a Tek P5200 diff probe, and allowed me to look at what was going on when I needed to solve a problem similar to this - it was a regenerative rectifier with 2.5% line chokes, so a 2.5% voltage error caused a 100% current error. That made me work very hard on dead-time and Vce compensation; a

Please do. ;-)

Best regards, Spehro Pefhany

Hello Chris,

That is fairly normal. It is the same principle that current mode DC-DC converters use. An inner loop maintains the max current (in their case the inductor current) and then there are usually two outer loops. One for voltage control, the other for load current limit. Works fine.

The schematic in your posetd pdf file shows the integrator before the PWM (U4). I think it would help hooking a scope to its output and see how that behaves. On the photo it looks like the black cover comes off easily. If you find some unruliness there you can probe pot 2 and the left side of the 10k in the current feedback loop to see where it's coming from.

I like the address of that company (Calle Tecate). Now I am thirsty...

I think that National Instruments knows that if you buy their system they will get paid whether it works or not. Of course your "well known consultant" (blush blush) gets the same deal -- or at least he does unless his rate is about 4x the usual.

I'm sure that the NI sales guys are taught to say "yes" to everything. Further, I'd be willing to bet even odds that they really aren't that good at control systems. But the majority of their customers are worse, so normally they'll meet with success, and their help screens sure are pretty.

It can make a lot of sense to implement control loops digitally -- you can change things around easier, in a production environment you can severely reduce the number of different boards you have floating around, you get advantages of thermal stability and controllable internal precision that just can't be beat, and it's often easier to instrument your application than it would be to build instrumentation into your hardware.

But we're talking about a control loop that needs to turn over at 400Hz, assuming one update per revolution. That can be comfortably handled by a little fixed-point DSP chip or even a 16-bit micro if it's not doing much else (or a PIC, if it's not doing _anything_ else). Using rack-mounted chassis with multiple FPGAs in them is like hunting squirrels with a .50 caliber machine gun*.

Having said that, this application might be just perfect for analog hardware, particularly if you're only ever going to build one. Even if you were going to build a gazillion of them you're obviously more comfortable with analog controllers, so that's how you should prototype it.

• Except that in the squirrel case you don't get something to put in the pot at the end of the day.

Less friction, more inertia now. But also very different motor constants.

Oh, I wouldn't be attempting to lock one wheel to another, but both to the same reference clock. So that wouldn't encounter the problem you are mentioning.

Thanks for the input.

-- snarping snipped --

I think the root of your problem lies in the amplifier.

Your brushed DC motor system has magnets attached to the case, a thingy wound with coils attached to the shaft, an amplifier that delivers current to a switch, and a switch that directs that current to the appropriate coils depending on the angle of the shaft with relation to the case (and hence the magnets with relation to the coils).

Your brushless "DC" motor system has magnets attached to the shaft, a thingy wound with coils attached to the case, sensors that tell you where the shaft is in relation to the case, and what sounds like this gawdaful mess of electronics interposed between your torque command and your coils.

You say you're driving the brushed motor with a power op-amp that's being driven by your torque command -- why not do the same thing with your brushless motor? Get three power op amps that are big enough to handle the current, take the signals from your motor's position sensors and commutate your drive current (or drive voltage) command with an appropriate complement of 405x switches, and do the whole thing linearly. You won't have any concerns about the internal PWM of the drive doing weird things because there won't be any. You won't have to worry about internal sampling in the controller, or weirdo loops, or any of that, either.

I suspect that if you do this you will find out two things: one, the room will be warmer when the system is running, and two, the brushless motor/amplifier system will act a whole lot more like the brushed motor/amplifier system did.

What's this PWM crap, it's slow enough, why not an EC motor driven by a VCO?

...Jim Thompson

Hmm. When I measured the motor's speed vs. ref. voltage to roughly approximate the motor voltage constant (with no load on the shaft the Kv is very close to V/RPM, don't need to subtract out current*winding R) then the result was larger at low speed than high speed. Converged toward what I expected at high speed. It this opposite or consistent with what you'd expect based on the dead time?

Hmm, since the drive servos PWM duty (at least that's what the blok diagram says) instead of some actual measure of motor voltage, then it could very well be that voltage is not linear to duty. Let's see. As the percent of time spent in dead time vs. on-time decreases with increasing duty, ie higher speed, what does that predict for the effective motor voltage constant one would measure taking the motor+drive combo to be a black box?

It's late, I have to go home or my wife won't beat me. I'll try to think about this again later.

Thanks for the input.

Yeah. I don't have that luxury. I have to meet and pee away more time with NI next week. Maybe two different days for two different "alliance partners" Ugh! Don't they know this isn't a wise use of time?

Here's a crude analysis:

V* = setpoint voltage

Vdc = DC bus

D* = setpoint duty cycle = V*/Vdc

V = D* x Vdc + (1-D*) x 0V

all OK so far. But we end up slicing dead time off of the demand duty cycle:

D' = D* - 2 x (Tdead/Tperiod) = D* - 2 x Ddead

and the switch voltage causes an error too:

V' = D' x (Vdc - Vce(I,T)) + (1-D') x Vce(I,T)

The Vce error is usually nowhere near as big as the dead time error, as Ddead is constant, and D* gets small for small V*

During the dead time, the actual output voltage is either -Vdiode or Vdc

• Vdiode, depending on the current polarity (which ends up choosing which of the upper and lower diodes to commutate to).

OK, its not that crude an analysis.

S.K. Sul has written a number of good papers about dead time compensation; the guts of it is this:

D = D* - sign(I)*[Tdead/Tperiod + 0.5*(Vce(I) + Vdiode(I))/Vdc]

(plucked from one of my older lab books)

When I compensate for this, I simply add in a magic number (Hookes variable constant) to my calculated duty cycle, using sign(I) to decide whether to add or subtract it:

D** = D* +sign(I)*HVC

D = D* IFF HVC = [Tdead/Tperiod + 0.5*(Vce(I) + Vdiode(I))/Vdc]

Some of the sexier interlock compensation schemes wrap a PI controller around this magic number, but I got good results initially using a tuned-on-test "constant". I ended up getting fancier just by using Vce(I) and Vd(I) rather than Vce0 and Vd0, which helped.

:)

you're welcome.

If you can figure out a way to deal with the nonlinearities of this controller (say by replacing it with one that has dead time & Vcesat compensation), you ought to be able to head that stupid idea off pretty early. Betcha a replacement controller would be cheaper :)

Cheers Terry

I'll kick myself when you tell me, but what's an EC motor? Electro-Convulsive? A big hysteresis motor would do, but they can be pretty dang inefficient -- one that could put out 200 watts might waste more power than my linear amp suggestion.

I had considered suggesting driving the brushless motors with a VCO, but that leads to startup problems, which are complex to solve, then you're back to nasty complex problems -- unless whatever an EC motor is solves that problem.

Given that the problem originates at a research lab I'm assuming that getting something that works with a minimum of effort trumps developing the World's Most Elegant Circuit.

Which appears to be almost an "industry standard" drive topology. Even the packaging varies little between vendors.

Well it was simple with the PM motor, and at only about 45W delivered, a relatively small and easy to manage heat dissipation.

Get three power op amps that are big enough to

Wow. I never thought of doing it that way. Very interesting. I wonder how long it will take me to figure out how to do the commutation...

Yes and yes. I didn't think seriously of attempting a linear drive for this thing simply because PWM drives are the norm, and I didn't want to mess with figuring out commutation logic when I could possibly avoid another case of reinventing the wheel. I also thoroughly expected it wouldn't be difficult to use an off-the-shelf drive. I get enough flak for making custom stuff as it is. Once in a while I pick something off the shelf, and whammo! Shouldn't have done that.

But seriously, isn't using minor loop synthesis (Bill Sloman, where are you?) and using the drive in it's intended application as a speed servo a suitable way as well?

As I see it there are three drive approaches for a motor (the following is as much a question as a statement of what little I know so feel free to educate):

1. current drive -- this is most commonly used for position servos since acceleration is proportional to torque is proportional to current. Position servos like to be able to directly control acceleration.
2. voltage drive -- this is used in speed servos since speed is almost proportional to voltage with the minor complication of the terminal voltage not being the same as the back EMF. I started using this rather than current because that's what was done in the Unitrode app notes that got me started on this odyssey.
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.

This seems to be a very compelling approach. Also, it allows one to use off the shelf PWM drive hardware with all it's nice features such as current limiting, very minimal power dissipation, and small package size.

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.

In a time crunch, which makes more sense? Building amplifiers, or building F-to-V converters? Or maybe neither if there is a speed servo drive that can take my encoder signal directly. But that still leaves the slow wheel with it's lack of anything but the hall signals. This wheel does however have the advantage of requiring much less power, so a linear custom concoction might be workable.

The amp building looks like a lot of work. I suppose here it would make sense to first see what kind of ready-made linear DC amps are on the market. This also would change my rough sketch of what the final system package would look like to a larger volume. This may be tolerable.

Here's something:

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: