tachometer time synchronized with waveform time

[dmertz]

We ran into an issue trying to record both the speed/time from the OAT Tachometer.vi and waveform data from our other channels.  The problem is that the time shown in the waveform data is different from that in the tach signal.  I need to make sure my tach signal rpm data is synchronized with the data I recorded from my other channels (pressure, temp, etc). 

I am recording data to two different excel files using two different Write Labview Measurement.vis.  I have the "enable" switches tied together.  I record the data to excel from my .dat files.  Since the tachometer signal does not send "0 rpm" there is nothing in the excel file until I have a speed profile.  So I wait to record until I have a clear speed profile around 120 rpm and then record data.  Once in the excel files, I subtract the offset from the tachometer signal (Excel file #1) and the other waveform data (Excel file #2) so that both start at time zero.  I get about 0.5s extra recorded samples from #2.  Why do #1 and #2 not match?  Is there any way I can ensure that the data I am taking is occurring at the same time and one set does not lag the other? 

Thanks.

[Juan G]

Hi dmertz ,

Can you attach your vi so since I am not able to open it from the hotlink.

Regards,

Juan Galindo

Applications Engineering

[Delfo79]

Hi all

I also had a similar problem. In my VI, I want to acquire a waveform, starting from the moment when the speed goes over a threshold.

I have a loop that acquires a every iteration 1.5s of waveform and computes speed profile, then tries to cut the waveform when the speed exceeds the threshold value.

Unluckily, watching the speed profile generated by the VI "OAT Analog Tacho Process" (whose reset connector is set to FALSE) I can see that the time values are not in phase with the acquisition timelenght.

To give an example, at the 4th iteration of the loop, where I would expect values between 4.5s and 6s, usually the speed profile has a timelenght ranging from a bit more than 3s to 4.7s, which means, it is not a problem due to the loss of a cycle for initialization issues, otherwise its points would stay inside the range 3s-4.5s

I thought it could be a problem of buffer underflow, but even increasing the buffer lenght doesn't solve the problem.

May it be an effect of the interpolation in the computation of speed profile? Or do I lose some samples during the loop? (I close the acquisition channel only at the end of the VI, in every loop I just call the read VI)

Thanks in advance 

[Delfo79]

Hi all

I also had a similar problem. In my VI, I want to acquire a waveform, starting from the moment when the speed goes over a threshold.

I have a loop that acquires a every iteration 1.5s of waveform and computes speed profile, then tries to cut the waveform when the speed exceeds the threshold value.

Unluckily, watching the speed profile generated by the VI "OAT Analog Tacho Process" (whose reset connector is set to FALSE) I can see that the time values are not in phase with the acquisition timelenght.

To give an example, at the 4th iteration of the loop, where I would expect values between 4.5s and 6s, usually the speed profile has a timelenght ranging from a bit more than 3s to 4.7s, which means, it is not a problem due to the loss of a cycle for initialization issues, otherwise its points would stay inside the range 3s-4.5s

I thought it could be a problem of buffer underflow, but even increasing the buffer lenght doesn't solve the problem.

May it be an effect of the interpolation in the computation of speed profile? Or do I lose some samples during the loop? (I close the acquisition channel only at the end of the VI, in every loop I just call the read VI)

Thanks in advance 

[Logan_H.]

Delfo,

What sort of rate are you reading from the Tacho?  Also, can you give a bit more detail on the architecture of your program? What rate are you acquiring the waveform at? What sort of hardware are you using to take in the values?

In the mean time, this document explains a few reasons for delay in the OAT Analog Tacho Process VI and other Sound and Vibration Measurement Suite VIs.

 http://digital.ni.com/public.nsf/allkb/B46B0FA276FDEE288625758400767C5D?OpenDocument

Logan H

[Delfo79]

Thanks Logan for the link, it solved some doubts I had about OAT.

I'm sorry, I wasn't very clear in writing the question.

Anyway, I could find the solution. My VI was composed by a main loop. At every iteration of the loop the VI:

-  read 1.5s of waveform

-  extracted speed profile from the read waveform piece ("OAT Analog Tacho Process" was called with RESET to false, in order to take account of previous data too)

- compared the profile data with the speed threshold

Working this way, I did find that at every iteration I received the right waveform.

The problem was that the extracted speed profile was composed of instants in both the previous iteration and the actual one, while I would expect it to be composed only of instants either in the previous or in the actual one. And obviously didn't match the actual tacho waveform edges!

In the end I understood that the speed profile was computed taking in account both data from the previous tacho waveform piece and the just-acquired one: I modified my VI considering that at every loop iteration the speed profile was temporally translated respect to the waveform, and now it works OK.

Thanks again for the answer

Paolo