Timing problem with writing to file with analog input

[JoachimTaelman]

Hello all,

I'm currently working on a datalogger from a NI cdag 9172 in labview. I have to admit that labview is new to me, so it could be possible that I made some basic errors. (This is also basic testing.

I enter the sample rate to my device to 1 kHz. Afterwards I want to show the data on the screen and save the data for use in matlab. Allthough, I've entered the sample rate to 1kHz, the data is stored to the file with a sample rate between 1.7 and 1.8kHz (not consistent) and not at 1kHz as I've selected. I've read tutorials and post in this forum, but I was unable to solve the problem.
I've tried several methods: the one with the DAQ-assistent and write data to file assistent. Afterwards I tried with the different blocks seperately and make the connections myself, but still the problem is the same.

Can anyone help me please? I will be very thankfull.
Joachim Taelman

[10Degree]

Joachim,

You might want to look at some of the examples in help for the task you are trying to do.  Take a look at “Cont Acq&Graph Voltage - Write Data to File (TDMS).vi” and see if that (or one of its relatives) is helpful for your application.  Some other thoughts:

You can get rid of the loop to create virtual channels, just pass your list of physical channels in (as they do in the referenced VI above) to create the channels.

You might want to consider laying out your application so that wiring goes from left to right, top to bottom.  LabVIEW certainly does not execute anything in this order (execution order is based on data dependency) but it will be generally more readable to the community of developers you may encounter.

Remember too, even though you use the timed loop structure, the lack of deterministic control in Windows will not guarantee an iteration every ms.  At best, you may get around 50ms resolution.

  -cb

[JoachimTaelman]

Thank you for your quick respond.

the lay out-issue was something I was aware of. Thank you for you tips.

I tried the examples you mention, but the timing problem stays: allthough I enter 1kHz as sampling rate for the device, the data is not stored at 1kHz at all.
Am I right if you suggest me to work without the time loop, as I use already virtual channels?

Joachim

[10Degree]

Joachim,

What modules do you have plugged into the chassis for measuring your voltage signals?  How many signals are you sampling - 4?  I will try a test here and see if I get reasonable data.

-cb

[JoachimTaelman]

I have a NI 9239 to sample 4 channels.
In the futere, 2 new NI 9239 modules will be used for a total of 12 channels.

[10Degree]

With 50kSamples/sec simultaneous there shouldn't be any issues with sharing bandwidth as in a multiplexed card.  I am curious, how have you concluded that your sample rate is different than how you configured the system?  I may not have understood your problem.  The waveform output from the DAQmx read includes a t0 start time, dt and number of samples.  Does this not agree with your setup?  It looks like you are doing 1000 S/sec, continuous samples, 100 samples per read. 

[JoachimTaelman]

I have saved the file and opened it with matlab.
A period of 5 seconds lasted for 9seconds, my 50Hz power line peak was at 31Hz.

[JoachimTaelman]

To show what I meant, I have attached a picture of the frequency plot of my testsignal (powerline 50Hz).
I took my tdms-file, converted it so I can process it further in matlab.
Here is the frequency plot of my signal: you can see clearly that the 50Hz peak is at a frequency of 31. So the data is written not correctly to my tdms-file where I store the data.

I also checked the t0, dt and y-values. The dt is 0.000620. What does this mean?

Thank you for your help and your time!

Joachim

[10Degree]

Hmm,  the dt in your waveform data is the time (in seconds) between samples.  Yours corresponds to a sampling rate of around 1612.9 samples per second.  Your earlier code seems to indicate that you are setting the sample rate to 1000 samples / second which should give you a dt=0.001.  Something indeed seems odd here.  Can you tell me what version of labview you are using?  We can try a few simple tests to see if things are working right.  Also, what labview package do you have?  If you have labview Full or above, you can do signal processing (FFT etc.) in labview to get things working before exporting to matlab for analysis. 

-cb

[Joe_H]

the first thing that I would try is to see if the loop finished late. You can do this by using the nodes on the inside of the loop. Just pull them down until you see the finished late node or by clicking on the node and selecting it. Write this out into an array on the output by using indexing. This should give some insight on the problem. if it finished late then there is something wrong on the acquisition part.