From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

wait in while loop

Hello all,

 

 

I know this is a stupid question but I was really confused about the wait function.

 

I have read the description and I didn't quite get it. I thought that if I put a wait function in a while loop, then the system would wait for a certain amout of time between two iterations. So I tried to build a really simple VI taking data at 400s/s. Each iteration took 10 data and there was a 1000ms constant wired to wait function. It turned out that there was't a wait between every reading of 10 data, but the wavechart did update quite slowly(about 1000ms per update).

Did I understand it wrongly or did I built the VI incorrectly? Then what's is the correct way if I want the while loop to pause for a certain amout of time before the next interation?

Thank you!

 

 

0 Kudos
Message 1 of 5
(6,364 Views)

What you did was make it so the while loop waited at least 1 second before it ran again. You did not tell anything inside the while loop to slow down. So, everything went as fast as it could until it was done, then waited around for the rest of the 1 second until it started again. If you want the loop to pause for (almost) exactly 1 second between acquisition spurts, then add a 1-second wait inline with your acquisition step, either by putting your error wire through a (shudder) sequence frame or making a little subVI which has just a wait timer and an error wire going through it (roll your own, or I believe you can just use one of the Open-G timer VIs). Remember that Windows is not an exactly-timed (deterministic) OS, though, so you may well not get exactly 1 second between bursts of activity.

 

Cameron

 

To err is human, but to really foul it up requires a computer.
The optimist believes we are in the best of all possible worlds - the pessimist fears this is true.
Profanity is the one language all programmers know best.
An expert is someone who has made all the possible mistakes.

To learn something about LabVIEW at no extra cost, work the online LabVIEW tutorial(s):

LabVIEW Unit 1 - Getting Started</ a>
Learn to Use LabVIEW with MyDAQ</ a>
Message 2 of 5
(6,355 Views)

What you wrote and what you wanted are two very different things.  so lets go through this a bit:

!00.png

What you wrote and what you wanted are tiled top and bottom.

1: Sample rate determines how often a scan will start  a scan will take one measurement for each chanel in the Task   the division here would change the sampe rate depending on how many chanels are in the task. 

2: Ignore--(just say there is more than one way to skin a cat and that a finite measurement task could be set up to act very simillar)

3; This was were you "Melted Down"!  the value of that enum is 2 and its "Units" are "Samples per channel" BUT we have a contineous sample task so, this is wired to set the buffer size for the Task.  Wired the 3A way the buffer will contain "more" than one second worth of data.  wired with a "2" you are probably using the minimum buffer size the device is capable of.

4: We don't need to change the samples per chanel and leaving it unwired implies "use the current value (400") or, for each iteration wait until there is a seconds worth of data (or 10 seconds have elapsed) and return the samples in an array of 1D waveforms.

5: we really don't need to wait since the loop CANNOT spin faster than an AVERAGE of once per second.  In theory, something could "Delay" the file write and the DAQmx tasks buffer could have 800 samples per chanel in it when an iteration started.  In that case there would be enough data in the buffer and the read would return almost immediatly, iterate and zip though again and again until the buffered data was all transfered.  That is desireable!  If the Wait was put back in and the same delay occured you would never "Catch up" and all your data read would "lag" the acquired data by at least 2 seconds - if enough little delays happened over a long period the "lag" would get worse and worse and worse until the buffer overflowed (causing the vi to throw an error that you might never understand)

 

Now that you have gone back and re-read "5":

we really don't need to discuss how silly it is to read 1/40th of a seconds worth of data (10 samples per chanel) out of the buffer at a rate of once per second do we? - that buffer will fill fairly quick.


"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 5
(6,337 Views)

Hello Cameron,

 

Thank you for the reply. I kind of get it. Does it mean that the loop (wavechart and data saving part) waits but the data taking process does not?

I've tried the sequence frame/wiring error into wait, but it was still the same. Is there something wrong with my VI?

 

Regards,

Yaqiong

 

0 Kudos
Message 4 of 5
(6,272 Views)
The name is Jeff.

the loop you wrote waits. The hardware does not care about your software loop's speed and runs just the way the software told it to run before the loop started.

yes there are a few things wrong with expecting hardware to pace itself to a program it has no knowledge of.

"Should be" isn't "Is" -Jay
Message 5 of 5
(6,256 Views)