Question about the Wait Function

[masterwho]

I wrote a VI to store the time stamps in a text file.

I fond something strange in the text file (see the picture below).

The time stamps weren't writen into the file every 10 ms! How could this happen? And how could I fix it and make the time stamp to be writen every 10ms?

Thanks a lot!

[FHM]

see attacht screenshot. I hope it helps.

[F._Schubert]

As an alternative, you can use a timed loop.

Felix

[johnsold]

Can your OS write to files in 10 ms?

If you want data timestamped at 10 ms intervals, you need to move the file writes outside the loop.  At that speed you should also move any controls or indicators out of the loop so that  OS calls to update the screen do not slow things down.

Lynn

[Coq_Rouge]

Here is a simple test you can do. You will find the resolution for the "Get Date/Time In Seconds Function" to be in range 15 to 20 msec. As this depend on OS and Labview version. Why do you need timestamp every 10 msec? Also remember that Labview is not a realtime system. Tell us more about your project and post code. 

[Andy.G]

Also you might find that the wait until next multiple timing function would suit your program, rather than the wait ms function.

[Rhys - AE]

To further what was just said:

The wait function will indeed wait 10ms, or near enough as I will soon explain.

When used in a loop, the wait function will wait for 10ms AFTER the code inside the loop has been executed.

Depending on your Operating System, and the speed of your PC, the code inside the loop could take several hundred milli-seconds to execute.

So the total time for each loop iteration, and thus the time between file writes, will be (Xms + 10ms), where X is the time taken to execute the other code.

Another thing to consider is that unless you are using a Real-Time OS, your Windows or Mac OS will not prioritise LabVIEW! The execution of your code must run alongside your virus scanner, email client, music player etc. etc. etc.

As such, it is often asking too much to try to use labVIEW in accuracies of +/-1ms on the common desktop PC.

As a final note: I cannot give facts on file writing, but just from my experience with LabVIEW a file write every 10ms is impractical as the write-to-file VI usually takes longer than 10ms to execute itself. Why not buffer up 10 writes/pieces of data/whatevers and then write them all to file at once? Whilst we are at it, why not buffer 100 pieces and then write them all at once?

I have had this idea argued before, with people saying that if the system were to crash then the buffered up 100 reads would be lost. Remember guys: that labVIEWs write to file VI passes the data to the windows write buffer, and windows doesn't necessarily put it on disk straight away! That can only be guaranteed by closing the file reference or flushing the queue.

Apologies, I have diverged.

[tbob]

---

@Rhys - AE wrote:

When used in a loop, the wait function will wait for 10ms AFTER the code inside the loop has been executed.

---

I don't think the above statement is entirely true.  The wait function is usually placed in parallel to whatever code is in the loop.  Therefore, the wait will run at the same time that the other code runs.  If the other code takes less than 10mS, the entire loop will take 10mS because of the wait.  If the other code takes 40mS, the entire loop will take 40mS, because the 10mS wait will take place in parallel to the 40mS code.  Try the attached example.  The code inside the loop takes 42mS on my PC.  The entire loop takes 42mS, not 42 + 10.

Here is a picture for those who don't have LV2009:

[altenbach]

---

@tbob wrote:

---

@Rhys - AE wrote:

When used in a loop, the wait function will wait for 10ms AFTER the code inside the loop has been executed.

---

I don't think the above statement is entirely true.  

---

Yes, without data dependency, the wait will execute in parallel to the rest of the code, but is probably not guaranteed to be scheduled to start first. There could be some jitter.

The problem with wait(ms) is that the errors accumulate over time.

If you would place a 50ms wait and a 100ms wait in parallel, the loop time will be 100ms, and not 150ms.

As long as the loop code can execute in well below 10ms, the "wait next ms multiple" will be able to keep sync, but the first iterations will be delayed by a somewhat random amount in the range from 0 to the wired delay value.

As others have said, the timed loop is more accurate and you can even detect timing errors and take appropriate action. 

[tbob]

---

@altenbach wrote:

.....There could be some jitter......

---

Yes this is true.  When I set the For Loop number of iterations to something lesser, the entier code would run 11mS sometimes, 10mS at other times.  So there is some jitter.  I would not use this for an exact time measurement either.  Try setting the wait to 0 or 1 mS.  The overhead is longer than 1mS.