Sample Clock Rate, Calculating RPM

[MeCoOp]

To summarize my situation I have propeller anemometer that outputs a 0-10 volt square wave signal; 10 pulses per revolution.  I am using a NI USB-6341 for the data acquisition.  I have a program set-up that is supposed to count the number of pulses for "x" amount of samples and then calculate the number of revolutions and RPM.  The end goal is to use either the revolution or RPM calculation and correlate it to airflow, CFM.  At the present I get small variances in my calculated values that result in large shift in my CFM readings.  It could be the bearings of the propeller or some other hardware issue but before I go that route I'm hoping to get some feedback on the program I have so far.  I'm afraid I may not be using the sample clock rate property correctly or maybe calculating the data incorrectly.  I'm open to suggestions.

Thanks in advance!

[Drew_T]

MeCoOp,

First off, this sounds like a really neat application!  I am wondering where the calculation for CFM is, but I think what you are experiencing is just noise.  However, it would help if you could point out what calculated values are experiencing variations, and how those variations are presenting.

Regarding your code, it looks pretty good, although i would use shift registers to get the edges counted and sample clock rate into the Frequency case of your case structure instead of local variables.  Finally, since the sample clock rate is defined by you, it is unnecessary to pull the value out of a property node.  

Good luck on your application and let me know more about whats going on with it!

Drew

[John_P1]

Mi MeCoOp,

Nothing wrong with the local variables here, I think people tend to recommend against them because if you're not careful it's easy to create race conditions.

The property node to read back the sample clock rate is actually recommended/necessary, since DAQmx coerces the sample rate if you don't specify an integer divide-down of one of the internal timebases (100 MHz, 20 MHz, or 100 kHz on your board).  In your case, 3000 Hz becomes ~3000.03 Hz (100 MHz / 33333).  Analog input rates always coerce up.

Anyway, you could be off by ±1 pulse of your external signal depending on its phase.  For example, if the rising edge happens to occur right after the task is started, you might see one higher count than you would if the rising edge occurred just before the task was started.  I don't know the frequencies you are measuring, but do you think this explains the error you are seeing?

While your approach does have some potential, the best solution would be to condition the external signal to be 0-5V TTL, then use a counter to perform a frequency measurement on the 0-5V signal.

Best Regards,

[MeCoOp]

Hi John,

The purpose is to be able to monitor airflow as it changes so the frequencies will change depending on the UUT.  I do believe it could be something in the counting method since these slight changes in count drastically change my calculated CFM.  I took the CFM calculations out to avoid confusion, it is simply a function of the pulse count calibrated to a known airflow.  I have looked into conditioning the signal to 0-5V but didn't have much success.  I tried to build a voltage divider with (2) 10 Ohm resistors but it appeared to drain the power supply to the anemometer and the resistors were incredibly hot.  Electrical theory isn't my strong suit so I'm open to any suggestions.

I've worked on the *.vi since my initial post but I haven't had a chance to test it yet.

Thanks.

[John_P1]

Hi MeCoOp,

A resistive voltage divider should work to bring the voltage down to 0-5V, but you should use higher resistors than 10 Ohms (The combined 20 Ohm rsistance will draw 500 mA from your 10V source, or 5 Watts of power).  Maybe instead try using 10k resistors if you have some available.

Anyway, the Analog method is also a viable approach, but the downside (in addition to added software complexity) is that your measurement error is ±1 count of your input signal.

Moving the configuration outside the loop is also a good step to eliminate unnecessary hardware calls.  On that note however, why not just make the task continuous so you don't have to start and stop it repeatedly inside the loop?

Best Regards,