Radiators and Fans

[BillA]

all rad and fan stuff here

insert blinking RED LIGHT

the sim is fun, but there is a train wreck dead ahead

where is the data going to come from upon which to base any calculation ?

Since87
you absolutely cannot have 'users' plugging in CFM values, they are WAY too ignorant
what will be used is the fan's spec'd free flow value which has no bearing on its output pushing through a rad
- if a semblance of accuracy is required the specific P-Q data must be pulled from the fan's graph
THEN matched to the rad's flow resistance

the air and liquid flow resistances are tedious to obtain, but not really so difficult
-> the dissipation is hugely difficult, and complex

note that in my rad testing (article) I 'quantified' only the liquid side dT
AND I used a air/coolant temp differential of 10°C (should have been 5°C to reflect a 'good' system)
but the lower the differential, the less capability the rad will have

properly done there would be an energy balance calc looking at both sides
- understand the problem: the quantities we are dealing with make such temp quantifications extremely difficult (= prone to error)

what needs to be derived are "dissipation/in³" values as a function of air velocity; for each 'type' of rad core

jeez, someone better start writing grant proposals
is there a research PhD in the house ??

[Since87]

Just want to let you know I'm not ignoring this issue. (In fact I mentioned it as a 'gaping hole' at one point.)

I need some time to get my head around the problem, but my understanding is a secondary issue.

The real issue of course is the testing and resultant data. Could you be persuaded to do enough testing that reasonable extrapolations over the popular families of radiators could be done? What form could such persuasion take? (I've got a firstborn I'd be willing to part with on occasion.)

It's possible that some of this data could be gotten from manufacturers. Lytron publishes the necessary data. (Although some rather extreme interpolation is required to get the thermal resistance for an arbitrary operating point based on the Lytron graphs.)

I assume auto manufacturers base their HC selection on some design criteria. (How relevant it is at our operating point(s) may be an issue.)

Any good shmoozers out there willing to try extracting data from manufacturers?

[BillA]

I have asked Cathar to post/link to the threads where he had tons of info related to the physical differences (tubes, fins, spacing), but other than some rough empirical 'results', nothing so detailed

feel free to correct me Cathar

any seeker of data from the mfgrs is going to encounter HUGE difficulties in the applicability of the data
-> our entire 'use range' is far far below their first datum

too little dT on both the air and liquid sides
(and this is precisely why the testing is so difficult)

what would it take ? money works wonders !
if I had a number to do I could probably get it down to 20hrs each
(to setup and calibrate is about 30hrs though)
you tell me . . .

[Blackeagle]

BillA,

I'm a bit afraid of the answer but how much to do a rad? Volume discounts?

[BillA]

10 at a time, perhaps $400 ea

it would require some careful thought to 'cover the waterfront' with only 10 trials

here is a better question:

what should the air/coolant temp differential be when testing rads ?

[gmat]

Good question. See my thread 'how it works'... i have no answer right now it's 1:30AM and i need some sleep...

[Alchemy]

Hmm. It's certainly not impossible to do this, but I'd like to know how detailed an experimental setup you're looking for? Or, put another way, how flexible do you want the data to be?

You could run every possible combo of fan, rad, and water flow rate under some standard test conditions to generate thermal resistance values from the water in the rad all the way to ambient temperature. Lotta work, lotta accuracy.

Or you could run a single test series and generate lots of empirical data that will apply to any fan you have a PQ chart for. Bear with me:


Setup the rad in a duct with a blower ahead of it. Run warm water through the rad at some constant inlet temperature. Measure incoming air temp, inlet and outlet water temp, and the temperature of the radiator metal in some corner (so the probe can be insulated from air and not affect airflow much). Measure pressure on either side of the rad in the duct and measure airflow with a pitot tube or something similar. Measure water flow rate.

By measuring the difference in water temp and using its specific enthalpy and flowrate, you can determine the heat load.

By adjusting the blower speed you can generate an air PQ curve with the pitot tube and pressure differential data.

