Looping Time Less Than 1 ms

[altenbach]

---

@Sharonoff wrote:
Just repeat the code you need to
execute in a loop as many times as you want
...

---

Well, repeating the code100x would really cause a diagram headache!!! Just put the wait inside a case structure that is only enabled every N iterations. 😉

I mostly agree with Shane, but there are special scenarios where you just care about the average loop speed (no precise timing). For example, a loop with a 0ms wait will run much slower than a loop without a wait, so if you want to get something in-between you need to get creative. (Assuming that there is little complexity in the loop and it can actually achieve very high loop rates.)

A loop without wait will grab the CPU for 55ms! This could be millions of iterations.

What if you want a very fast loop that releases the control of the CPU ever 100 interation instead of every iteration (using 0 ms wait)?

--> Place the 0ms wait inside a case structure that only is active every 100 iteration (Use quotient&Remainder and divide the loop counter by 100. Wire the rmainder to the case and put the wait into the "0" case. The default case remains empty.).

Of course you could also use a 1ms wait or higher, depending on your specific needs.

[Joshua.Hibberd]

Here is a very inelegant solution if you have access to a DAQ card:

Create a time source with the DAQmx Create Timing Source (Frequency).vi

Set the Frequency to 10 kHz

Use this time source as the source for a timed loop, make sure you set the period to 1 tick (as the default is 1000 ticks)

Leave the  loop empty except for an error line going into and out of the loop, and use the error line to control the sequence of execution

Program the Timed loop to act like a For loop (connect the stop terminal of the loop to the (index +1) equals? (loop count constant/control)

Your delay will be .1 ms for each iteration of the Timed loop. 

Setting the Frequency too high will eat up more processor and may interfere with the function of your VI, if timing is important... but if timing were really crucial, you shouldn't be using this method anyway.

I was able to run this without completely eating up my entire CPU (about 30% of a 2.14 GHz Dual Core), so it did not interfere with the function or timing of the VI.

Generally when I program my .VIs, they do not even use 1% of the CPU, so it's almost viable to use this as a method... However I would really recommend you avoid it unless absolutely necessary, as it is not very precise, and eats

up a lot of processor doing absolutely nothing but waiting... but if you have the available resources and you can't see any other way, there it is.