Estimating servo loop bandwidth and sampling rate

[Chris Carlen]

Greetings:

My problem is to control 4 internal combustion engine valves
electronically. When I first heard about the problem, I was told up to
20kHz response would be needed. This led me to considerations of a
whopping 200-400ksps per each of four channels needed to accomplish this
using a DSP. Now I think the situation is an order of magnitude better.

Here are my first-order estimates of the closed-loop BW needed:

First we have to get some idea of the upper frequency content of the
valve movement profile. For an exhaust valve, let's say it is a smooth
Gaussian looking curve, and it is open for 1/4 of the 720 degree engine
cycle, or 180 degrees. Furthermore let's say that the "rise-degrees"
are about 60 degrees or pi/3 radians.

For an engine at 3000RPM, that's 50Hz.

Then crank angular frequency w = 2 pi (50Hz) = 100 pi rad/s.

Risetime tr of valve based on 60 "rise-degrees" is

tr = (pi/3)(s/(100 pi rad)) = 3.3ms

Upper frequency component of a waveform with 3.3ms risetime is:

f_valve = 0.35 / (3.3 ms) = 106Hz

Notice that the valve actuation frequency content is higher than the
crank rotation frequency. This is expected.

Now let's say we are willing to tolerate up to 2 crank degrees of
tracking error at 3000RPM. Things get a little tricky since this is
crank angle degrees, which we need to convert into degrees of phase
shift relative to the frequency content of the valve actuation, which we
know is about 140Hz. Thus the phase shift at 140Hz of the closed loop
transfer function must be about:

(2 crank degrees)(106Hz/50Hz) = 4.24 degrees

Assuming that the closed-loop transfer function looks like a single pole
near the cutoff frequency, what cutoff frequency (which will be the
closed-loop system BW) is needed to give this amount of phase shift?

The phase shift vs. frequency parameterized for cutoff frequency is:

arctan(f/fc) = 4.24, where f = 106Hz.

Thus, fc = 1400Hz is my estimate of the closed-loop bandwidth needed to
control the valves to within 2 crank degrees at an engine speed of
3000RPM. This is almost an order of magnitude slower than what I
originally was told.

I know this is a crude approximation, but that is all it is intended as,
in order to assist in choosing DSP and A/D&D/A hardware to implement the
controller. Next question is sampling rate needed.

Since this is closed-loop BW, I am not sure how it relates to open-loop
BW, which is what I need for determining sampling rate. Some crude
algebraic attempts to see the relation between open-loop unity gain
point and closed-loop BW or cutoff frequency suggests they are the same.

In that case I'd want about 20x oversampling or more (20x still injects
18 degrees of extra phase into the open-loop transfer function which is
about the most I'd want), so I'm looking for at least:

20 x 1400Hz = 28ksps per each of four channels.

Not terribly difficult.



--
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

 

[Tim Wescott]

Chris Carlen wrote:

Greetings:

My problem is to control 4 internal combustion engine valves
electronically. When I first heard about the problem, I was told up to
20kHz response would be needed. This led me to considerations of a
whopping 200-400ksps per each of four channels needed to accomplish this
using a DSP. Now I think the situation is an order of magnitude better.

Here are my first-order estimates of the closed-loop BW needed:

First we have to get some idea of the upper frequency content of the
valve movement profile. For an exhaust valve, let's say it is a smooth
Gaussian looking curve, and it is open for 1/4 of the 720 degree engine
cycle, or 180 degrees. Furthermore let's say that the "rise-degrees"
are about 60 degrees or pi/3 radians.

For an engine at 3000RPM, that's 50Hz.

Then crank angular frequency w = 2 pi (50Hz) = 100 pi rad/s.

Risetime tr of valve based on 60 "rise-degrees" is

tr = (pi/3)(s/(100 pi rad)) = 3.3ms

Upper frequency component of a waveform with 3.3ms risetime is:

f_valve = 0.35 / (3.3 ms) = 106Hz

Notice that the valve actuation frequency content is higher than the
crank rotation frequency. This is expected.

Now let's say we are willing to tolerate up to 2 crank degrees of
tracking error at 3000RPM. Things get a little tricky since this is
crank angle degrees, which we need to convert into degrees of phase
shift relative to the frequency content of the valve actuation, which we
know is about 140Hz. Thus the phase shift at 140Hz of the closed loop
transfer function must be about:

(2 crank degrees)(106Hz/50Hz) = 4.24 degrees

Assuming that the closed-loop transfer function looks like a single pole
near the cutoff frequency, what cutoff frequency (which will be the
closed-loop system BW) is needed to give this amount of phase shift?

The phase shift vs. frequency parameterized for cutoff frequency is:

arctan(f/fc) = 4.24, where f = 106Hz.

Thus, fc = 1400Hz is my estimate of the closed-loop bandwidth needed to
control the valves to within 2 crank degrees at an engine speed of
3000RPM. This is almost an order of magnitude slower than what I
originally was told.

I know this is a crude approximation, but that is all it is intended as,
in order to assist in choosing DSP and A/D&D/A hardware to implement the
controller. Next question is sampling rate needed.