By adjusting the flowrate of the water you can generate a water PQ curve.

By adjusting the flowrate of the air and measuring the temp diff between the air and the rad surface (and dividing by heat load) you can generate an airside thermal resistance/Q curve.

By adjusting the flowrate of the water and measuring the temp diff between the water and the rad surface (and dividing by heat load) you can generate a waterside thermal resistance/Q curve.


So there you go. Do this for every rad and you'll have water PQ, air PQ, water thermal resistance/Q, and air thermal resistance/Q curves.

It's pretty ambitious, I admit, but from what I hear of BillA's work, it seems he's done this sort of thing before.

I can work out a fairly detailed experimental method if needed, but I figure I'm just popping in with ideas here and there right now.

Good, you think?

Alchemy

[Cathar]

Originally posted by unregistered
I have asked Cathar to post/link to the threads where he had tons of info related to the physical differences (tubes, fins, spacing), but other than some rough empirical 'results', nothing so detailed

feel free to correct me Cathar

Been out all day - just got back.

Yeah, I had some stats on about 4 to 6 different radiators over at OCAU.

I was trying to draw some sort of correlation between facial surface area, thickness, and total fin surface area, the latter which is dependent upon the density of the fin folds.

I can't say that I really tried that hard though. I'll try and dig up some of the information posted, although Bill's own radiator review does give a fair indication.

One thing that did seem to come forward that thickness is highly over-rated. After some investigation on the heater-core style design I was unable to find any real benefit for going with a 3-core radiator (typically about 2" thick) over most 2-core rads (typically about 1.3" thick). The thicker the core, the lower the air-flow (higher resistance), the slower the water-flow (more total parallel tubes) resulting in a lower Reynold's number, and the third row is achieving poor efficiency due to the low air flow due to the weak fans (by industrial standards) that people use as the first 2 rows have already heated the air to a fair extent.

Seemed to me that the best sorts of radiators for computer cooling were large with lots of frontal area, 2-row-core, not too thick (no more than say 35mm deep fin area) with brazed-on fins and a high fin fold density (16+).

Of course, none of the above discussion answers the question of how to simulate a core, but it is intended to highlight the complexity and unobviousness (sic) of radiator performance.

[BillA]

a minimalist rad testing outline (prepared for a client) is here

there is nothing, no matter how simple, that cannot be made more complex
lord knows I am a Grand Master at such, but the goal is always the opposite
good designs are simple designs, quite true in testing

see no point in attempting to characterize the rad tube/fin profile surface temp,
no way to use the info and too prone to mounting induced variability

the other stuff was done, its described in the rad article
rads respond quickly and assessing equilibrium and valid mean values can be a real chore
even measuring in tenths (as compared to my norm of hundredths), the havoc caused by cycling AC is incredible
- then one has to figure out how to 'dump' the heated air so as not to jack up the amb temp

rad dissipation testing is a pain

a rule of thumb in rad design is that following tubes are only ~70% as effective as the preceding one
tubes can be offset but this then significantly increases the air side resistance, reducing the flow rate/velocity, etc

[Alchemy]

Originally posted by unregistered
good designs are simple designs, quite true in testing

Agreed. The less work, the less likelihood of up-f**ks. Perhaps the most important thing I learned from college. Er, other than learning how to drink entire bottles of rum in a sitting. Second most important, perhaps.

see no point in attempting to characterize the rad tube/fin profile surface temp,
no way to use the info and too prone to mounting induced variability

Well, you need some way to separate the heat transfer coefficients between air and radiator and water and radiator. This is the simplest way I can think of to try that. You're quite right that variability will be a pain, though. Obviously the temperature will change significantly depending on how far the water has traveled on the other side. Not sure what to answer to that except running replicates.

rads respond quickly and assessing equilibrium and valid mean values can be a real chore

Again, can't you just run replicates and analyze the data later to figure out an average and standard deviation for what you're trying to find?

then one has to figure out how to 'dump' the heated air so as not to jack up the amb temp

