I have to implement a digital control loop with a very low sample
rate, i.e. I get the sensor value every two hours. I have to regulate
the fuel consumption of an engine. Is this even feasible with a PID
controller? Or are there other better controllers (mybe non-linear)?
Also, I am not sure whether I should call the PID function on every
new value only, or more often. I think that more often could be better
if the actual value doesn't change very much - even if the underlying
sensor value is not real anymore if it is no new value. But that would
probably not possibly with an integrating (I) part. Any ideas?
On Wed, 08 Jul 2009 09:10:16 -0700, Johannes Eble wrote:
Given the information you've presented I can absolutely, positively say
that I don't know. And I suspect that neither does anyone else.
How rapidly do conditions change? What are the magnitudes of the
disturbances you're dealing with? How linear and how predictable is the
engine's response to your control input?
If your first answer is "way faster than two hours" then it probably
can't be done. If it's "way slower", and the disturbances are large
enough to stall out the engine in less than two hours, then it probably
can't be done. If the disturbances are slow enough and small enough and
the engine responds rapidly and unpredictably to control input then it
probably can't be done.
The closer your answers are to "slow", "small" and "very" the more likely
it is that any old thing will work; the closer they are to "fast", "big"
and "not very" then the more likely it is that the task just can't be
done at all. Somewhere between "easy" and "can't be done" there may be
room for a fancy controller.
I know that it is vague. But I think that this is a general type of
system (extremely low sampling rate) that should happen quite often in
practice. Maybe there is no theory for it, but I simply can't imagine
that there is no experience for it. Doesn't this happen all the time
in space control? Unfortunately, the control textbooks fall short of
it, but they only teach theory. ;-)
I probably have to do it in combination with engine maps, states that
have different controllers and states that don't have a (loopback)
controller at all
As I wrote to Jerry, the fuel consumption is drifting apart, but this
happens within days.
Another problem is that there are other subsystems that are controlled
that influence the fuel consumption system. They are faster (seconds).
But I plan to swith off the fuel consuption control when these
subsystems come into action (it doesn't happen all the time).
>What are the magnitudes of the
See above, within days.
How linear and how predictable is the
On Wed, 08 Jul 2009 23:35:52 -0700, Johannes Eble wrote:
If the drift is measured in days, then a two-hour sampling interval isn't
Sampling rates are only 'slow' or 'fast' in absolute terms if they
challenge our ability to build reliable systems or if they challenge our
ability to build fast systems. Beyond our system-building abilities, a
sampling rate can only be fast or slow relative to the problem at hand.
So if you're controlling the water level behind a dam a sampling rate of
once every hour may be really, really fast. On the other hand, if you're
trying to close a loop at 200Hz and maintain a high degree of precision
you'll find that a 10kHz sampling rate is slow indeed.
Here again, then, you're probably fine (see Bruce Varley's post about
The set of all fuzzy controllers is included in the set of all fancy
controllers, but the obverse is not true. And the set of all fuzzy
controllers has a strong intersection with the set of all over-hyped
In your case I think a regular PID with output linearization would work
I mean that I have to get the actual fuel consumption following a
setpoint as accurate as possible. I know it is vague, and I don't
think it is realistic to assume that this will happen within seconds
or minutes, but probably hours.
Do you mean the open or the closed loop? Well, it certainly should be
stable. Without the controller as it is now, it is stable, but the
fuel consuption ist drifting away (within days). We want to compensate
On Wed, 08 Jul 2009 23:14:26 -0700, Johannes Eble wrote:
Well in _that_ case then your sampling rate is probably fair. It sounds
like your sample speed vs. disturbance speed is generous enough, so
success probably depends most strongly on how nonlinear your plant is.
Why are you measuring so seldom? If you're dodging noise there are
advantages to measuring more often and low-pass filtering in the
controller, although perhaps not strong enough ones to make it useful.
They say that it is too expensive to use any sensor that has a higher
sample rate and that is more accurate. We have to use the make-a-guess-
crap that already fits into the tank system. I can't decide on the
sensor, I am just the poor programmer ;-)
The sensor is a black box to me, I get the values via CANbus.
For starters I'd suggest a strategy that's commonly referred to as 'smart
operator'. Smart operators know that if they move the knob by x, then the
thing they want to control will move by y. So they just look at how far
things are away from target and make a once-off move once the new data
appears, with a magnitude calculated to null out the error. If the rapid
slew when the adjustment appears is a problem, just apply some filtering
that's fast in relation to the sample interval.
This depends on a degree of linearity in the process.
That's easy to understand and easy to implement.
On Thu, 09 Jul 2009 16:57:28 +0800, Bruce Varley wrote:
It sounds like an integrating controller with output linearization, tuned
to be deadbeat.
Depending on how well known the command vs. output curve is you may want
to back off on the gain to avoid 1/fs oscillation.
It's probably better to not think of this as a PID algorithm, because the
action is not time-continuous. The gain is the relationship between
manipulated variable move ('knob') and the consequent controlled variable
Tim is right, if the gain is too high, you can get limit cycling at the
sample frequency, as the strategy overcorrects on every receipt of new data.
It's better to undercorrect than overcorrect, which is the same thing as
lowering the gain. When I'm applying this strategy, I always start with a
gain that I know is on the low side so that correction is only partial Then
as you monitor the behaviour over many cycles, you can tweak the gain up,
depending on how repeatable things turn out to be.
Sorry, I missed your other embedded questions.
wrote in message
With the strategy I'm suggesting, the raw correction would be applied as a
once-off change, ie. a step change. If you don't want the change made this
fast, you could apply a single lag low pass filter (Google) which will turn
the step change into something resembling a ramp, technically an exponential
response. The main requirement for this strategy is that all effects of an
adjustment must be well cleared before the next data point arrives. I'm
assuming here that your process will steady out a lot quicker than your
2-hours, then you could have a low pass filter with a time constant (Google)
of maybe 10 minutes, or even longer. For a single lag filter, just about all
the input will appear at the output in 3 - 4 times the time constant.
I'm not going to get into defining linearisation, someone else might oblige.
I haven't come across the deadbeat term before (thanks for a new word, Tim)
I assume the idea is that the adjustment 'hits the nail on the head', ie
achieves total, or approximately total, annulment of the error in one move.
Deadbeat controllers are not practical for most systems and are more
of an interest in theoretical work. The system must be well defined
like a hard drive. The Dahlin controller is much more practical. The
main point is the procedure for calculating the controller gains that
will give the desired response. The internal model control formulas
for pid gains are calculated in the same way but in the s domain.
On Fri, 10 Jul 2009 00:29:53 -0700, Johannes Eble wrote:
That's what I'd do. Most likely you want to ease the new command in,
instead of suddenly changing the engine operation (what are you
Assume that your engine has an command-to-consumption relationship
described by the function f(x). Then output linearization is just
driving the output with the inverse of the function -- so if f(x) = sqrt
(x), then you'd run your command through an x^2 block.
A deadbeat system is one that comes to a rest in a finite number of
samples -- for a linear system this will be no more than the number of
states in the system.
As Peter pointed out, most systems aren't even close to being well
behaved enough to be amenable to deadbeat control. It's of very minor
interest in those cases where the plant is well enough behaved to allow
it, and probably of more interest to serve as an absolute "you'll never
ever do better than this" upper limit to performance.
That won't matter much; as long as the engine always responds quickly
enough to input you can probably approximate it as responding
(I meant to say fs/2 here, where fs is the sampling frequency -- at any
rate it's when the system ping-pongs between being too high and too low
Yes, but it's the integrator gain you'd be lowering. The system as Bruce
described only needs integrator gain, if you're thinking of it in PID
terms. A pure-integrator controller is often the best thing to use when
you have a very prompt plant.
I've been trying to follow the discussion, but I evidently missed some
What can cause the fuel consumption to vary? Does the load vary? Is
there an attempt to keep the engine speed constant?
A system that uses an engine to accomplish a task, in which the
important aspect is fuel consumption rather than the task, seems odd.
More like an accountant's view of the project, rather than an engineer's.
If the system is reasonably linear for small changes, establishing the
system gain can be useful. Keep a record of the last correction applied.
When a new sample is received, calculate the change due to the last
correction, the new correction needed, and from these, the best estimate
of the correction to be applied. This works well when a system
correction will have fully settled before the next correction is
applied. That seems likely in this case.
Engineering is the art of making what you want from things you can get.
On Fri, 10 Jul 2009 13:28:26 -0400, Jerry Avins wrote:
I'm wondering that myself.
I can think of times when you may wish to servo the resource consumption
-- mostly in cases where you're strictly resource-constrained. A homey
example would be if you're broke (or snowed in) and you're almost out of
heating oil -- it's better to live for a week at 55 degrees F than to
have a nice warm house for three days and then freeze for four.
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.