Since this is closed-loop BW, I am not sure how it relates to open-loop
BW, which is what I need for determining sampling rate. Some crude
algebraic attempts to see the relation between open-loop unity gain
point and closed-loop BW or cutoff frequency suggests they are the same.

In that case I'd want about 20x oversampling or more (20x still injects
18 degrees of extra phase into the open-loop transfer function which is
about the most I'd want), so I'm looking for at least:

20 x 1400Hz = 28ksps per each of four channels.

Not terribly difficult.

Rule of thumb: Sample at 5 to 20 times your desired _closed_ loop
bandwidth, unless something wacky is going on. Wacky things are either
a plant that's just too easy to control, or a requirement for a severe
amount of derivative gain (which would almost constitute a
higher-bandwidth inner loop, thereby adhering to the rule...). I
usually make an exact z-domain model of the plant as sampled and design
from that.

Observation: You can probably do much of your control with feedforward
(i.e. almost open loop). This application just cries out for a nearly
open loop adaptive controller that adjusts the drive profile based on
past valve performance. If you can do this your bandwidth and sampling
rate could go down down down without compromising performance in any way.

Or just stick to your 28kHz, since it's quite obtainable with a halfway
decent DSP.

--

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

 

[Roy McCammon]

Chris Carlen wrote:

Greetings:

My problem is to control 4 internal combustion engine valves
electronically. When I first heard about the problem, I was told up to
20kHz response would be needed. This led me to considerations of a
whopping 200-400ksps per each of four channels needed to accomplish this
using a DSP. Now I think the situation is an order of magnitude better.

Here are my first-order estimates of the closed-loop BW needed:

First we have to get some idea of the upper frequency content of the
valve movement profile. For an exhaust valve, let's say it is a smooth
Gaussian looking curve, and it is open for 1/4 of the 720 degree engine
cycle, or 180 degrees. Furthermore let's say that the "rise-degrees"
are about 60 degrees or pi/3 radians.

For an engine at 3000RPM, that's 50Hz.

Then crank angular frequency w = 2 pi (50Hz) = 100 pi rad/s.

Risetime tr of valve based on 60 "rise-degrees" is

tr = (pi/3)(s/(100 pi rad)) = 3.3ms

Upper frequency component of a waveform with 3.3ms risetime is:

f_valve = 0.35 / (3.3 ms) = 106Hz

Notice that the valve actuation frequency content is higher than the
crank rotation frequency. This is expected.

Now let's say we are willing to tolerate up to 2 crank degrees of
tracking error at 3000RPM. Things get a little tricky since this is
crank angle degrees, which we need to convert into degrees of phase
shift relative to the frequency content of the valve actuation, which we
know is about 140Hz. Thus the phase shift at 140Hz of the closed loop
transfer function must be about:

(2 crank degrees)(106Hz/50Hz) = 4.24 degrees

Assuming that the closed-loop transfer function looks like a single pole
near the cutoff frequency, what cutoff frequency (which will be the
closed-loop system BW) is needed to give this amount of phase shift?

The phase shift vs. frequency parameterized for cutoff frequency is:

arctan(f/fc) = 4.24, where f = 106Hz.

Thus, fc = 1400Hz is my estimate of the closed-loop bandwidth needed to
control the valves to within 2 crank degrees at an engine speed of
3000RPM. This is almost an order of magnitude slower than what I
originally was told.

I know this is a crude approximation, but that is all it is intended as,
in order to assist in choosing DSP and A/D&D/A hardware to implement the
controller. Next question is sampling rate needed.

Since this is closed-loop BW, I am not sure how it relates to open-loop
BW, which is what I need for determining sampling rate. Some crude
algebraic attempts to see the relation between open-loop unity gain
point and closed-loop BW or cutoff frequency suggests they are the same.

In that case I'd want about 20x oversampling or more (20x still injects
18 degrees of extra phase into the open-loop transfer function which is
about the most I'd want), so I'm looking for at least:

20 x 1400Hz = 28ksps per each of four channels.

Not terribly difficult.

could you elaborate. What do you sense and what do you drive?

You actually want to control the valve position is a continuous
fashion from open to closed, or do you just want to issure the
open and close commands at the right time?

One thing to be wary of in mechanical systems is that the
"constants" are often functions of position. Things can be quite
non linear and a system stable for small signals can fail
unstabily for large signals.

 

[Chris Carlen]

Roy McCammon wrote:

could you elaborate. What do you sense and what do you drive?

You actually want to control the valve position is a continuous
fashion from open to closed, or do you just want to issure the
open and close commands at the right time?

One thing to be wary of in mechanical systems is that the
"constants" are often functions of position. Things can be quite
non linear and a system stable for small signals can fail
unstabily for large signals.

Hi Roy, thanks for the reply.

It is desired to control the continuous valve position. What is sensed
is absolute valve position via LVDT. What is driven is a voice coil
motor. The actual physics may be described like the following:

The voice coil motor actuates some sort of differential hydraulic valve.
The hydraulic "push-down" vs. "push-up" signals actuate a hydraulic
cylinder which actuates the valve, which I suppose also has a spring,
but I'm not sure.

We will want to be able to adjust the continuous valve actuation
profile, ie., position function of crank angle. We plan to develop a PC
based user interface that will essentially allow the user to move around
Bezier points on the screen, to shape the valve actuation function for
each of the four valves in whatever manner desired.