Ooh, that's a very good point. Ambient temp really changes that much in your testing lab? If so, you can still measure delta-Ts to figure out what you're trying to do, but the fact you're trying to test a dynamic system does indeed make for a pain in the ass.

Alchemy

[BillA]

"you need some way to separate the heat transfer coefficients between air and radiator and water and radiator"
no
read more, post less

I characterize wbs without ever touching 'h'
and in the rad article (imperfect as it is by my standards of today) I did the same

while the equipment designer needs a 'value' for 'h', the applications engr does not
-> the (apparent) thermal resistance/impedance works just fine
and this is what I characterize

do (re)read that rad article, focusing on the methodology
and understand that the data illustrated with the graphs can be swapped around for different presentations/relationships

I could write 10 pages on the testing necessary to characterize 'h',
and then refer you to 10 books or so on CFD modeling so you could use 'h'
but none of this is relevant to the task at hand

"can't you just run replicates and analyze the data later to figure out an average and standard deviation for what you're trying to find?"

lol, with whose budget ?
the rad article took me 8 fu*king months, deduct at least half of that for my ignorance and its still 4 months
yea, I know all about 'replicates': 30hrs X 10 = 300hrs
-> and replicates are not the principal issue, it is the grid spacing and consistantly relating that to different sizes and types of rads
- validation will not occur by virtue of running replicates if the same 'error' is simply being repeated over and over

the 'right' software would help, I have now converted almost everything over to GIPB (IEEE 488) instruments
but LabVIEW costs $2000
donations ?

"Ambient temp really changes that much in your testing lab? If so, you can still measure delta-Ts to figure out what you're trying to do, but the fact you're trying to test a dynamic system does indeed make for a pain in the ass."

if you cannot maintain the inlet air temp when testing rads, you will chase your tail forever

Alchemy
you need a couple of years in an R&D lab to give you some perspective on that of which you blithely speak
then a year or two in mgmt making up budgets to pay for the data

simple little graphs can cost 10s of thousands of dollars
and may be worthless if the 'experimental design' was flawed

[Alchemy]

Originally posted by unregistered
Alchemy
you need a couple of years in an R&D lab to give you some perspective on that of which you blithely speak
then a year or two in mgmt making up budgets to pay for the data

I speak blithely because nobody seems to be paying me to do otherwise. I'm throwing out ideas based on theory because my research for the past two years has not been in heat transfer, so I lack the experience to know what tests are difficult and why.

I come here to take breaks from doing my own research, industrial design assignments, and studies. I don't have the time to read long experimental methodologies. I'm giving opinions based off the top of my head because I don't want to pull out my texts and call up CEP articles and read a webpage telling me why Joe Schmoe in Tuscon thinks airflow isn't important in a radiator. I honestly don't care.

If you expect me to become an expert in designing small-scale heat transfer applications for free when I have quite a few more important things to do right now, I think you are being unrealistic.

Alchemy

[Since87]

Originally posted by unregistered

the 'right' software would help, I have now converted almost everything over to GIPB (IEEE 488) instruments
but LabVIEW costs $2000
donations ?

The $4000/10 rads is quite reasonable IMO, however given my previous experience in trying to raise money from those interested in watercooling data, I don't think there's a chance in hell of reaching that number in cash. Other forms of compensation?

Any idea how new the copy of LabVIEW would need to be? There's an old (~5year?) copy of LabVIEW at my employer's somewhere. There's a slim chance it might be available rather cheaply.

Another option is to write a specific control program for the testing to be done. It's fairly simple to write software to control instrumentation. (Debugging it, when the instruments are in another location, could be a pain.) I could write a bare bones control program to automate the testing given adequate information on the command set of the instruments/controllers.

What would it take to make the testing 'push button' for you? Is there custom hardware that would help? I can design and build things that aren't available 'off the shelf'. (One example that comes to mind - Lytron 6320, Maxijet 1200, El cheapo waterblock with a heating element attached, sensor and PID control circuitry - low airflow resistance +/- 0.1C air temp regulator. Temp would have to be regulated to something above max ambient.)

