Maker Pro
Maker Pro

Do you think NI can fix my PLL?

M

Mike Monett

Jan 1, 1970
0
Joerg said:
Well, he said he thought about handing it off in order to free up some
of his time. "...so I can focus on building other subsystems of the
project" were his words. Nothing wrong with that IMHO.

Most of the tasks that I am called out for as a consultant were
initially thought to be "something simple that needs to be fixed". Some
of them were (but not by the staff alone), others had a few hardcore
problems underneath the surface. It has happened that clients said at
the end "You mean, that's it?". But they would have had a hard time
finding it out on their own, for example that #77 ferrite material could
not possibly have worked in a certain situation.

The title of his post is "Do you think NI can fix my PLL?"

The answer is no. Chris is the best person for the job.

And stop using me as an advertisement to promote your own business.

Regards,

Mike Monett
 
J

Jon Elson

Jan 1, 1970
0
Chris said:
I think the arrangement would be to work closely together, where I
would learn how the loop was optimized so I could probably handle
future adjustments.



The requirements are not terribly difficult initially. About +/-0.5
degreees jitter is tolerable. But there is another dimension to the
project to explore syncing two wheels together. This will need to be
about 0.01 degrees p-p.

My problem is that when I did it with a PM motor, it worked very well.
Hardware behaved with a few % of the sim. Moving to brushless is
faltering, though the circuit is basically the same.

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
1024-rev
encoder is then run through an all-digital PLL X20 multiplier which has a
pretty narrow lock range. It has never lost lock (which would cause glaring
artifacts in the film output). The digital PLL produces the pixel clock of
20480 pixels/rev.

Jon
 
J

Joerg

Jan 1, 1970
0
Hello Mike,
The title of his post is "Do you think NI can fix my PLL?"

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".
And stop using me as an advertisement to promote your own business.

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

Chris Carlen

Jan 1, 1970
0
Joerg said:
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".

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.

--
Good day!

________________________________________
Christopher R. Carlen
Principal Laser&Electronics Technologist
Sandia National Laboratories CA USA
[email protected]
NOTE, delete texts: "RemoveThis" and
"BOGUS" from email address to reply.
 
M

Mike Monett

Jan 1, 1970
0
Chris Carlen said:
Mike, it wouldn't be Windows. It would by LabVIEW running on a
dedicated real time CPU or FPGA. Windows might be involved at a higher
level of "stop/go" that sort of thing.

Don't get me wrong, I still think it's a non-ideal approach.

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
 
C

Chris Carlen

Jan 1, 1970
0
Jon said:
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).

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
2x the continuous rating for a short time, then ramp down to the
continuous current limit set by a pot.

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:

http://www.a-m-c.com/download/datasheet/b15a8.pdf

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!


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 1024-rev encoder is then run through an all-digital PLL X20
multiplier which has a pretty narrow lock range. It has never lost
lock (which would cause glaring artifacts in the film output). The
digital PLL produces the pixel clock of 20480 pixels/rev.

Jon


--
Good day!

________________________________________
Christopher R. Carlen
Principal Laser&Electronics Technologist
Sandia National Laboratories CA USA
[email protected]
NOTE, delete texts: "RemoveThis" and
"BOGUS" from email address to reply.
 
J

Joerg

Jan 1, 1970
0
Hello Chris,
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.

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.
 
M

Mike Monett

Jan 1, 1970
0
Chris Carlen said:
The requirements are not terribly difficult initially. About +/-0.5
degreees jitter is tolerable. But there is another dimension to the
project to explore syncing two wheels together. This will need to be
about 0.01 degrees p-p.

The first is OK. The second is going to be a challenge, especially
when locking two wheels together.
My problem is that when I did it with a PM motor, it worked very well.
Hardware behaved with a few % of the sim. Moving to brushless is
faltering, though the circuit is basically the same.

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
 
T

Terry Given

Jan 1, 1970
0
Chris said:
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 2x the
continuous rating for a short time, then ramp down to the continuous
current limit set by a pot.

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:

http://www.a-m-c.com/download/datasheet/b15a8.pdf

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!

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 <= 1% current
error requires <= 0.025% voltage error.

Of course if I was smart I would have octupled the inductance to start
with, then gradually reduced it. But no, I had to do it the hard way.

[snip jolly interesting stuff]

HTH

Terry

PS I give NI a 1:100,000,000 chance of being able to fix your problem. I
nearly fell off my seat laughing when I read your colleagues "idea".
 
J

Joerg

Jan 1, 1970
0
Hello Chris,
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 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...
 
T

Tim Wescott

Jan 1, 1970
0
Chris said:
Hi:


I'm attempting to build another motor PLL system and running into some
difficulties stabilizing the loop. Since there is a lot of work to do,
I have considered contracting out the PLL design to a well known control
expert outside of my company, so I can focus on building other
subsystems of the project.