The resulting functions will likely be downloaded on the fly (the user
can modify the valve profiles while the engine is running) as a table to
the DSP system, which will generate the command or reference position
signal by indexing this table as a function of crank angle. So the
crank shaft encoder will also be interfaced to the DSP.

The DSP will then implement the control loop taking the internally
generated digital command value, and "servoing" the valves via the voice
coil motor drive output and LVDT feedback. It will also a few times a
second send back to the PC a "scope trace" of the actual valve
controlled position, which will be overlayed with the command curve to
indicate how well the controller is doing.

The main thing working in our favor is that this has been done before my
the manufacturer of the valve actuation system. Yet, they indicate that
we should build our own servo system, both because theirs is a very
expensive commercial vehicle design hardware/software system that has
this function implemented as a secondary aspect, and also because there
are some changes to the valve actuation package between the one they
have demonstrated and the one we will be using. For one thing, our
valves are much lighter.

Yes, there is ample opportunity for complex non-linearties to be
present. I have been thinking about this subject a great deal, and have
some to a picture that mirrors your description--that the "constants" in
the describing transfer function of the plant are really functions of
position. Overall, I think I have an understanding of most of the
gotchas, so that if problems arise I will likely know what the next step
should be.

The manufacturer states that the thing worked well under simply PID
control. I remain skeptical of this, yet will give it a shot as a first
experiment once hardware is actually available to test. Right now we
still have to build the power drivers and LVDT conditioning electronics,
which I hope to oversee another tech. to do so I can think mainly about
the control problem.

Once the electronics are done, I will likely begin by attempting to
characterize the transfer function of the plant in the frequency domain
and also the DC transfer to see how linear it is. If the
non-linearities are "slight" then I will hope to be able to use basic
linear methods to devise a loop compensation. If this can be satisfied
with the available degrees of freedom afforded by a PID control, then
jolly. Otherwise I will try more sophisticated methods.

I am giving myself a 4 month period to learn some more of the control
theory in enough depth to be able to put rigor to what I can only
conceptualize at this point. I will also do considerable modeling and
experimentation with test cases before dealing with the actual valves.
In order to better prepare to handle the control problem, I have a busy
schedule planned:

I hope to host Rick Lyons here on June 1,2,3 for his DSP workshop, so
before that I'm spending this month studying Fourier series and
transforms. Then I'll spend June through August looking into my control
theory text, and hopefully figuring out how to implement PIDs, as well
as arbitrary s-domain transfer functions (or their z equivalents) in
computer code instead of analog electronics which I can do now. Will
also attend various workshops with TI or ADI to get familiar with their
DSPs and tools.

I have learned from the articles on Tim Wescott's site that there are
much better ways to do this on a computer than the way that I knew up to
this point. You may laugh, but I thought the only way to do it was
through convolution (ie, an FIR filter). Well actualy I know about IIR
filters, but don't understand them yet. FIR is of course horribly
computationally inefficient. There seems to be a much more
computationally lightweight way, through Z-transforms and difference
equations. So I will be looking into all this fun stuff before I have
to actually attempt to control the valves toward the end of the year.

Good day!




--
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarle@sandia.gov

 

[Tim Wescott]

Chris Carlen wrote:

Roy McCammon wrote:

could you elaborate. What do you sense and what do you drive?

You actually want to control the valve position is a continuous
fashion from open to closed, or do you just want to issure the
open and close commands at the right time?

One thing to be wary of in mechanical systems is that the
"constants" are often functions of position. Things can be quite
non linear and a system stable for small signals can fail
unstabily for large signals.



Hi Roy, thanks for the reply.

It is desired to control the continuous valve position. What is sensed
is absolute valve position via LVDT. What is driven is a voice coil
motor. The actual physics may be described like the following:

The voice coil motor actuates some sort of differential hydraulic valve.
The hydraulic "push-down" vs. "push-up" signals actuate a hydraulic
cylinder which actuates the valve, which I suppose also has a spring,
but I'm not sure.

We will want to be able to adjust the continuous valve actuation
profile, ie., position function of crank angle. We plan to develop a PC
based user interface that will essentially allow the user to move around
Bezier points on the screen, to shape the valve actuation function for
each of the four valves in whatever manner desired.

The resulting functions will likely be downloaded on the fly (the user
can modify the valve profiles while the engine is running) as a table to
the DSP system, which will generate the command or reference position
signal by indexing this table as a function of crank angle. So the
crank shaft encoder will also be interfaced to the DSP.

The DSP will then implement the control loop taking the internally
generated digital command value, and "servoing" the valves via the voice
coil motor drive output and LVDT feedback. It will also a few times a
second send back to the PC a "scope trace" of the actual valve
controlled position, which will be overlayed with the command curve to
indicate how well the controller is doing.

The main thing working in our favor is that this has been done before my
the manufacturer of the valve actuation system. Yet, they indicate that
we should build our own servo system, both because theirs is a very
expensive commercial vehicle design hardware/software system that has
this function implemented as a secondary aspect, and also because there
are some changes to the valve actuation package between the one they
have demonstrated and the one we will be using. For one thing, our
valves are much lighter.