I got the impression you were interested in one of my employer's products. Would getting that 'at cost' be of interest. (A not for resale agreement would be necessary, as it definitely won't fly if it might eliminate a 'real' sale. If interested email me, because I won't say anything more explicit 'in public'. I'm not talking anything illegal/unethical, just competitor/customer relations issues.)

[BillA]

no problem, valid enough
its 'off the cuff' because you're not being paid

hmmm

methinks the fool is I

[BillA]

Since87

ah yes, that drop-dead power meter (had forgotten that beauty)
no, for my purposes I can get by with 5½ or 6½ digit dmms,
but a good thought

re the software:
have (very) limited exp with LabVIEW 5.1 and 6.1, the latter being far better for ease of use
(by the ignorant/untutored such as I)

am exploring Matlab as their Control Box should provide all that I would need (??)

what I need to accomplish is not difficult given that it is the control of GPIB instruments,
but the learning curve for this can be quite steep when done w/o prior experience
- the value of LabVIEW seems to be with the virtual instrument drivers which enable instrument setup and control through the GUI w/o ever having to program anything;
Matlab I think requires use of the GIPB command instructions

I had an offer of assistance from a metrology guy, but it vanished when he understood that I had a budget of zero for $1500 PCI DAQ cards

my simplistic appraisal of the 'need' is this:
- no control required, though with LabVIEW PID controllers and such are quite simple to setup - just REAL difficult to 'tune', and the requisite flow control hardware is unknown to me
- just data acquisition; hit 'START' and everything starts recording at the frequency/interval defined
. several parameters need a 'live' display as they are the 'controlled variables', and need to be viewed as a graph

this the kind of 'system control' you had in mind ?

[jaydee]

I am not even close to being able to discuss the technicalities of testing these rads and fans, but I will throw out a simplistic view/question.

Say your test setup is with a shroud that is say 2" from the radiator. Now you test your 10 rads and 10 fans the same way each time and come up with a set of numbers that are entered into this proposed calculator.

Now my question is, what happens if someone goes by this calculator but ends up not using a shroud, using a shroud that is 3" away from the rad, using a shroud 1" away from the rad, or any other combination OTHER than what has been tested??? Does this not complety destroy any accuracy in such results from the test and void any usefullness in such a calculator for any person that is not going to mount the fan/rad identical to the test setup??? Also what if the given airflow to the intake of the fan is resricted because of a fancy fangrill, inside a case, or for whatever other 100 reason that may come up? :shrug:

Maybe I am just not sure what your all trying to acheive here. Which brings up another point. This calculator is going to need a user guide on why it works, what has been done to make it work, and what other issues/variables (that may throw off the results from the calculator) the person using it needs to consider when attempting to build a system from it. This user guide may very well be more complex than the actual calculator? :shrug:

[Since87]

Originally posted by jaydee116
I am not even close to being able to discuss the technicalities of testing these rads and fans, but I will throw out a simplistic view/question.

Say your test setup is with a shroud that is say 2" from the radiator. Now you test your 10 rads and 10 fans the same way each time and come up with a set of numbers that are entered into this proposed calculator.

Now my question is, what happens if someone goes by this calculator but ends up not using a shroud, using a shroud that is 3" away from the rad, using a shroud 1" away from the rad, or any other combination OTHER than what has been tested??? Does this not complety destroy any accuracy in such results from the test and void any usefullness in such a calculator for any person that is not going to mount the fan/rad identical to the test setup??? Also what if the given airflow to the intake of the fan is resricted because of a fancy fangrill, inside a case, or for whatever other 100 reason that may come up? :shrug:

You have very good points here. I brought up similar issues earlier. Another issue is, 'What other fans are in the system, are they blowing or sucking, and how hard?'

These are the reasons I'm inclined to just go with a user input CFM (or CMM) and a report of the dP needed to achieve that CFM. (Not to mention the huge variety of fans which may be used.)

