Simple LED question from a beginner.

[smercurio_fc]

---

@broken Arrow wrote:

I still would not advise the use of Locals, the same way I would not advise my son to drink beer, even though I do.

---

I thought that was just Zima.

[Broken_Arrow]

---

@smercurio_fc wrote:

---

@broken Arrow wrote:

I still would not advise the use of Locals, the same way I would not advise my son to drink beer, even though I do.

---

I thought that was just Zima.

---

God no. Zima is a better analogy for Global Variables. I don't advise anyone to use them, and neither do I, and they make me vomit.

[Viper]

---

@Ray.R wrote:

Using Local Variables is BAD ADVICE.

There is no need for it.

As Altenbach suggested, using a state machine with shift registers is the appropriate way to go.

There are plenty of examples on this forum that shows what you want to implement.

Some of these examples were written by the top contributors to this forum and show appropriate implementation of the code.

---

Ray, would you be so kind as to offer a couple of search terms so that we can find some of these examples?

[Ray.R]

---

@Ray.R wrote:

---

@omprakash wrote:

Hope this helps

---

What the heck is this?  This is not a solution for what the person is asking?  Why have a loop if it either stops at the first iteration if LED is FALSE?  And once you set the value for LED2 it will not reset unless you stop and run the VI again.  Nevermind the fact that the second loop will also stop as soon as it is FALSE, which is what the value will be when the first loop ends.  Did you try running your example?  It's really useless..  Try running it.  Learn from it and try to understand the dataflow by first running it and repeating the execution with highlight execution turned ON.

---

I'm going to be listed in the Rude Threads, aren't I?  LOL!! 😄

By the way, there is nothing wrong from learning from our mistakes.  We all make them.  The lesson learned is the important part..

So back to this example.  As pointed out by a fellow contributor to the forum, one important aspect is to open the Windows Task Manager and to look at the CPU Useage before, during and after running the VI example.  You'll notice that the CPU useage goes up to 100% on a single core (50% on dual).  That's because the loop (or loops) do not have a Wait (ms) within the loop, thus preventing the CPU to handle other tasks and hogging all the CPU time.  Simply adding the Wait will allow the CPU to tend to other tasks and return to this one.  Add the Wait, select different values (including 0ms) and observe the behavior.

[Ray.R]

Yes, or I can also whip up an example..

🙂

[Ray.R]

Have a look at the attached example.

I have put comments in it.  It is not the best implementation, but it does show the way to implement it as a State Machine.

The comments should provide information to expand from it.

[omprakash]

Hi Ray,

         Rude for sure but still thanks for explaining the reason.

[altenbach]

---

@Ray.R wrote:

  Nevermind the fact that the second loop will also stop as soon as it is FALSE, which is what the value will be when the first loop ends. 

---

Another classic race condition. The second loop will stop once the control is updated via the local variable.

It is very likely that the control gets read by the code before it gets updated via the local variable, meaning the second loop spins twice instead of once.

While it makes no difference here, it could make for unpredictable code. For example if you would place an indicator on the iteration terminal of the second loop or use it's value later, the result is not predictable.

[Ray.R]

---

@altenbach wrote:

 For example if you would place an indicator on the iteration terminal of the second loop or use it's value later, the result is not predictable.

---

Actually, that resembles an exercise that NI had in it's beginner LabVIEW course..

It's a very good exercise which should be run numerous times and observe the behavior.