Yes, there is ample opportunity for complex non-linearties to be
present. I have been thinking about this subject a great deal, and have
some to a picture that mirrors your description--that the "constants" in
the describing transfer function of the plant are really functions of
position. Overall, I think I have an understanding of most of the
gotchas, so that if problems arise I will likely know what the next step
should be.

The manufacturer states that the thing worked well under simply PID
control. I remain skeptical of this, yet will give it a shot as a first
experiment once hardware is actually available to test. Right now we
still have to build the power drivers and LVDT conditioning electronics,
which I hope to oversee another tech. to do so I can think mainly about
the control problem.

Once the electronics are done, I will likely begin by attempting to
characterize the transfer function of the plant in the frequency domain
and also the DC transfer to see how linear it is. If the
non-linearities are "slight" then I will hope to be able to use basic
linear methods to devise a loop compensation. If this can be satisfied
with the available degrees of freedom afforded by a PID control, then
jolly. Otherwise I will try more sophisticated methods.

I am giving myself a 4 month period to learn some more of the control
theory in enough depth to be able to put rigor to what I can only
conceptualize at this point. I will also do considerable modeling and
experimentation with test cases before dealing with the actual valves.
In order to better prepare to handle the control problem, I have a busy
schedule planned:

I hope to host Rick Lyons here on June 1,2,3 for his DSP workshop, so
before that I'm spending this month studying Fourier series and
transforms. Then I'll spend June through August looking into my control
theory text, and hopefully figuring out how to implement PIDs, as well
as arbitrary s-domain transfer functions (or their z equivalents) in
computer code instead of analog electronics which I can do now. Will
also attend various workshops with TI or ADI to get familiar with their
DSPs and tools.

I have learned from the articles on Tim Wescott's site that there are
much better ways to do this on a computer than the way that I knew up to
this point. You may laugh, but I thought the only way to do it was
through convolution (ie, an FIR filter). Well actualy I know about IIR
filters, but don't understand them yet. FIR is of course horribly
computationally inefficient. There seems to be a much more
computationally lightweight way, through Z-transforms and difference
equations. So I will be looking into all this fun stuff before I have
to actually attempt to control the valves toward the end of the year.

Good day!

Thanks for the plug! It hadn't occurred to me that someone would
approach this knowing about the FIR filter but not the IIR -- it should
have, but it didn't. If you know analog filters you _do_ know about IIR
filters. Anything you build with caps and coils is an IIR filter -- you
have to go to incredible lengths to build an FIR filter with analog,
continuous-time components.

You should also be aware that for the most part FIR filters should take
a back seat to IIR filters for control loops. FIR filters are _very_
nice for communications applications because they have a constant delay
as a function of frequency. They're bad for closed-loop control because
it's a _large_ delay; you can generally get much greater amplitude
change vs. phase delay with an IIR filter than you can with an FIR, and
that's generally exactly what you want in a control loop.

"Just" PID can do wonders. I use the quote marks because you can put in
some pretty interesting nonlinearities and still have something that you
can say with a straight face "its a PID controller".

