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?
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 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 this.
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).
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.
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.
If the drift is measured in days, then a two-hour sampling interval isn't that bad.
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 'smart operators').
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 controllers.
In your case I think a regular PID with output linearization would work pretty good.
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.
thanks very much for your h> > > 'smart operator'. Smart operators know that if they move the knob by x,
How does this filtering work? Should it have a higher sample rate, i.e. should I use a sort of sample rate conversion?
What is output linearization? What do you mean by deatbeat? It could be that my controller will have a variable sample rate if the intervals it gets the new sensor values are varying.
Do you mean I should lower the gain (i.e. the P in PID)? What is 1/fs oscillation? fs is the sampling frequency?
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 move.
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.
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.
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.
I've been trying to follow the discussion, but I evidently missed some critical details.
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.
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 adjusting, anyway?).
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 instantaneously.
(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 every sample).
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 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.
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.