switch state every minute

[JÞB]

---

@James.M wrote:
Wow, never thought of the bogging caused by multiple loops controlled that way. Are Timed Loops the only way around this while still maintaining consistent loop timing?

---

First its really only an issue when you collect a lot of small loops into a very large app.  SO, Timed loops are NOT going to really help.  Although you can set the Phase and priority of timed loops they each run in their own execution system and with enough of those all clammoring for OS arbitration the execution system switching overhead is really only useful for smaller apps (Just buy a better processor with more cores if you get to that level of complexity and let the OS do all the work)

In some cases you can get away with a "Master notification serving loop"  or so I've heard.  (It really is rare to have that large an app on a modern machine. 

The down side is ms timer rollover.  Wait til next ms multiple is by nature immune to that effect if you use any power of two as the multiple (If not you will get a runt period at rollover).  Frankly I have a roll-my-own Wait ms with error handling that is safe over rollover.  Way back when (Actually the first week I met LabVIEW) the stars alligned and I has a program go into an infinate loop inside Wait +(ms).vi from the old Traditional DAQ palatte (Circa LV4 or 5.1)  I've used the attached vi ever since.  Some minor changes to cosmetics made over the years and the Seconds input got that coerce to nearest ms bug fix after it was pointed out to me ten years after I fist built the darned vi (when some C++ weenie tried a 1e-5 input value).

And we are all still learning!

[natasftw]

---

@James.M wrote:
Wow, never thought of the bogging caused by multiple loops controlled that way. Are Timed Loops the only way around this while still maintaining consistent loop timing?

---

You don't want to use the Timed Loop outside of RT/FPGA.  It's entirely pointless.

The wait is more than sufficient.  Unless you're trying to get two loops to start roughly syncronized, there's no added value to the wait until next multiple.  That's the purpose of that wait.

Here's what's baffling me.  Wait is the tool you need here.  It's similar to me giving you a hammer to take care of a nail.  Why are you so eager to find another tool for this task?  What is wait not doing that has you so frustrated with it that you're going out of your way to find more difficult solutions to something so simple?

Jeff, you're making a common misperception here.  Let's look at how the run until next ms multiple runs.

Let's use a wait time of 10ms and keep that constant.

First, let's look at code that takes 5ms to execute.  If I start that anywhere between 0-5ms, our second iteration starts on 10ms and every following iteration starts at the multiple.  If the code starts after that, the second iteration will start somewhere between 11-14ms.  Why?  Just like everything else in LabVIEW, the Wait Until Next ms Multiple runs in parallel to anything without data dependencies.  Once we reach 10ms, it's complete and it stops.  At this point, we're waiting on the code to complete.  As soon as it completes, the loop's iteration is finished and goes to the next iteration.  There isn't a "runt" period.  It starts again immediately.  Then, it acts like we observed in the first case where it starts at or before 5ms.  This will be true for any code execution time of less than 10ms.  It will work its way down until it starts on that multiple and continue forward.

The next situation to consider is if the code execution is 10ms or longer.  Here, we see the Wait Until Next ms Multiple complete at the multiple and the code runs until complete.  Once complete, it immediately starts rendering the wait useless.

In none of these cases do we see a period where we linger waiting on the Wait Until Next ms Multiple.

[apok]

yes, there were no need for the bottom bool SR as "auto reset' would of handled it in this situation. It's just a habit I used going from different states and making sure that the elapsed .vi is resetting at that time, not applicable for this vi.

CLD'rs knows:

b. Timing functions

1. Use the Wait function to control the loop execution rate and allow the processor to respond to external events and system tasks

2. Use the Wait Until Next ms Multiple function to control the loop execution rate and to synchronize multiple loops

3. Avoid using any of the Wait functions to time a software operation

4. Use the Tick Count function and the Get Date/Time in Seconds function to time software operations

As per wait vs. wait multiple...here is an example vi to explain further.

[JÞB]

---

@natasftw wrote:

---

@James.M wrote:
Wow, never thought of the bogging caused by multiple loops controlled that way. Are Timed Loops the only way around this while still maintaining consistent loop timing?

---

You don't want to use the Timed Loop outside of RT/FPGA.  It's entirely pointless.

The wait is more than sufficient.  Unless you're trying to get two loops to start roughly syncronized, there's no added value to the wait until next multiple.  That's the purpose of that wait.

Here's what's baffling me.  Wait is the tool you need here.  It's similar to me giving you a hammer to take care of a nail.  Why are you so eager to find another tool for this task?  What is wait not doing that has you so frustrated with it that you're going out of your way to find more difficult solutions to something so simple?

Jeff, you're making a common misperception here.  Let's look at how the run until next ms multiple runs.

Let's use a wait time of 10ms and keep that constant.

First, let's look at code that takes 5ms to execute.  If I start that anywhere between 0-5ms, our second iteration starts on 10ms and every following iteration starts at the multiple.  If the code starts after that, the second iteration will start somewhere between 11-14ms.  Why?  Just like everything else in LabVIEW, the Wait Until Next ms Multiple runs in parallel to anything without data dependencies.  Once we reach 10ms, it's complete and it stops.  At this point, we're waiting on the code to complete.  As soon as it completes, the loop's iteration is finished and goes to the next iteration.  There isn't a "runt" period.  It starts again immediately.  Then, it acts like we observed in the first case where it starts at or before 5ms.  This will be true for any code execution time of less than 10ms.  It will work its way down until it starts on that multiple and continue forward.

The next situation to consider is if the code execution is 10ms or longer.  Here, we see the Wait Until Next ms Multiple complete at the multiple and the code runs until complete.  Once complete, it immediately starts rendering the wait useless.

In none of these cases do we see a period where we linger waiting on the Wait Until Next ms Multiple.

---

OK I probably did not make myself clear in re: when to and when NOT to use WUNmsM.

Use it if two or more process loops need some kind of "Gross" synchronization.

Avoid it for timing a single loop because of the possible "Runt" or Short periods assume near zero computation time in the iterations:

• Runt Case 1.  Loop iteration 0 starts with mSec timer at 100,789 and millisecond multiple is 100.  at  ms Timer value 100,800 iteration 0 completes and iteration 1 starts. 11mSec after i=0.  from then on iterations are at 100mSec intervals until CASE 2
• Runt Case 2 Our loop has been running for a while and the mSec timer is now 4294967200 Iteration 42948664 starts and completes not 100mSec later but 96 mSec later when the mSec Timer value is "0".  

@Runt case 1 CAN be avoided with code in iteration 0 to wait without executing core code (just a case driven by i [0 |1,Default]  Runt case 2 resolves to a 0mSec shortage with any millisecond multiple that is a power of 2 only.  NUTS kind of stuff that crops up every 49d 17hr 2min and @47.3 sec but when it CAN cause a problem it really really causes trouble and is flipping impossible to troubleshoot if you are not looking for it.  To even think of looking you have to know it happens.