Originally posted by jaydee116

Maybe I am just not sure what your all trying to acheive here. Which brings up another point. This calculator is going to need a user guide on why it works, what has been done to make it work, and what other issues/variables (that may throw off the results from the calculator) the person using it needs to consider when attempting to build a system from it. This user guide may very well be more complex than the actual calculator? :shrug:

I see the main benefit of the simulator as a way to compare different systems of components.

If I have to have a MCW462-UH, (because blue is my favorite color) then what pump and rad are the best 'fit'? (With the block, and my budget.) A pump and rad that are 'good' choices with a White Water may be poor choices with a MCW462-UH.

By playing around with the simulator and trying different combinations of parts, people can determine what factors make a difference they consider worthwhile, and what factors don't.

IMO, the simulator doesn't need to be extremely accurate at real world predictions, to be useful in comparing setups. Results that closely match actual setups are certainly desireable. Finding out why simulations don't match reality, and if it is feasible, correcting the problem will be important. There are too many issues the simulator can't account for to expect extremely accurate results though. (e.g. TIM joint)

My impression is that what is most frequently misunderstood is the 'wetside interactions'. I believe the simulator could be very useful in allowing people to 'see' those interactions.

[bigben2k]

Right, but as Bill pointed out, the user data would need to account for the pressure drop (air), otherwise it's useless.

I don't know about ya'll, but I am very concerned with the water side restriction, and it is on top of my list, as a selection factor.

Otherwise, the size will be dictated by what I can fit, which in my case is 6 by 8. I'm also opting for a 2.5" thick heatercore, for maximum surface area, because although I plan to use a blower, I know that most of the performance will depend on the airflow, not the water flow (rate or turbulence), and a simple axial fan is not likely to have the necessary pressure.

That's my logic.

Now if I can get an idea of how I can expect this setup to perform, great! Maybe it'll tell me that a specific axial fan would cut it, or maybe it'll tell me that I ought to consider a bigger blower.:shrug:

[BillA]

the CFM issue is more vexing than it may appear