You'll probably find that your hydraulic valves exhibit some stiction
(see my "friction and backlash" article,
http://www.wescottdesign.com/articles/Friction/friction.html, when your
brain is ready to absorb more info . This has the potential to be a
nasty problem, exacerbated by the speaker-coil actuators on the valves.

A good way to check for the kinds of nonlinearities caused by friction
is to find the system frequency response at a number of different input
amplitudes (this is called "describing function analysis"). If the
apparent transfer function changes with changes in signal amplitude then
the system isn't linear. The nice thing about this is that the
describing function plot gives you something to design to using Bode
plot techniques -- theoretically there's no guarantee, but if you design
your controller to meet gain and phase margins for the entire range of
behaviors you see you'll have an excellent chance of having a correctly
working controller. My "z transforms" article
(http://www.wescottdesign.com/articles/zTransform/z-transforms.html)
scrapes the surface of Bode plot design, but you can get it from a book
as well.

--

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

 

[Chris Carlen]

Tim Wescott wrote:

Thanks for the plug! It hadn't occurred to me that someone would
approach this knowing about the FIR filter but not the IIR -- it should
have, but it didn't. If you know analog filters you _do_ know about IIR
filters. Anything you build with caps and coils is an IIR filter -- you
have to go to incredible lengths to build an FIR filter with analog,
continuous-time components.

The articles on your web site were very interesting, and gave me seed
material to know the directions in which to learn and experiment. I
will likely study those articles in detail soon, and implement some of
the codes on a test jig like an AVR micro with some mock plant.

I came about using FIR in a strange way. I had skimmed over the subject
of digital filtering in my DSP book, and understood the general idea of
FIR as moving averaging. A further link in the chain was provided by
learning about the convolution integral in continuous time analysis.

It occurred to me that I could simply write an s-domain transfer
function of a filter that I want to implement digitally, then inverse
transform that to a time domain expression. By sampling that at the
rate of my data stream, I get the FIR coefficients. I wrote a simple
convolution code for the AVR running in a dynamometer controller that I
built which checks if the motor current has gone above some threshold
and shuts down if so. We were experiencing transients causing it to
shut down unnecessarily. There was no room on the PCB to hack in an
extra analog filter, so I did it digitally. It works great. This made
me very excited to learn more DSP.

I then extrapolated the idea of using the convolution to do FIR
filtering to the idea of implementing any desired transfer function such
as a loop compensation for a servo.

But it turns out not to be the best way.

You should also be aware that for the most part FIR filters should take
a back seat to IIR filters for control loops. FIR filters are _very_
nice for communications applications because they have a constant delay
as a function of frequency. They're bad for closed-loop control because
it's a _large_ delay; you can generally get much greater amplitude
change vs. phase delay with an IIR filter than you can with an FIR, and
that's generally exactly what you want in a control loop.

This is the idea I am getting. Hopefully I will have a grasp of how to
make IIR filters soon after the course with Rick Lyons in June.

"Just" PID can do wonders. I use the quote marks because you can put in
some pretty interesting nonlinearities and still have something that you
can say with a straight face "its a PID controller".

You'll probably find that your hydraulic valves exhibit some stiction
(see my "friction and backlash" article,
http://www.wescottdesign.com/articles/Friction/friction.html, when your
brain is ready to absorb more info . This has the potential to be a
nasty problem, exacerbated by the speaker-coil actuators on the valves.

I am also aware of this issue, since it crops up in some injector fuel
rail regulator valves here in the labs. We've learned they don't take
kindly to linear drive, and so low frequency PWM is needed to jiggle the
things and keep them unstuck. Obviously the same issue can crop up with
the valves, though I expect it isn't as likely since they won't be
hanging out in a static location for very long. We'll see.

A good way to check for the kinds of nonlinearities caused by friction
is to find the system frequency response at a number of different input
amplitudes (this is called "describing function analysis"). If the
apparent transfer function changes with changes in signal amplitude then
the system isn't linear.

Yes.

The nice thing about this is that the
describing function plot gives you something to design to using Bode
plot techniques -- theoretically there's no guarantee, but if you design
your controller to meet gain and phase margins for the entire range of
behaviors you see you'll have an excellent chance of having a correctly
working controller. My "z transforms" article
(http://www.wescottdesign.com/articles/zTransform/z-transforms.html)
scrapes the surface of Bode plot design, but you can get it from a book
as well.

Thanks for the input.


Good day!



--
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarle@sandia.gov

 

[Terry Given]

"Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
news:109kppqor99nvef@corp.supernews.com...

Thanks for the plug! It hadn't occurred to me that someone would
approach this knowing about the FIR filter but not the IIR -- it should
have, but it didn't. If you know analog filters you _do_ know about IIR
filters. Anything you build with caps and coils is an IIR filter -- you
have to go to incredible lengths to build an FIR filter with analog,
continuous-time components.

You should also be aware that for the most part FIR filters should take
a back seat to IIR filters for control loops. FIR filters are _very_
nice for communications applications because they have a constant delay
as a function of frequency. They're bad for closed-loop control because
it's a _large_ delay; you can generally get much greater amplitude
change vs. phase delay with an IIR filter than you can with an FIR, and
that's generally exactly what you want in a control loop.

"Just" PID can do wonders. I use the quote marks because you can put in
some pretty interesting nonlinearities and still have something that you
can say with a straight face "its a PID controller".

look at some of Bob Pease's rants on PID vs fuzzy control - nat semi have
archived a whole bunch of these, go looking.

You'll probably find that your hydraulic valves exhibit some stiction
(see my "friction and backlash" article,
http://www.wescottdesign.com/articles/Friction/friction.html, when your
brain is ready to absorb more info . This has the potential to be a
nasty problem, exacerbated by the speaker-coil actuators on the valves.

A good way to check for the kinds of nonlinearities caused by friction
is to find the system frequency response at a number of different input
amplitudes (this is called "describing function analysis"). If the
apparent transfer function changes with changes in signal amplitude then
the system isn't linear. The nice thing about this is that the
describing function plot gives you something to design to using Bode
plot techniques -- theoretically there's no guarantee, but if you design
your controller to meet gain and phase margins for the entire range of
behaviors you see you'll have an excellent chance of having a correctly
working controller. My "z transforms" article
(http://www.wescottdesign.com/articles/zTransform/z-transforms.html)
scrapes the surface of Bode plot design, but you can get it from a book
as well.

nice. And it happily answers K. Aylwards complaints about frequency response
analysis wrt nonlinearities (thou shalt not analyse/measure, thou shalt
transient simulate with his spice). Its worth noting that SMPS are as
nonlinear as all hell, yet on the whole respond quite nicely to this sort of
analysis by bode plot, and most people DONT bother to do the describing
function analysis Tim recommends, just take a single bode plot.....the
miracle of high loop gain.

--

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

 

[Tim Wescott]

Terry Given wrote:

-- snip --

look at some of Bob Pease's rants on PID vs fuzzy control - nat semi have
archived a whole bunch of these, go looking.

Yes, I remember reading them when they first came out. I'm still

waiting for a project that's sufficiently fuzzy to justify fuzzy control
-- so far I've been able to just understand the math and design a
controller. I can certainly understand the appeal of fuzzy logic, but I
don't think you should use it until you're at a loss, and then you
should subject your system to rigorous stability testing before you even
_think_ of shipping it.

-- snip --

nice. And it happily answers K. Aylwards complaints about frequency response
analysis wrt nonlinearities (thou shalt not analyse/measure, thou shalt
transient simulate with his spice). Its worth noting that SMPS are as
nonlinear as all hell, yet on the whole respond quite nicely to this sort of
analysis by bode plot, and most people DONT bother to do the describing
function analysis Tim recommends, just take a single bode plot.....the
miracle of high loop gain.

Oh, there's nothing wrong with simulation, but if the system allows it

the describing function is a good way to find the controller to simulate
with.

--

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

--

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

 

[Chris Carlen]

Terry Given wrote:

"Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
news:109kppqor99nvef@corp.supernews.com...
A good way to check for the kinds of nonlinearities caused by friction
is to find the system frequency response at a number of different input
amplitudes (this is called "describing function analysis"). If the
apparent transfer function changes with changes in signal amplitude then
the system isn't linear. The nice thing about this is that the
describing function plot gives you something to design to using Bode
plot techniques -- theoretically there's no guarantee, but if you design
your controller to meet gain and phase margins for the entire range of
behaviors you see you'll have an excellent chance of having a correctly
working controller. My "z transforms" article
(http://www.wescottdesign.com/articles/zTransform/z-transforms.html)
scrapes the surface of Bode plot design, but you can get it from a book
as well.


nice. And it happily answers K. Aylwards complaints about frequency response
analysis wrt nonlinearities (thou shalt not analyse/measure, thou shalt
transient simulate with his spice). Its worth noting that SMPS are as
nonlinear as all hell, yet on the whole respond quite nicely to this sort of
analysis by bode plot, and most people DONT bother to do the describing
function analysis Tim recommends, just take a single bode plot.....the
miracle of high loop gain.

I have an interesting example in mny files of a SMPS-like application--a
solenoid coil driver topology--that exhibits a non-linearity severe
enough to allow the thing to go totally unstable at one operating point
when coming from one direction, and yet is stable at operating points
above and below that one, or when coming from the other direction.



--
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

 

[nospam]

Chris Carlen <crcarle@BOGUS.sandia.gov> wrote:

The voice coil motor actuates some sort of differential hydraulic valve.
The hydraulic "push-down" vs. "push-up" signals actuate a hydraulic
cylinder which actuates the valve, which I suppose also has a spring,
but I'm not sure.

A rather critical point which you might be missing. Assuming this hydraulic
valve is a flow control device (not pressure) then the system you are
trying to control is inherently integrating. Also remember that for much of
the cycle the engine valve needs to be closed and hard against a mechanical
stop, a normal pid loop would probably have to be disabled to prevent it
winding up on the stop, but thankfully the inherent integrator is
inherently disabled (assuming the engine valve can stand the force).

Taking a simplistic approach you are going to be generating a repetitive
voltage waveform for the hydraulic valve control signal synchronised to the
engine crankshaft. That waveform is going to be pretty much identical from
one engine cycle to the next so why not just generate it from a lookup
table and use positional feedback from the valve to dynamically 'calibrate'
the table?

A while ago I made a similar 'electronic programmable camshaft' for an
industrial machine. The actuator was a stepper motor and belt system. It
ran completely open loop. Your application is the same but with a less
friendly actuator.

 

[Rich Grise]

"Chris Carlen" <crcarle@BOGUS.sandia.gov> wrote in message
news:c7djrt05db@news2.newsguy.com...

Roy McCammon wrote:
could you elaborate. What do you sense and what do you drive?

You actually want to control the valve position is a continuous
fashion from open to closed, or do you just want to issure the
open and close commands at the right time?

One thing to be wary of in mechanical systems is that the
"constants" are often functions of position. Things can be quite
non linear and a system stable for small signals can fail
unstabily for large signals.


Hi Roy, thanks for the reply.

It is desired to control the continuous valve position. What is sensed
is absolute valve position via LVDT. What is driven is a voice coil
motor. The actual physics may be described like the following:

I'd have thought that continuous control would be something like overkill -
why would you want anything other than fully-open or fully-closed for an
engine valve? Or is the response so fast that you want to be sure that
you don't smack the piston either side of TDC?

Thanks,
Rich

 

[Terry Given]

"Chris Carlen" <crobc@BOGUS_FIELD.earthlink.net> wrote in message
news:c7eou801civ@news2.newsguy.com...

Terry Given wrote:
"Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
news:109kppqor99nvef@corp.supernews.com...
A good way to check for the kinds of nonlinearities caused by friction
is to find the system frequency response at a number of different input
amplitudes (this is called "describing function analysis"). If the
apparent transfer function changes with changes in signal amplitude then
the system isn't linear. The nice thing about this is that the
describing function plot gives you something to design to using Bode
plot techniques -- theoretically there's no guarantee, but if you design
your controller to meet gain and phase margins for the entire range of
behaviors you see you'll have an excellent chance of having a correctly
working controller. My "z transforms" article
(http://www.wescottdesign.com/articles/zTransform/z-transforms.html)
scrapes the surface of Bode plot design, but you can get it from a book
as well.


nice. And it happily answers K. Aylwards complaints about frequency
response
analysis wrt nonlinearities (thou shalt not analyse/measure, thou shalt
transient simulate with his spice). Its worth noting that SMPS are as
nonlinear as all hell, yet on the whole respond quite nicely to this
sort of
analysis by bode plot, and most people DONT bother to do the describing
function analysis Tim recommends, just take a single bode plot.....the
miracle of high loop gain.


I have an interesting example in mny files of a SMPS-like application--a
solenoid coil driver topology--that exhibits a non-linearity severe
enough to allow the thing to go totally unstable at one operating point
when coming from one direction, and yet is stable at operating points
above and below that one, or when coming from the other direction.

Christopher R. Carlen

Nasty. Caused by the inductance-vs-plunger position of solenoid? I'd love to
hear more about it - how you analysed, designed, implemented, measured
it....

cheers
Terry

 

[Chris Carlen]

Terry Given wrote:

"Chris Carlen" <crobc@BOGUS_FIELD.earthlink.net> wrote in message
news:c7eou801civ@news2.newsguy.com...

Terry Given wrote:

"Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
news:109kppqor99nvef@corp.supernews.com...

A good way to check for the kinds of nonlinearities caused by friction
is to find the system frequency response at a number of different input
amplitudes (this is called "describing function analysis"). If the
apparent transfer function changes with changes in signal amplitude then
the system isn't linear. The nice thing about this is that the
describing function plot gives you something to design to using Bode
plot techniques -- theoretically there's no guarantee, but if you design
your controller to meet gain and phase margins for the entire range of
behaviors you see you'll have an excellent chance of having a correctly
working controller. My "z transforms" article
(http://www.wescottdesign.com/articles/zTransform/z-transforms.html)
scrapes the surface of Bode plot design, but you can get it from a book
as well.


nice. And it happily answers K. Aylwards complaints about frequency

response

analysis wrt nonlinearities (thou shalt not analyse/measure, thou shalt
transient simulate with his spice). Its worth noting that SMPS are as
nonlinear as all hell, yet on the whole respond quite nicely to this

sort of

analysis by bode plot, and most people DONT bother to do the describing
function analysis Tim recommends, just take a single bode plot.....the
miracle of high loop gain.


I have an interesting example in mny files of a SMPS-like application--a
solenoid coil driver topology--that exhibits a non-linearity severe
enough to allow the thing to go totally unstable at one operating point
when coming from one direction, and yet is stable at operating points
above and below that one, or when coming from the other direction.

Christopher R. Carlen


Nasty. Caused by the inductance-vs-plunger position of solenoid? I'd love to
hear more about it - how you analysed, designed, implemented, measured
it....

It's a problem caused by the changeover from discontinuous to continuous
conduction of the inductance, complicated by additional non-linearities
in the drive method--which was hoped to make the problem simple, but
actually made it terrible in terms of control. I have a LT-SPICE file I
could send you. Email me at my home address to remind me, and tonight
I'll send you a copy. You may have to fiddle a little with getting any
symbols and model file paths reconciled to run on your directory structure.

crobc@NOT-THIS-PART.earthlink.net



--
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarle@sandia.gov

 

[Chris Carlen]

Rich Grise wrote:

"Chris Carlen" <crcarle@BOGUS.sandia.gov> wrote in message
news:c7djrt05db@news2.newsguy.com...

Roy McCammon wrote:

could you elaborate. What do you sense and what do you drive?

You actually want to control the valve position is a continuous
fashion from open to closed, or do you just want to issure the
open and close commands at the right time?

One thing to be wary of in mechanical systems is that the
"constants" are often functions of position. Things can be quite
non linear and a system stable for small signals can fail
unstabily for large signals.


Hi Roy, thanks for the reply.

It is desired to control the continuous valve position. What is sensed
is absolute valve position via LVDT. What is driven is a voice coil
motor. The actual physics may be described like the following:


I'd have thought that continuous control would be something like overkill -
why would you want anything other than fully-open or fully-closed for an
engine valve? Or is the response so fast that you want to be sure that
you don't smack the piston either side of TDC?

Thanks,
Rich

Hi Rich, thanks for the input.

It is understandable to think it could be as simple as on-off. The
first concern you noticed already, is that one shouldn't just let the
valve slam into the seat. It should be settled down smoothly. This
pretty much necessitates linear control.

But there are more subtle issues. The engine researchers are
investigating very detailed phenomena. Some of which includes the
effects of "swirl" and other forms of tubulence on the combustion
process. The knowledge level is to the point where models are being
computed and compared to lab experiments, that account for low-level
chemical reaction kinetics and heat release for many parallel and highly
complex combustion reaction pathways, coupled with fluid dynamics
physics and turbulence flow field models. In short, a modeling which
accounts for *everything* that happens in the engine. The complexity of
what these scientists are dealing with is mind boggling.

The point is that by playing with the valve actuation profiles of
primarily the two intake valves, one can manipulate angular momentum
initial conditions for the swirl and other turbulence aspects at the
beginning of the combustion event. This combined with special designs
of the port leading to the valves as well.

Ok, gotta go.

Have a good day!



--
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

 

[Rich Grise]

Thanks for this!

"Chris Carlen" <crobc@BOGUS_FIELD.earthlink.net> wrote in message
news:c7hl9o0h9e@news3.newsguy.com...

Rich Grise wrote:
"Chris Carlen" <crcarle@BOGUS.sandia.gov> wrote in message
news:c7djrt05db@news2.newsguy.com...

Roy McCammon wrote:

could you elaborate. What do you sense and what do you drive?

You actually want to control the valve position is a continuous
fashion from open to closed, or do you just want to issure the
open and close commands at the right time?

One thing to be wary of in mechanical systems is that the
"constants" are often functions of position. Things can be quite
non linear and a system stable for small signals can fail
unstabily for large signals.


Hi Roy, thanks for the reply.

It is desired to control the continuous valve position. What is sensed
is absolute valve position via LVDT. What is driven is a voice coil
motor. The actual physics may be described like the following:


I'd have thought that continuous control would be something like
overkill -
why would you want anything other than fully-open or fully-closed for an
engine valve? Or is the response so fast that you want to be sure that
you don't smack the piston either side of TDC?

Thanks,
Rich


Hi Rich, thanks for the input.

It is understandable to think it could be as simple as on-off. The
first concern you noticed already, is that one shouldn't just let the
valve slam into the seat. It should be settled down smoothly. This
pretty much necessitates linear control.

But there are more subtle issues. The engine researchers are
investigating very detailed phenomena. Some of which includes the
effects of "swirl" and other forms of tubulence on the combustion
process. The knowledge level is to the point where models are being
computed and compared to lab experiments, that account for low-level
chemical reaction kinetics and heat release for many parallel and highly
complex combustion reaction pathways, coupled with fluid dynamics
physics and turbulence flow field models. In short, a modeling which
accounts for *everything* that happens in the engine. The complexity of
what these scientists are dealing with is mind boggling.

The point is that by playing with the valve actuation profiles of
primarily the two intake valves, one can manipulate angular momentum
initial conditions for the swirl and other turbulence aspects at the
beginning of the combustion event. This combined with special designs
of the port leading to the valves as well.

Ok, gotta go.

Have a good day!



--
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

 

[Terry Given]

"Chris Carlen" <crobc@BOGUS_FIELD.earthlink.net> wrote in message
news:c79o8111aio@news3.newsguy.com...

Greetings:

My problem is to control 4 internal combustion engine valves
electronically. When I first heard about the problem, I was told up to
20kHz response would be needed. This led me to considerations of a
whopping 200-400ksps per each of four channels needed to accomplish this
using a DSP. Now I think the situation is an order of magnitude better.

Here are my first-order estimates of the closed-loop BW needed:

First we have to get some idea of the upper frequency content of the
valve movement profile. For an exhaust valve, let's say it is a smooth
Gaussian looking curve, and it is open for 1/4 of the 720 degree engine
cycle, or 180 degrees. Furthermore let's say that the "rise-degrees"
are about 60 degrees or pi/3 radians.

For an engine at 3000RPM, that's 50Hz.

Then crank angular frequency w = 2 pi (50Hz) = 100 pi rad/s.

Risetime tr of valve based on 60 "rise-degrees" is

tr = (pi/3)(s/(100 pi rad)) = 3.3ms

Upper frequency component of a waveform with 3.3ms risetime is:

f_valve = 0.35 / (3.3 ms) = 106Hz

Notice that the valve actuation frequency content is higher than the
crank rotation frequency. This is expected.

Now let's say we are willing to tolerate up to 2 crank degrees of
tracking error at 3000RPM. Things get a little tricky since this is
crank angle degrees, which we need to convert into degrees of phase
shift relative to the frequency content of the valve actuation, which we
know is about 140Hz. Thus the phase shift at 140Hz of the closed loop
transfer function must be about:

(2 crank degrees)(106Hz/50Hz) = 4.24 degrees

Assuming that the closed-loop transfer function looks like a single pole
near the cutoff frequency, what cutoff frequency (which will be the
closed-loop system BW) is needed to give this amount of phase shift?

The phase shift vs. frequency parameterized for cutoff frequency is:

arctan(f/fc) = 4.24, where f = 106Hz.

Thus, fc = 1400Hz is my estimate of the closed-loop bandwidth needed to
control the valves to within 2 crank degrees at an engine speed of
3000RPM. This is almost an order of magnitude slower than what I
originally was told.

I know this is a crude approximation, but that is all it is intended as,
in order to assist in choosing DSP and A/D&D/A hardware to implement the
controller. Next question is sampling rate needed.

Since this is closed-loop BW, I am not sure how it relates to open-loop
BW, which is what I need for determining sampling rate. Some crude
algebraic attempts to see the relation between open-loop unity gain
point and closed-loop BW or cutoff frequency suggests they are the same.

In that case I'd want about 20x oversampling or more (20x still injects
18 degrees of extra phase into the open-loop transfer function which is
about the most I'd want), so I'm looking for at least:

20 x 1400Hz = 28ksps per each of four channels.

Not terribly difficult.



--
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

Chris,

take a look at the "software control of flyback converter" thread in
a.b.s.e. - I posted a plot of the frequency response of 3 filters - an RC
and 2 IIR digital filters, measured with a frequency response analyser. Very
interesting.

Terry