switch state every minute

[MaxXx]

Hello,

I'm trying to make a simple VI that will switch a light on for 1 minute, then turn it off for 1 minute, then repeat. It seems really simple but I cant figure it out, any help would be appreciated.

Thanks!

[BowenM]

As always, please post what you have attempted so far, and we will be happy to tell you how to improve, or where you went wrong.

[apok]

freebee

[Bob_Schor]

Simplify!  You don't need two "wait" functions.  Get rid of Elapsed Time, wire 60000 to Wait (ms), since 60,000 milliseconds = 60 seconds = 1 minute.  No need for boolean Shift register.

BS

[James.M]

---

@Bob_Schor wrote:

Simplify!  You don't need two "wait" functions.  Get rid of Elapsed Time, wire 60000 to Wait (ms), since 60,000 milliseconds = 60 seconds = 1 minute.  No need for boolean Shift register.

BS

---

That's not entirely the best way to simplify because it leaves no opportunity to stop mid-minute. He can get rid of the bottom shift register and just have it auto-reset, but the 100ms loop time is necessary to keep the application responsive.

Edit: I also don't understand why everyone always uses the Wait function for loop timing instead of Wait Until New Multiple

[Bob_Schor]

So if you want to "Quantize" the Wait state to 100 msec, then instead of Delay, call it "Wait Quanta".  Now Delay becomes "Wait 100 msec", decrement Wait Quanta, and if > 0, Next State is Wait, otherwise Next State is the saved State After Wait.

You are correct that many people don't understand when to use Wait Until Next Multiple.  However, here Wait (ms) should be fine as it is basically the only thing going on so we should do successive 100 msec Quanta without losing any "ticks".

Bob Schor

[crossrulz]

---

@Bob_Schor wrote:

So if you want to "Quantize" the Wait state to 100 msec, then instead of Delay, call it "Wait Quanta".  Now Delay becomes "Wait 100 msec", decrement Wait Quanta, and if > 0, Next State is Wait, otherwise Next State is the saved State After Wait.

---

Since when do we trust Windows to do the timing properly?  The Elapsed Time should be used here just in case Windows decides to freeze your program for a few seconds.  Then suddenly your counts are off.  But the express VI should be se to auto reset, eliminating the need for one of the shift registers.

[JÞB]

---

@James.M wrote:

---

@Bob_Schor wrote:

Simplify!  You don't need two "wait" functions.  Get rid of Elapsed Time, wire 60000 to Wait (ms), since 60,000 milliseconds = 60 seconds = 1 minute.  No need for boolean Shift register.

BS

---

That's not entirely the best way to simplify because it leaves no opportunity to stop mid-minute. He can get rid of the bottom shift register and just have it auto-reset, but the 100ms loop time is necessary to keep the application responsive.

Edit: I also don't understand why everyone always uses the Wait function for loop timing instead of Wait Until New Multiple

---

OK I'll chime in.  First becase I like apok's freebie code, second because i'll address some idiosyncratic behavior of wait functions.

Kudos to apok the code has real advantages for scaling:

1. the 100mS wait can easilly be replaced by any timeout event without indroducing odd things.  When would you do this:
1. Modifying the code to a QMH to get more states in the consumer
2. adding a notifier to exit the loop from a higher level caller
3. through +inf (many things
2. Elapsed time Express vi is a great lightweight X.vi for use as the "small child in the back seat" (See "A Trip to Grandma's House") and allows users to interupt an otherwise long process
3. Even better.  If suddenly you need a "Pause / resume / reset" feature converting that Express vi to a vi has %90 of the code to start from (Hey all you CLD candidates! there is a reason the CLD success Package contains a very simillar exercise!!!)

Why wait ms and not wait til multiple.  Simple, unless you use a bunch of largish relativly prime numbers for the "Actor Loops" your medium to large app is going to "Porpoise" the CPU load when a ms multiple common to several loops shows up.  This is real annoying when you put together some intensive loops that suddely randomly appear to "Bog down"

So kudos for getting me on a soap-box!

[Bob_Schor]

I'm always learning -- Thanks, Jeff.

BS

[James.M]

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?