and is manifest in its fullest dimensions here
I do like overclockers.com ('cause they post my scribbling ?), but the forums seem to be getting ever 'less experienced'
- now who says I can't be delicate ?

not too many WCers know too much about fans, and certainly not enough to make even much of a guess about what the actual throughput might be

JD
your questions are valid, not all are so critical, and must in any case be approximated
many variables can be 'eased' into with a factor which could be added or subtracted as appropriate
(use a checklist: fan standoff - 1", 2"; restrictive grill - yes, no; etc)

our basic problem is going to be the data itself
I think a program using it is quite doable (focus on simple always)

[Since87]

Originally posted by unregistered

re the software:
have (very) limited exp with LabVIEW 5.1 and 6.1, the latter being far better for ease of use
(by the ignorant/untutored such as I)

The guy, who knows where the software would be, wasn't in today, so I don't know what we've got. I'd guess it predates 5.1.

Originally posted by unregistered

- the value of LabVIEW seems to be with the virtual instrument drivers which enable instrument setup and control through the GUI w/o ever having to program anything;
Matlab I think requires use of the GIPB command instructions

I haven't used either, but it is my understanding that LabVIEW is very user friendly.

Originally posted by unregistered

my simplistic appraisal of the 'need' is this:
- no control required, though with LabVIEW PID controllers and such are quite simple to setup - just REAL difficult to 'tune', and the requisite flow control hardware is unknown to me
- just data acquisition; hit 'START' and everything starts recording at the frequency/interval defined
. several parameters need a 'live' display as they are the 'controlled variables', and need to be viewed as a graph

this the kind of 'system control' you had in mind ?

What I had in mind was a system where you setup the hardware, start the software, go to bed, and look at the results file the next morning.

It sounds like you need to tweak things on the fly. What would those things be? What would it take to automate? Fan speed (of a DC fan) would be simple enough to control based on feedback from flowrate sensors. (A single fan providing a wide enough operating range might be a problem.)

How do you control water flow? Is it set and forget, or does it need frequent tweaking? I presume there are electrically controllable valves available. Mfgs?

I can write software to do the direct GPIB control of the instruments and come up with some computer interfaceable device for controls. It probably wouldn't be very user friendly by todays standards, but is that an issue? The software could just output a data file that could be pulled into Excel.

What I'm proposing would be nowhere near as flexible as LabVIEW. If you upgrade an instrument for example, the software would need to be partially rewritten to interface to the new hardware. If this could get the job done though...

[BillA]

Originally posted by Since87
. . . .
What I had in mind was a system where you setup the hardware, start the software, go to bed, and look at the results file the next morning.
. . . .

WHAT ?
it won't change the wb automatically after sensing equilibrium for 20 min. ?
what a pissant system
jk jk

no interactive control needed, once 'properly' set
(takes some tweaking to get the mean coolant flow where desired)
everything else is quite stable

off one GPIB port I'm using a Keithley 706 scanner with 5 cards, to which is daisy-chained:
Philips 2534
Keithley 195A
Fluke 8840A
HP 3490
Fluke 2190A
- actually only envision using 25 channels or so
(though more would be 'setup' for different testing configurations)

and off a separate GPIB port an HP3456A reading just 4-wire resistance to 6½ digits in 100 reading 'batches' and running a stat analysis on them (but the switching still being done through the 706)
and possibly a Fluke 2180A and 2300A together as well

I don't stand a snowballs chance in hell of writing a GPIB program for these - way too much multiplexing
I do have the manuals for everything, but thats it

but Since87, is this a productive use of your time ?
let me poke around a bit and see if I can come up with some 'store bought' software

anyone have experience with the Matlab Inst Control toolbox ?

[gmat]

Originally posted by unregistered

and is manifest in its fullest dimensions here

OMFG. We really need that sim !

Originally posted by unregistered

(use a checklist: fan standoff - 1", 2"; restrictive grill - yes, no; etc)

our basic problem is going to be the data itself
I think a program using it is quite doable (focus on simple always)

Yep.
What i propose is:

- a set of standard fans, on which we have good data direct from the mfger. The Papst are good candidates, Comair as well, i don't know about Panaflo's (do we have pressure.flow charts for them ?). If we take the Papst 4412 NGL, the Panaflo L1A and the Comair Rotrons in 120 and 172mm we'll cover 90% (random figure, it may be like 95%) of the watercooling population.
- Pressure/ air flow charts for rads of course.
- we'll assume the fan is shrouded, and about 100% of the rad surface is available.
- we'll assume the fan is pulling air, and the rad is exposed to ambient.
- we'll assume the shroud is 'sealed' (like D-Tek's one) so no lateral losses
- there will be a red warning telling those assumptions. The user then will know he'll get worse performance if he doesnt take precautions, or better performance with a push/pull setup.

[Since87]

Originally posted by unregistered
but Since87, is this a productive use of your time ?

There hasn't been any "productive" use of my spare time since I discovered water cooling forums last summer. This would at least give me a reason to learn to use MS Visual C.

Originally posted by unregistered
WHAT ?
it won't change the wb automatically after sensing equilibrium for 20 min. ?
what a pissant system
jk jk

What? Deprive you of the pleasure of redoing the TIM joint multiple times? Never.

Originally posted by unregistered

no interactive control needed, once 'properly' set
(takes some tweaking to get the mean coolant flow where desired)
everything else is quite stable

I did a bit of googling. Johnson Controls has "proportional control" electric ball valves. Didn't find much technical detail though. Hard to say how easy it would be to control such. These valves may not be adequately stable when set between full open and full closed. Also, backlash could make the control system a bit tricky. Possibly worth considering though.

Does the coolant flowrate really need to be set accurately as long as it is known accurately?

