Convert a TTL to RPM numeric display.

[Feroz]

In the other method you are using, 'inf' shows up as your frequency because you are acquiring the digital signal using the 'On-demand' option in the Advanced Timing tab of your DAQ step.  Due to this, when you convert the digital signal to an analog waveform, the waveform doesn't have the same interval between the data points.  By this I mean dt is unknown in the waveform and hence the software sets dt to zero.  Because of this, the steps consuming the analog waveform will not be able to compute the frequency as they rely on the dt value in the waveform. 

In the method I mentioned, you should be able to get the lower RPMs.  I was able to do this on my machine.  I noticed that in your 'RPM ending.ppt' screenshot, there is an error in the DAQ step.  Can you tell us what that error is?  This will probably help us figure out why the RPM value is not being computed.

[Team Stoney]

Here’s what I do, step by step.

TTL signal to PFI1 (pin 16 and pin 1), NI 9401 in slot 5

Steps followed:

Acquire Signals >> DAQmx Acquire >> Counter Input >> Frequency – add channels to task – selecte ctr0

Click Run to test signal… I see 67 Hz in the “Measured Value(s)” field above; things look go so far. Click Stop and proceed to Processing step.

Processing >> Formula with Y= x0*60

Click Run, Click on Data View, Drag Processed Data over, change view to Gauge, I see what I am recording… 4kHz.  Things look good until I slow my rotating component to a stop.

The output (RPM) stops at approximately 900 to 500 RPM and sets an error “Sample Period Too Short”.  However, the chart display seems to update very slowly while giving an incorrect RPM… flat lined at approximately 500 RPM.

I am hoping to record 0 to 5000 RPM and have it plotted respectably.

As for the spike... It does not happen all the time and I'm not sure why.

Thanks,

Steven Stonecash

[Mark_E]

Hi Steven,

Is there an error number associated with the error message “Sample Period Too Short”?

I’ve tested the functionality using Feroz’s approach using a counter input. I generated my counter signal from the same 9401 as well as another DAQ card and I get the expected results all the way down to 1Hz (=60RPM). What happens when you try this? The way I did this was by using Measurement & Automation Explorer (MAX):

1)    Right-click the 9401 and select Test Panel.

2)    Click the Counter I/O tab. Choose counter 1 (ctr1) and choose a frequency. I started with 1kHz and later tested from 1-9Hz. Click Start.

3)    Wire the counter 1 output (pin 25) to the counter 0 gate (pin 16).

4)    Go to Sound & Vibration Assistant  and run the test to acquire the counter 0 input.

Is the processed data what you expect? If so, we may need to figure out what’s happening with the optical sensor’s output.

[hoffiz]

First of all it looks like you are doing everything correctly. I would you to take the chance and check this discussion forum:  Counter issues with cDAQ-9172 and 9401, also take a look at the User Guide and specification page 41 will give you more information on the counter task set up.

Can you try reading the frequency without doing any calculations? Can you check if you read 0.833 Hz when you read a 50 RPM signal? I was trying to replicate the issue but I don’t have anything that will simulate the frequency going to “zero”, the lowest I can go is 95 Hz, also can you click on details next to where you get the error “Sample Period too Short” that will give you a number and an explanation of the error.

 

[Team Stoney]

Here’s what I’ve done so far:

What I did:

Followed Elizabeth’s “Acquire Signals >> Counter Input >> Frequency.  Once you have finished setting the task up for one of the counters on your 9401, right-click on the newly created task and select Run.”.

What I saw: Within the newly created MAX, the “Measured Value(s)” Read the correct frequency… although it stops collecting/updating at 2 I believe to the “Signal Input Range Min setting of 2”  The system won’t let me pick 0 or I get a MAX error of “200527”.

Perform the same step in S & V Assistant and I get sample period to short error (w/o an error code #)

Mark,

No error number associated with the error message “Sample Period Too Short”.

What I did:

1)    Right-click the 9401 and select Test Panel.

2)    Click the Counter I/O tab. Choose counter 1 (ctr1) and choose a frequency. I started with 1kHz and later tested from 1-9Hz. Click Start.

3)    Wire the counter 1 output (pin 25) to the counter 0 gate (pin 16).

4)    Go to Sound & Vibration Assistant  and run the test to acquire the counter 0 input.

I get 1k in the “Measured Value(s)” field and my processed data 60K… both are incorrect.  As for my sensor, I’ve connected to a hand held display and get correct reading.

[Team Stoney]

Jamie,

Please take a look a my reply to Mark.

Thanks!

[Mark_E]

Hi Steven,

When you set up the counter 1 output (pin 25) in the test panel at 1kHz, the result should be that you get 1kHz at the counter 0 input (pin 16) in the Sound & Vibration Assistant. You said you got the 1kHz “Measured Value(s)” to display 1kHz and that the processed data shows 60kHz. If your formula is Y=x0*60, this is the result I was expecting you to get. What about it is incorrect?

In your slides (M steps – step 4) you say you expect your measurement to be 10. Why? What is the number of ticks per revolution that you expect from your signal source?

[Team Stoney]

Mark,

I misunderstood what the objective of the test panel was; it simulates a signal for Sound & Vibration to use… if I understand correctly now.  Here are my results:

Freq = 9000Hz, Processed Data = 540k

Freq = 1000Hz, Processed Data = 60k

Freq = 100Hz, Processed Data = 6k

Freq = 21Hz, Processed Data = 1.26k

Freq = 20Hz, Processed Data =  1.2k… but now I get a “Sample Period Too Short” w/o and fault code number.

Freq = 19Hz, Processed Data =  1.14k… still with a “Sample Period Too Short”

WRT to ticks per revolution I was expecting to see what my sensor was reading… not MAX’s simulated signal.

[Mark_E]

Hi Steven,

I am not able to reproduce your error. Let's disconnect your source altogether and talk about our test setup results until we find the source of the error.
It sounds like you got the counter output/input test to work at 1kHz when I had you do it in MAX. But what is the result when you output a counter at a frequency much lower than 1kHz, like 1 Hz? Do you still get the "Sample Period Too Short" error?
Is the number of ticks per revolution of your device actually 60, or was this just a number made up by Ima to illustrate a concept?
You also mentioned that your light wasn't on at some point. Is that an intermittent problem, or a regular occurrence? Does it ever blink? If so, when?
Let me know what happens when you limit your tests to just the cDAQ hardware and the signals generated from it. Thanks.

[pollon]

Hi Ima,

I was searching for an example to measure TTL signal and convert it in RPM and i found your post. Can it work on signal express or i must have sound and vibration?

Paul