Smoothing out VAV flow reading

[Milkman Spawn]

This is something stupid that has been bugging me for a while.

Usually I work with VAVs that are fully programmable and make use of a function to average or "smooth out" the velocity pressure since it tends to fluctuate quite a bit. The problem is, especially during balancing, the calculated airflow lags behind due to the averaging function and causes overshoot or undershoot when the damper is driving to meet the airflow target.

When I've worked with canned VAV apps like the siemens TEC, or even spyders(not canned but from an official library), the air flow reading is steady and when the airflow target is changed, the damper drives to meet the new target quickly and reliably. There is no overshoot and the airflow reading is steady.

I've tried things like only using the averaging function when the airflow is within a certain range of the target, but that produced mixed results. One option might be to use the raw airflow reading for control, and make a separate smoothed out value to display on the graphic, but that will be a bit of extra work. Just wondering if anyone has dealt with this in a fully programmable VAV app, or knows what's going on behind the scenes in a canned app.

[orion242]

Normally put a deadband on the PID driving the damper. Something like 5% of the current setpoint which typically keeps it from chasing the noise. If that's not enough, sometimes I'll use an exponential filter to smooth it out a bit. Don't normally need that though.

Any VAV controller that has a rock steady airflow reading is doing some sort of filtering in the background.

[Milkman Spawn]

Normally put a deadband on the PID driving the damper. Something like 5% of the current setpoint which typically keeps it from chasing the noise. If that's not enough, sometimes I'll use an exponential filter to smooth it out a bit. Don't normally need that though.

Any VAV controller that has a rock steady airflow reading is doing some sort of filtering in the background.

Yes a deadband is definitely required. The problem isnt that the VAV controller is 'chasing the noise', its that the filtered flow reading lags behind the actual flow. So by the time the filtered reading reaches setpoint, the actual flow is higher, and the filtered flow will overshoot or undershoot while it catches up.

[orion242]

its that the filtered flow reading lags behind the actual flow. So by the time the filtered reading reaches setpoint, the actual flow is higher, and the filtered flow will overshoot or undershoot while it catches up.

Sounds like you need to filter less, or use a different filter. Not a huge fan of filtering the readings for that reason.

[numbawunfela]

Filtering inputs is often done with a moving or rolling average. If the rolling average is accross a 30 second period, it will produce the issues you are seeing. If the rolling average is a 5 second period, that is usually short enough that the effect on control is minimal in the way you describe.
Less filtering is my reccomendation in this instance. Shorten the period on the rolling average.

[Paul Benkovitz]

It sounds like the canned VAV program filters more when there is no change of damper to prevent hunting, and less or none when there is a change of damper to prevent overshoot. In a fully programmable VAV controller that should not be hard. If I were doing it I would set the dampening values , and then subtract or divide them or turn it off when the PID is active. Either there will be an output on the PID that says it is out of deadband or you will have to determine that yourself.

[Milkman Spawn]

Do either of you have an example of the math for your rolling average, or exponential functions?

[Milkman Spawn]

It sounds like the canned VAV program filters more when there is no change of damper to prevent hunting, and less or none when there is a change of damper to prevent overshoot. In a fully programmable VAV controller that should not be hard. If I were doing it I would set the dampening values , and then subtract or divide them or turn it off when the PID is active. Either there will be an output on the PID that says it is out of deadband or you will have to determine that yourself.

I did try something like this, and still experienced some erratic behavior. Its possible the answer is it just requires some tweaking to find the sweet spot for the deadband of the PID and the speed of the filter function.

[orion242]

Do either of you have an example of the math for your rolling average, or exponential functions?

D = E*D+(1-E)*G

D = output
G = input
E = amount of filtering in the range of 0-1. Typical values 0.8-0.98 when I use it. Higher number = more filtering.

[Paul Benkovitz]

I am using ((G - D)/E) + D

D = output
G = input
E = Amount of smoothing, 1 is none, 10 is max.

It then goes through a ramp set at .05 increase/decrease every 30 seconds.

[Milkman Spawn]

Thanks, the math is helpful. I'll write it down in my notes.

[MaxBurn]

So is the PID simply inadequate for this job? Too hard to tune so it needs assistance?

I could understand if this were just for a display point. Behind the scenes I'm wondering how much goes on in controllers with canned programs and how OEM's are figuring things.

[Milkman Spawn]

So is the PID simply inadequate for this job? Too hard to tune so it needs assistance?

I could understand if this were just for a display point. Behind the scenes I'm wondering how much goes on in controllers with canned programs and how OEM's are figuring things.

The PID is fine, whether the airflow is filtered or not. If filtered, there is some overshoot when changing airflow targets. This is fine for normal VAVs but it has always annoyed me when air balancing because it takes too long. Without the filter there is no problem meeting the target quickly, however the reading jumps around a bit, which isn't a problem except for the optics to the end user. This is what I'm doing for more sensitive areas like labs, where a quick and accurate response is needed.

Just like you, I am curious what goes on in the canned programs where it just works so quickly and smoothly.

[orion242]

where a quick and accurate response is needed.

Normal VAV box with standard actuator, quick is relative term. Are they installed good? Aka no bull%hit right at the inlets?

however the reading jumps around a bit,

Is the damper & static constant while this is going on?

Just looking at what I have done, the airflow was not filtered. Program is written so the airflow sample, cfm calc, PID, output are all in sequence to make sure in->out is completed each cycle. With the PID I'm using, its integral only and a small deadband that less than whatever % TAB is shooting for. Not much magic there really outside of tuning the system as a whole. Have you looked for anything else in the system that's unstable? I'll typically slam on 1/sec logs on fan speed, static, handful of box dampers if things are PITA just to look for anything else fighting me. One damper changes, static changes, more dampers reposition feeding into itself with a slow responding fan / hyperactive boxes.

VAV box is what it is, its not going to match the speed of a venturi. Should be able to do a reasonable job with them. Some folks seem to expect venturi performance out of VAV. They need a bit of education.

[Milkman Spawn]

Normal VAV box with standard actuator, quick is relative term. Are they installed good? Aka no bull%hit right at the inlets?...

Is the damper & static constant while this is going on?...Have you looked for anything else in the system that's unstable?

Not really having control issues like that. Just trying to figure out how to get my application to look perfect just like a canned app. It sounds there is no hidden secret, just a matter of using the appropriate deadband and filtering. I think the PID and the filter function in my company's VAV app is just too slow and its been causing me headaches for years when balancing. Otherwise it works fine normally.

[numbawunfela]

The Distech and Johnson and Alerton and Delta canned VAV apps are completely modifiable... so I can get into the guts and see what they are doing and why. You can't do that with your brand of controller?
Some older stuff was configurable... so no visibility there. But not recently...

[Milkman Spawn]

The Distech and Johnson and Alerton and Delta canned VAV apps are completely modifiable... so I can get into the guts and see what they are doing and why. You can't do that with your brand of controller?
Some older stuff was configurable... so no visibility there. But not recently...

Negative, the new schneider VAV controllers are freely programmable, but the optional VAV component is a black box. I have also used siemens ATECs and the honeywell spyder VAV app. The ATEC is a black box, but the spyder is programmable. I dont have one i can look at though.

[orion242]

You can't do that with your brand of controller?

Seen a good few that have at least some 'black box' bs in the mix. Auto homing of floating point outputs, airflow cals, sensor zeroing, filtering applied to AIs by default, special box damper blocks that just take cfm & setpoint and deal with everything else.

Still wonder why HW uses K-factor & duct area in their cfm calc? Yet another box.