Originally posted by unregistered
off one GPIB port I'm using a Keithley 706 scanner with 5 cards, to which is daisy-chained:
Philips 2534
Keithley 195A
Fluke 8840A
HP 3490
Fluke 2190A
- actually only envision using 25 channels or so
(though more would be 'setup' for different testing configurations)

and off a separate GPIB port an HP3456A reading just 4-wire resistance to 6½ digits in 100 reading 'batches' and running a stat analysis on them (but the switching still being done through the 706)
and possibly a Fluke 2180A and 2300A together as well

I don't stand a snowballs chance in hell of writing a GPIB program for these - way too much multiplexing
I do have the manuals for everything, but thats it

It could be difficult to set this up via email. In a sense, you would have to write the program anyway. All I could do is translate your writing into C-language and GPIB commands.

I did look up the test equipment. It appears the 706 has an 8 bit digital I/O port. That port could be used for communicating settings to a fan speed controller and a flow control valve.

If I could do this 'hands on' it would be fun. The multiplexing might make it impractical via email. I'd need a detailed schematic of the setup to have any hope of getting it right. I'd also need photocopies of all the GPIB command stuff in the manuals and maybe the whole manual for the 706.

It's certainly doable, and I'm motivated to do it, if it substantially increases the likelihood that rad data would be available for the simulator. It would be a one tricky pony though, so maybe not of interest?

[BillA]

boy, we're sailing off the deep end here into testing, but I'm game (and obviously interested)

I think I have resolved the software 'issue', lets bank that one for a while

the control feedback/automation is of interest and potential utility
3 parameters being able to benefit: coolant temp, coolant flow, and air flow

the coolant temp is stable (±0.02°C fluctuation), but subject to drift as the outside temp changes form night to day
- the pump, chiller, and cross-flow brazed plate heat exchanger in the chiller bath are all outside
(too much heat and noise)
I suspect that with a DAQ board having a 16 bit analog output it would be simple enough to gin up an interactive chiller control
- the chiller is now remotely controlled with a precision microvolt (calibration) source, but such devices with GPIB control are VERY expensive (0.0001 VDC = 0.01°C)

coolant flow is a can of worms as the system length is ~11' and I have 3 oscillations of different periods
the flow rate is quite stable but understanding the actual range (to 'set' the mean can be vexing)
- I know of no single throttling (needle) valve whose effective range spans my flow rates (0.3 to 4 or 5 gpm),
nor with the sensitivity needed in an 'automated' controller
??
BTW, it does need to be set accurately for the 10 mountings as these are single point readings,
otherwise no, not at all critical - so long as accurately known

air flow can be difficult to stabilize, at specific flow rates the fans may sync, the flow start pulsating, really bizarre
(the compressibility of air is quite apparent)
I started with mechanical dampners, went to huge pots from welding machines (10A of fan current is no joke), to 115VAC fans with Variacs
- don't think its worth the effort (not actually running enough hours, at least for now)

I have a different question for you:
in running 4 - 20mA transmitters, I have a huge settling time (as in hours) to read at the 100pA level (Setra units, Foxboro only to 1µA)
which I believe is caused by the transmitters and not the meter, a Keithley 195A
-> can I switch in and out a resistive dummy load in the transmitter current loop when its not being read ?

[Alchemy]

Originally posted by Since87
I did a bit of googling. Johnson Controls has "proportional control" electric ball valves. Didn't find much technical detail though. Hard to say how easy it would be to control such. These valves may not be adequately stable when set between full open and full closed. Also, backlash could make the control system a bit tricky. Possibly worth considering though.

No valve is stable across its entire range of % open, but yeah, I'd expect a ball valve to be more difficult to control than a linear or proportional valve.

A P-only controller has the downside of being slow to act and having an offset, so usually it's impossible to get a flowrate to be fixed on a single value - it will hover near the value, but almost never land directly on it. PI controllers are much better with accuracy, though more difficult to tune.

It would be important to know what sort of flowmeter is used with the controller and valve. If it's not terribly accurate, P-only would be adequate, as anything more advanced would still be operating off incorrect flow signals.

Alchemy