Do you think NI can fix my PLL?

When you changed from brush to brushless, you also changed servo amps (I am assuming, here). The AMC brushless amp, you say has some non-linearities. You get one angle comparison every 2.5 ms, what is the sampling interval of the servo amp? And, what is the bandwidth? It seems like you may need a much higher bandwidth than the typical servo amp provides. A bandwidth of more than 100 Hz would be of little use in the typical CNC machine tool, but it sounds like a bandwidth of several KHz would be needed here. I am assuming there is some digital circuitry in the servo amp (has to be at least a PWM wave generator, comparator and FET drivers). If there is a microprocessor in the servo amp, it most likely is sampling the velocity command (I guess really a torque command in this case) at a few KHz at most. But, even the random relationship between the PWM wave and the motor commutation signals will produce some torque jitter that may keep your loop from stabilizing. Certainly, for .01 degree P-P at 24,000 RPM, I can't imagine any standard motion control servo amp can handle this job. There are special motors and drives used in polygon spinners and disk drive servo writers that provide much tighter control (maybe this is already what you are using).

I did a PLL motor speed control for a laser photplotter some years ago. It used the age-old Motorola PLL 2-chip set, and the phase comparator fed a linear amplifier (basically an op amp with current-boosting transistors). The speed reference, however, is a 1024 cycle/rev encoder, rather than one pulse per rev. One quirk I had initially was that the rate the motor was spinning only produced a back-EMF of about 3 V, and having the emitter of the low-side Darlington transistor grounded did not provide a current path for braking the motor. So, it introduced a non-linearity in the transfer function, and made the servo loop unstable. Reconnecting the low-side transistor to a -5 V power supply allowed the motor to be effectively braked, thereby making the transfer function linear over a larger range of 2 quadrants (the other 2 are now possible, but not used.) This speed loop has to be pretty stable, as the output of the

Jon

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.