PC Fan RPM Measurement and PWM Control

[beaverpelt]

Hi all,

So my needs are simple: I want to control a 4-wire fan's speed via PWM and measure its RPM with the integrated Hall effect sensor. Attached is my VI, called "Fan Control v1". My problem is this: The RPM measurement will sporadically return a very large number that I know is incorrect (from 4,000 RPM to over 1E6 RPM instantaneously, then back down to 4,000 RPM). I can separate the two functions into their own VIs (control and measurement), and they work perfectly. Pretty sure the problem is in my combined VI, since both functions work fine on their own.

Thoughts?

[RTSLVU]

First thing I see hs a stacked sequence, get rid of it. As soon as you start to reach for a stacked or even a flat sequence, STOP!  Think for a minute because there is always a better way.

A simple state machine is what you should be using here.

Your sequence causes your DAQmx task to be repeatedly created, initialized, run, and cleared.

You should create your task (once), run it (collect data in a loop), and clear it (once).  

[beaverpelt]

Yes, that makes sense, if I'm doing only 1 thing continuously (measuring RPM or controlling speed).

Now, given the fact that I need to both collect data (measure a frequency) and set a PWM duty cycle (continuously generate a frequency) at the same time, how do I practically do that? Can I set up both tasks once, execute continuously, and then clear them both once?

[beaverpelt]

UPDATE: RTSLVU, I was able to do exactly what you said by separating all tasks into 3 categories: setup, continuous execution, and closing all tasks.

However, I still have my original problem, which is speed measurements that occasionally jump up to about 750,000,000 RPM, corresponding to a measured frequency of 25 MHz, not at all possible with a 4-wire fan. Somehow the measurement and the control segments of the VI are clashing with each other.

[RavensFan]

You can figure out what is causing that problem and eliminate it.

Or you can set limits and say that any value above a certain value is too high and just use the last valid value.

[RTSLVU]

---

@beaverpelt wrote:

UPDATE: RTSLVU, I was able to do exactly what you said by separating all tasks into 3 categories: setup, continuous execution, and closing all tasks.

However, I still have my original problem, which is speed measurements that occasionally jump up to about 750,000,000 RPM, corresponding to a measured frequency of 25 MHz, not at all possible with a 4-wire fan. Somehow the measurement and the control segments of the VI are clashing with each other.

---

Those four wire computer fans are far from precision devices.

Have you looked at the signal with a scope?

Maybe there is noise present at certain RPM's that is confusing the frequency counter.

[beaverpelt]

RavensFan: I would rather solve the real problem and eliminate it. However, I also created a version that analyzes the output of the VI just as you say. It's a workaround that does not solve the original problem. Here's my scheme:

If a new measurement is more than 10% greater than the average of the last 3 measurements, then accept the aforesaid average as the new measurement. Otherwise, accept the new measured value.

This works fairly well, since the erroneous measurements happen once about every 30 or 40 measurements, and the measurements are such high frequency that there is no possibility the fan can physically increase its speed by more than 10% between subsequent measurements.

[beaverpelt]

RTSLVU: Yes, I agree. The computer fans are not precision sensors.

I have attempted to look at the signal with a scope as the VI runs, but the scope was messed up and I couldn't see enough detail in the signal.

If there is noise in the tachometer signal, it has to be caused by the PWM portion (speed control) of the VI. How do I know this? Because speed measurement and speed control function perfectly when separated into their own VIs and run one at a time. Only when I attempt to do both at once do I see the bad measurements.

[RavensFan]

---

@beaverpelt wrote:

RavensFan: I would rather solve the real problem and eliminate it. However, I also created a version that analyzes the output of the VI just as you say. It's a workaround that does not solve the original problem. Here's my scheme:

If a new measurement is more than 10% greater than the average of the last 3 measurements, then accept the aforesaid average as the new measurement. Otherwise, accept the new measured value.

This works fairly well, since the erroneous measurements happen once about every 30 or 40 measurements, and the measurements are such high frequency that there is no possibility the fan can physically increase its speed by more than 10% between subsequent measurements.

---

That sounds like a good plan.  Beyond that, or maybe before that, you could look at detecting if any given reading is greater than you would ever expect it to be.  So if 5000 RPM is your top speed, then anything larger than perhaps 5500 RPM could be regarded as an error and just ignored.

[beaverpelt]

Right, and that would be convenient, but unfortunately the erroneous readings overlapped the vicinity of my max true RPM (4,000), so I couldn't just cap it at a reasonable number like 5,000 RPM. Don't know if this was in the VI I attached earlier, but I had a needle gauge on the front panel I used to watch it happen real time.