Effects of using time delays in real time acquisition

[AmnaG]

Hi,

       It might be a very basic question but it's confusing me. I have seen many programs with time delays. But when we are working in real time then how the time delays would possbily be affecting the actual timing of acquisition. Are these effects basically changing the sampling rate (samples per second). While, without time delays VIs will run so fast that we would not be able to intepret any charts or spectrums.

Hope it makes sense, thoughts?

Regards 

AG

[Lennard.C]

Hi,

Well, it depends on your application. Basically, those functions that is related to time delays like Wait (ms) or Wait until next (ms) Multiple are used to control the frequency of a while loop (let's say you have different while loops). Another use of these is to control the acquisition rate. For example, we use can Wait until next (ms) multiple to make acquisition loop to acquire data at multiples of 10ms so the data acquisition process will acquire every 10ms (that is if the acquiring process takes less than 10ms).

In real time, we use time delays to introduce sleep. Giving non deterministic tasks some time to run while the deterministic tasks sleeps. This is to prevent something we call starvation: https://www.ni.com/en/support/documentation/supplemental/15/multithreading-in-labview-real-time.html

You can take up some LabVIEW basic courses and you can learn more about software timed controls using time delays and etc. 

Here's some link on timing related subjects for LabVIEW:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P82BSAS&l=en-US

http://www.youtube.com/watch?v=uHIMRFeaQqc

Hope that answers most of your question. 

Warmest regards,

Lennard.C

[RavensFan]

Yes.  But it all depends on how you are acquiring the data.  If you are doing single point data acquisition, then a loop will run as fast the PC and the DAQ card will allow.  If you are doing continuous data acquistion with a DAQ card that has an internal timing source, the data will be collected at the sampling rate assigned to the DAQ card, and the overall loop will run as fast as it can as a function of the number of samples and sampling rate.  Unless there is something else in the loop that takes a long time to make it run slower.

[Lennard.C]

---

@RavensFan wrote:

Yes.  But it all depends on how you are acquiring the data.  If you are doing single point data acquisition, then a loop will run as fast the PC and the DAQ card will allow.  If you are doing continuous data acquistion with a DAQ card that has an internal timing source, the data will be collected at the sampling rate assigned to the DAQ card, and the overall loop will run as fast as it can as a function of the number of samples and sampling rate.  Unless there is something else in the loop that takes a long time to make it run slower.

---

Yup, it also depends on how you set your data acquisition or control using DAQmx APIs or DAQ Assistant Express VI. 

[AmnaG]

Thanks for detailed explanations. 

 Yes that's what I was thinking. Becasue I will be acquiring data at rate of 512 Hz in an array format. And what I am doing is taking samples let's say 255 samples and plotting it every time, that means I am plotting 0.5 second of my original data. But then I realized that I am also using delay in my while loop. So basically I just want to make sure that the data of 255 samples which I am plotting everytime on waveformchart is basically 0.5 sec of my original data time but not labview time in which I am using delays.  

Regards

AG

[Lennard.C]

Hi, 

If the data you're getting is in waveform format, you can check it's dt by using Get Waveform Components.vi (https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/functions/get-waveform-components.html I believe your dt should be at 0.5?

Warmest regards,

Lennard.C

[AmnaG]

Nopes basically it's in an array format.

[Craig_]

The DT would be the time between each sample.

You do not need to add waits to your loop because the DAQmx read will wait if samples are not ready yet.

[RavensFan]

We'd have to see your code and how the DAQ tasks are set up to give you the best answer.

But if your data acquisition task is controlling the rate of the loop, you do not need a wait statement in the loop.

Okay, Craig already made the point I wanted to make.  I started typing but got sidetracked before I could finish and post the message.