LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How accurate is the wait function when using really long waits?

Howdy all,

There was a similar earlier post asking about wait accuracy over small periods:

http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=506500000008000000D4A20000&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0&USEARCHCONTEXT_QUESTION_0=Accuracy+of+Wait+Function&USEARCHCONTEXT_QUESTION_S=0

but I'm interested in the behaviour of the wait function over long periods. If I tell the wait function to wait 19 minutes (so 19*60*1000 = 11400000 ms) assuming average system use (ie, system resources are consistently available, not many programs running in the background), what sort of accuracy can I expect? Or will it end up being entirely system dependent? If NOTHING is going on in the b
ackground, can I expect the function to terminate after approximately 19 minutes? (if it's within 30 seconds, I'd be happy) Any better ideas for handling long waits?

Any comments, ideas, etc. are appreciated
0 Kudos
Message 1 of 19
(3,286 Views)
I don't know about accuracy, but I noticed something funny last week while running a program.

I have a program which communicates over RS-232 and I need to make pauses now and then. After sending a few commands, I set the VI to wait for 20 minutes (1200000 ms). If I call the 20 minutes, half the time the VI freezes, it never re-starts. If I make a smaller wait first, it works fine. Even subsequent calls for 1200000 ms work fine.

I don't have an explanation for this, but it seems something wierd is going on.

I'm using W2k, LV 6.1.

Hope this helps

shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
0 Kudos
Message 2 of 19
(3,286 Views)
You can always use a smaller wait (either wait or Wait Until Next ms Multiple) in a loop so your VI does not lock up (no response from clicks), and count how long the vi is in idle. It should be acurate enough (within 30 seoncds out of 19 minutes).

If you use event in your VI, then simply wire 19 minutes to the "Time Out" input of the event structure. The VI only executes when either some monitored events happened or timed out. In your case, when it times out, just exit the loop.

-Joe
0 Kudos
Message 3 of 19
(3,286 Views)
Hi,

For this type of resolution (30 seconds), I see absolutely no problem with getting the desired results. Although the operating system may decide not to give LabVIEW the CPU immediately, it almost certainly would be within 30 seconds if there are plenty of system resources and not many programs running.

Allen P.
Applications Engineer
National Instruments
0 Kudos
Message 4 of 19
(3,286 Views)

I know this is a REALLY old thread, but I am having a problem in LV 2014 that seems to apply...

 

I am performing a 30 minute wait, using the wait (ms) function, where I am looping on a 1000ms wait 1800 times as I am cycling through a test. The reason I am doing it like this is so the operator can break out of the loop and stop the test program at any time, without having to wait until the 30 minute wait is complete. See below for screenshot of the usage.

 

About 30% of the time, at random, it seems that the dwell time that is supposed to be 30 minutes is more like 15-20 minutes. The rest of the time it's right on the money, or at least close enough to 30 minutes that it doesn't matter.  I can't see any code bugs that could cause this...it's pretty simple code. Does anyone see any reason why the way I'm doing it might cause this problem?

 

Capture.PNG

0 Kudos
Message 5 of 19
(2,764 Views)

Is there anything telling the Global STOP variable to be True?

0 Kudos
Message 6 of 19
(2,754 Views)

Why don't you just put the stop button's terminal in the loop itself?

 

"Seems like" and "is" are entirely different.  Is it something you've checked or is it something that just feels shorter?

0 Kudos
Message 7 of 19
(2,753 Views)

If the global stop variable were true, the program would end, due to that variable being wired directly to a Select function that controls the Next State of a state machine.

 

The time IS shorter, randomly, about 25-35% fo the time. I have not seen it go longer...FWIW...

 

The Stop terminal is not in the loop because this loop is a very small portion of the whole program. The Stop control terminal is actually in an event structure, so that it is immediately read when pressed, and then the stop global is set, which allows the operator to stop program execution from anywhere within the program.

 

0 Kudos
Message 8 of 19
(2,728 Views)

Is there anything else going on with that event structure?  With what you've shown, you can easily move it inside the for loop and use the wire you already have going out to stop the program.

 

It's difficult to say what else is going on with your program with such a small piece of it.  Is there a reason you're unable to share your code?

 

With what we've seen, it's a rather awkward architecture.  Seeing the whole picture might help to clear that up

0 Kudos
Message 9 of 19
(2,715 Views)

You really can't trust the waits being exact in a Windows environment.  What you should really be doing is use a While loop that iterates every 100ms or so and use the system time to see how much time has passed.  When the difference reaches your 30 minutes, stop the loop.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 10 of 19
(2,693 Views)