OAT Tachometer Incorrect Results

[Brian Davison]

I am receiving incorrect results from the OAT function "OAT Digital Tacho Process" in my trial application.  A quick summary of the hardware/software,

Windows XP

LabView 8.0

Order Analysis Toolkit

4 accelerometer channels through a USB-9233

Tachometer through a DAQPad-6015 (both PFI 3 and 4 are currently wired to tach pulse)

Bench test setup with a signal generator outputting a 0-5V squarewave at 100 to 6000 Hz.

When monitoring the "Speed Profile" cluster out of the OAT Digital Tacho Process, I see the time incrementing very slowly and the speed showing extremely high values.  Reducing the frequency of the signal generator increases the tachometer output speed.  When viewing the "Digital Tacho Info" cluster from the preceding OAT Build Digital Tacho Info function, I see the counter incrementing properly, the counter timebase equal to the analog signal sample rate, the task as event counting, and the counter bit as 32.

I believe the counter bit should be set as 24 for the USB-6015, correct?  Regardless, I haven't seen an effect on the tach output.

Any ideas on what's been wired incorrectly?  My program looks remarkably similar to the examples except for the hardware specific items but could have missed something 😉

Many thanks,

Brian    

[Daniel_L]

Hi Brian,

That's interesting behavior that you're seeing.  So you're basically seeing your time increment very slowly, and your speed being an unreasonable number?  If your OAT Build Digital Tacho info is looking correct, then it must be an input for your OAT Digital Tacho Process that is incorrect.  Can you check to make sure that the pulse per revolution and vibration signal duration values are correct?  And yes, the counter for the 6015 has 24 bits of resolution. 

Could you tell me a little more about your application?  If possible, I'd like to hook up some hardware myself and see if I can see the same behavior with your VI.  In the meantime, please troubleshoot the aforementioned inputs and see if you can get a different and more accurate reading. 

Thanks, and have a great weekend,

Daniel L.

Applications Engineer

National Instruments

[Brian Davison]

Thanks for the offer of assistance.  My vi will be applied to a machine monitoring application.  I am testing engine components on a test rig driven by an electric motor.  The motor control incorporates a 1024 pulse per rev quadrature encoder, giving me the option of either 1024 ppr or 1 ppr signals.  The unit under test will have four single axis accelerometers mounted, one in each of four stations.  I hope to quickly detect component failure in the UUT by monitoring these accelerometers.  One complication of this setup is a gear set between the electric motor and the components to be monitored, with the UUT driven at 2.4 times the encoder speed.

My bench test setup used a function generator to simulate the encoder pulses ( I tried both 1-ppr and 1024-ppr and made no attept to correct for the gear ratio) and I left the USB-9233 connections open.

As far as I can see, the output of the Build Digital Tacho Info function is correct.  The analog signal duration is calculated as it is in the examples.

I'm out of time and will provide more information soon.  Let me know any specific data you require.  Again, thanks.   

[Chen_Z]

Hi Brian,

In your code, you did not specify the counter timebase. As I know, DAQpad 6015 provides two on board counter timebase frequency 20M or 100kHz. It seems to me that you are using 100kHz as the counter timebase but specify 20M in the OAT Build Digital Tacho Info.vi.

In OAT example, it uses the oversampling clock from DSA board as a counter timebase. However, in your application, you can not get this clock, thus you have to specify a counter timebase manually.

You may try to input 100k in counter timebase [Hz] input in the OAT Build Digital Tacho Info.vi.

Let me know if it works.

Chen

[Brian Davison]

Thanks for the suggestion, Chen.  Unfortunately, the vi operates the same way regardless of the counter timebase input.  Setting the pulse per rev of the tach input to 1024, I get the following results:

17kHz input signal results in approx 5.2rpm indicated (should be 1000rpm)

102.4kHz input signal results in approx 0.86rpm indicated (should be 6000rpm)

290kHz input signal results in approx 0.3rpm indicated (should be near 17000rpm)

Brian

[Brian Davison]

I forgot to add a few more items:

The signal duration is calculated as approximately 0.035 seconds.  I have left the four USB-9233 channels open for this test.

Changing the ppr from 1024 to 1 will correctly modify the engine speed... i.e. an indicated speed of 0.3rpm at 1024ppr changes to approx 310rpm at 1ppr.

Brian

[Chen_Z]

Hi Brian,

Can you try the following again?

1. Change the input "synchronization type" to "by using reference clock".

2. Repeat to input 100kHz to "counter timebase[Hz]".

Let me know if this can work.

Thanks,

Chen

[Brian Davison]

Chen,

Changing to the reference clock doubles the engine speed output, but it is still incorrect and inversely proportional to the tach signal frequency.

Since I am new to DAQmx, I went back to basics and began examining the various DAQmx counter functions.  I found an interesting result when running the "Meas Dig Frequency - Low Freq 1 Ctr" example.  If you change the DAQmx Read function to Counter U32 1Samp from Counter DBL 1Samp, you get an incorrect frequency.  I've attached a modified example showing the the two results.

When I connect a 500Hz squarewave signal to the counter, I get the following output:

DBL output from the Counter DBL 1Samp = 500

U32 output from the Counter U32 1Samp = 40000

Shouldn't these two values essentially match?

Brian

[Neil_S.]

Brian,

I can observe the same behavior difference between the two configurations.  However, this behavior is expected.  To get accurate frequency measurements the documentation explains that you should choose the Counter DBL 1Samp instance of the DAQmx Read VI.  From the help documentation: "Reads one or more floating-point samples from a counter task. Use an instance that reads a floating-point value when NI-DAQmx scales counter samples to a floating-point value, such as for frequency and period measurement."   The other instance of the DAQmx Read VI should be used in cases where NI-DAQmx is returning a U32 value such as event counting.

Regards,

Neil S.
Application Engineer
National Instruments