Basically, the PLL is to lock a 136mmx2.54mm Al wheel to a 400Hz
reference (24kRPM, 1 pulse/rev position sensor). Must be 2nd order PLL
yielding zero phase error with constant frequency input. Wheel to be
driven directly by a Maxon 200W brushless DC motor with an Advanced
Motion Controls B15A8 PWM servo driver running in open loop mode. I
have found that the open-loop mode of the motor drive results in not
very linear DC transfer of ref. voltage in to motor phase voltage out,
as well as not yielding a very linear dynamic response as well (rise
time != fall time, but only by about 10-20%).

I have suspected that this may be the root of why the PLL behaves quite
a bit less stable than my modeling predicts.

A co-worker involved in the project has contacted National Instruments,
and they will come in next week to tell us "what we need". I have
serious doubts that NI solutions will either be appropriate from a
design perspective, nor able to achieve results quicker/less costly than
if I get a control expert on the task.

I suspect from what I've heard my co-worker say (he is a LabView
programmer primarily) that what NI has to offer which applies to PLL
implementations is a LabVIEW-FPGA platform. This would implement
digital filtering of the sort needed to stabilize the loop. Of course,
then also some digital IO would be needed to accept the reference and
wheel position sensor signals, and D/A output to drive the motor power
drive.

What is the view of "the SED community" on the appropriateness and
likelyhood of success with this approach?

My assertion has been that PLL stabilization is not something that can
be done the way most controls are handled around here (usually PID)
where you can use heuristic algorithms to getting it to work). Rather a
PLL must be computed via classical analysis and servo loop design
methods, ie, do the math.

Since the LabVIEW guy has no such experience the only possible way this
could work using the NI approach is if:

1. NI has PLL tuning algorithms that can "autotune" successfully.
2. OR NI will also provide us with contracted design assistance to
have one of their experts tune and set up the digital filtering LabVIEW
code.
4. AND I am wrong about the need for analysis to solve this PLL's loop
stabilization requirements.
3. AND I am wrong about the non-linearities being the root of
difficulties. Although, a digital platform might actually help in this
regard if some sort of linearizing function must be applied. I suspect
however, that this would be better solved by a simpler minor-loop
synthesis approach. Ie, run the motor in speed servo mode using the
drive and a speed feedback sensor (which should then be highly linear),
and build the PLL around that.


What do you think?
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.
I am quite opposed to this situation of employing NI, but need to keep
an open mind. But from an engineering perspective, I think it is absurd
even if it ultimately works to employ vastly complecx FPGAs and ultra
high-level programming software, DAQ systems etc. to do the job of
something that should be doable with a couple op-amps and a handful of
resistors and capacitors.

Thanks for input.
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.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
 
C

Chris Carlen

Jan 1, 1970
0
Mike said:
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?

Less friction, more inertia now. But also very different motor constants.
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:)

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.

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


Thanks for the input.


--
Good day!

________________________________________
Christopher R. Carlen
Principal Laser&Electronics Technologist
Sandia National Laboratories CA USA
[email protected]
NOTE, delete texts: "RemoveThis" and
"BOGUS" from email address to reply.
 
T

Tim Wescott

Jan 1, 1970
0
Chris said:
Hi:


I'm attempting to build another motor PLL system and running into some
difficulties stabilizing the loop. Since there is a lot of work to do,
I have considered contracting out the PLL design to a well known control
expert outside of my company, so I can focus on building other
subsystems of the project.

Basically, the PLL is to lock a 136mmx2.54mm Al wheel to a 400Hz
reference (24kRPM, 1 pulse/rev position sensor). Must be 2nd order PLL
yielding zero phase error with constant frequency input. Wheel to be
driven directly by a Maxon 200W brushless DC motor with an Advanced
Motion Controls B15A8 PWM servo driver running in open loop mode. I
have found that the open-loop mode of the motor drive results in not
very linear DC transfer of ref. voltage in to motor phase voltage out,
as well as not yielding a very linear dynamic response as well (rise
time != fall time, but only by about 10-20%).

I have suspected that this may be the root of why the PLL behaves quite
a bit less stable than my modeling predicts.
-- snarping snipped --

Thanks for input.
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.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
 
J

Jim Thompson

Jan 1, 1970
0
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
 
C

Chris Carlen

Jan 1, 1970
0
Terry said:
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.

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.

Terry

PS I give NI a 1:100,000,000 chance of being able to fix your problem. I
nearly fell off my seat laughing when I read your colleagues "idea".


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?



--
Good day!

________________________________________
Christopher R. Carlen
Principal Laser&Electronics Technologist
Sandia National Laboratories CA USA
[email protected]
NOTE, delete texts: "RemoveThis" and
"BOGUS" from email address to reply.
 
T

Terry Given

Jan 1, 1970
0
Chris said:
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?

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.
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.

you're welcome.
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?

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
 
T

Tim Wescott

Jan 1, 1970
0
Jim said:
What's this PWM crap, it's slow enough, why not an EC motor driven by
a VCO?

...Jim Thompson

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.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
 
Top