wait until next ms multiple adding miliseconds

[Ben]

---

Ravens Fan wrote:

...

The Wait Until function is going to give you the ability to have the While loop be basically synchronized so that they run on particular multiples.  But I don't know when that is a particular advantage. ...

---

I can give an example of of why the "Wait unitl next.." can really bite you.

The "standard" reason for putting a wait in a llop is to allow the various threads to share the CPU. So if you use a Wait unitl next... in ten loops all set for 100 ms, they will al wake up at the same time, fight for the CPU and then go back to sleep unitl it is time to fight again. To avoid minimize that I would have to set the delay for each loop to a factor of different prime numbers to keep them from waking up at the same time (well it works for the cicada).

Re: What is emphesised in the Basics course.

They (at least my guys) explain the difference but do not emheisize one or the other. At one point there was slide for this but it sounds like that one has been dropped. They (NI) do use the "wait unitl..." as an example of "poor-man's syncronization".

Ben

Message Edited by Ben on 10-02-2009 02:09 PM

[RavensFan]

Perhaps emphasized was the wrong term to use.  If I remember correctly, they did spend a minute telling what was the difference between the two.  The examples used then used the "Wait Until".  The instructor said use the "Wait Until".  That led me to believe that "Wait Until" was the better choice in most situations.  It wasn't until sometime later that I realized "Wait Until" would really never be the better choice.  I'm still not sure if there is a place where Wait Until should be used.  As I said, it basically synchronizes things, but as you said, it is a pretty poor way to synchronize.  I agree.  If I'm ever worried about syncrhonization, I'll used rendezvous's or notifiers.  Or use the timed loop structure and set the internal settings of the loop appropriately.

If you can think of a good case where Wait Until should be used, I'd like to hear it.

Here is a situation where Wait Until would be wrong and "byte" you.  In serial communication where you need to wait let's say 500 msec between a Write and Read.  Wait 500 msec will wait 500 msec between them.  A Wait Until could leave you with a wait of 1-500 msec depending on exactly when the function is called relative to the system clock.  The actual wait would appear to be random, and whether the wait is long enough for the communication sequence to work would be completely random.

[Darin.K]

There was once a time when the "Poor man's synchronization" was all that we had.  Of course a good day's work back then was getting the Remote Enabled light on a instrument to turn on.  Perhaps out of habit, I still use Wait Until to share the load among multiple While Loops.  Using Wait(ms) could create a bottleneck when one loop takes extra time, at which point the system might have a hard time recovering.  To me, it is like the slowing of traffic that still occurs hours after an accident because there is no break to dissipate the density wave.  The Wait until function is like a metering light that can tweak the flow to smooth the effect.  Of course setting them all to the same multiple is defeating the purpose and is akin to turning all four stoplights at an intersection green at the same time.  Sure you might get away with it for a short time, but eventually, bang.  So, I recommend it to anti-synchronize multiple loops.  These days there are much better choices to synchronize them.

[Ray.R]

---

Mark Yedinak wrote:

Would a timed loopeven give the level of accuracy he is looking for on a Windows platfrom? I don't think that NI would guarantee that.

---

LOL!  Maybe not..  😄   The level of accuracy would have to be defined.  🙂

Everyone has an interpretation of accuracy.  I like those on paper that state why they need a certain level.  If accuracy is a requirement, then a timer card may be needed.  Let's not go there (yet).

Ben & Ravens Fan described very well why I mention to avoid the "wait until next ms multiple". 

Ben,

Do you recall that long thread concerning approaches to better timing accuracy within Windows?  Maybe you've tagged it already?  I'll check your tags.

R

[Ben]

---

Ray.R wrote:

...

Ben,

Do you recall that long thread concerning approaches to better timing accuracy within Windows?  Maybe you've tagged it already?  I'll check your tags.

R

---

This is the only one I found after a quick search. Allow me the liberty to quote myeslf ( poet #34 in that thread, in the hope I'll find it easier next time).

---

Hi All,

After some experiments and punching a lot of buttons, it appears that multiple timed loops can run under Windows with HARDWARE timing.

This does not seem to be possible without adjusting the environment to help this happen.

The following is a list of things that can help you "adjust" Windoze do its job.

1) Set Windows to optimize background services.

Windows by default will attempt to optimize its scheduling to make foreground processes perform well. For single threaded applications this is fine but for LabVIEW, some of its background threads can suffer.

A) Start >>> Control Panel

B) Open "System" and choose the "Advanced" tab

C) In the "Performance" section click "Settings"

D) On the "Advanced" tab in the "Processor Scheduling" section select "Background Services"

E) Save or apply everything.

2) Stop Indexing services.

Windows will by default do file indexing. File indexing is functionality that tells windows to maintain in memory a cache of files on a disk or in a folder. This makes files show up in the Explorer faster and also makes searching for files faster.

A) Start >>> Accessories >>> Windows Explorer

B) Right-click C: drive and select "Properties"

C) On the "General" tab un-check "Allow Indexing Service to Index This Drive for Fast File Searching"

D) Save and apply everything

3) Set LabVIEW priority in Task manager. Windows will by default treat all processes that are ready to run as peers and will share the CPU evenly.

A) Open the Task Manager and select the "Processes" tab.

B) Locate "LabVIEW.exe" in the list of processes.

C) Right -click "LabVIEW.exe" and choose Set Priority >>> High

Note: Setting LV to run at higher than "High" will put it on equal footing with interrupt service routines etc. This could result in the machine "locking up" because LV is using all of the CPU and there is no opportunity to respond to interrupts from your mouse moving.

4) Shutdown Virus Checking. Virus checking gets its hooks into everything!

5) Disconnect Ethernet cable. Ethernet traffic requires intervention by the OS. No cable, no traffic, no distractions.

6) Set the VI properties of the sub-VI that will run the Timed Loop to "Priority = Time Critical" and "Execution Thread = Data Acquisition".

7) Configure hardware Timing source to run at 2000 Hz.

😎 Set "period" of timed loop = 2 (i.e. 2000 Hz clock / period of 2 = 1000 Hz)

Now wasn't that easy?

I have tested the above using the instructor machine with LV8 running three timed loops at 1000Hz for 20 minutes with no missed iterations and no "Finished Late" indications where the loop failed to start on time.

Ben

---

Ben

[Peñata]

Hi clink283,

To return to your original question and to reiterate what others like Mark Yedinak have said, you will not be able to maintain determinism on a Windows-based operating system because of the other operations going on in the background. If you want to be able to achieve that determinism, look into some of our real-time systems. Also, as other have pointed out, your issue most likely lies in the File I/O aspect of your application. You would probably have better results if you used some sort of Producer/Consumer architecture as Ben mentioned. Even in a real-time environment, I would recommended doing this so that you could have your data acquisition (or whatever you are doing that is time-critical) in a higher priority timed loop and then perform your non-time-critical operations, like File I/O, in a less prioritized loop.

Ravens Fan: In reference to your Wait (ms) vs. Wait Until Next ms Multiple question, I do not know why your instructor emphasized using Wait Until Next ms Multiple. That may have just been a personal preference of the instructor because, as far as I know, National Instruments does not officially emphasize one over the other. Personally, I always use Wait (ms) because of the all the "gotchyas" that you and Ben have discussed, unless I specifically need the functionality of Wait Until Next ms Multiple.

Thank you for choosing National Instruments.

Aaron Pena

National Instruments

Applications Engineer

http://www.ni.com/support

[clink283]

Just a quick update -  I've reduced the need for such a high level of accuracy.  

Thanks for all the replies and pointing me towards the producer/consumer architecture.

Cheers!