Understanding loops and buttons

[MaSta]

What do you mean by "the loop will not finish, but iterate to 1"? If I put a probe right before the exit point and after having selected "Exit" from the menu, the probe will be updated and that means the loop has come to the point where it reads the local variable, no matter what iteration is has come to. And then it should exit or LV is doing something wrong. This is the C code equivalent do.. while exit? = FALSE.

Like I said, even if the loops don't exit at the same time, but since the variable keeps being TRUE, they should exit anytime soon. In the event structure I set the variable to TRUE, then it leaves the event structure and the loop continues. It should at least go once to the exit point code. 

"Stop/Exit VI not recommended" - OK, but why do you say so? It's the same as when clicking the close button on a window. The software would either do something, if required, or not, but the OS will do what's needed to close an app, like freeing memory. I expect that's the code behind the Stop/Exit VIs. I see no point in exiting the event structure before.

[altenbach]

You have a glaring race condition, because when the event sets the "true", the local has already been read as false.

(There are two independent code fragments in the upper loop and both execute in parallel at new every iteration:(1) local is read and passed to the termination condition. (2) event structure waits for your menu action. It is important to understand dataflow here!)

Your local in the upper loop would get read as true on the next iteration, but that is waiting for another event and the loop cannot complete until the event structure has completed again.

Just wire from inside the event to the termination condition, no local needed there! All tunnels should be set to use default if unwired.

[MaSta]

Thanks to all for your involvement in this discussion. Very appreciated.

Coming from several years of C coding I see what LV does wrong here. In C, the exit condition is always read at the end of a while loop, so whatever code inside the loop is running (here: event structure), when it exits it would come to the loop end, find a TRUE and exit the loop.

This is my logic, this is how it should work. I don't see the difference between my code and your code. Why would LV handle a wire differently than a permanent variable? It's not a button with a latched press, going back to FALSE once read.

[tst]

---

@MaSta wrote:

Why would LV handle a wire differently than a permanent variable?

---

Because of dataflow, which is the basic paradigm LV uses for executing code. A block of code (in this case, reading a value from a local variable) will execute at some undefined point in time after its containing diagram starts executing and after it got all of its inputs (which in the case of a local variable is none). The wire is coming out of the event structure, so by definition it will only have a value after the structure is finished executing.

The fact that the local variable is connected to a loop stop condition is not relevant, as code following a node does not dictate when it executes, only code coming before it. LV might decide in some cases to do some optimizations to execution order based on downstream code, but that's not something you should rely on.

In short, your C experience is not applicable to this case, as LV follows dataflow, where things can run in parallel, so you need different considerations for how to execute things in the order you want.

If you really wanted to read the value from a local variable after the loop was finished, you would need to create some kind of dependency to control this (for instance, placing them in a sequence structure). I expect that any of these changes would make the code less elegant than simply using a wire (which is generally the most direct equivalent to a local variable in C, so if you're willing to accept the equivalence, that's where your C experience is relevant).

Also note that even if the stop condition terminal gets a T value it doesn't actually stop the loop (so it's not like break in C). Instead it tells the loop not to make another iteration once it finishes executing all of its code.

[MaSta]

Yes, I see now. At most points it works fine, but at some you gotta think "wired".

[tst]

---

@MaSta wrote:

Yes, I see now. At most points it works fine, but at some you gotta think "wired".

---

To be clear, you always have to think "dataflow" in LV. It's just that in many cases the order of execution doesn't matter. The important thing is to recognize the places where it does matter and handle them accordingly. Ideally, code should probably be written in a way where the order will never matter (everything by value, no side effects in functions, etc.), but I'm not sure if that's possible in practice.

[altenbach]

---

@MaSta wrote:

Coming from several years of C coding I see what LV does wrong here. In C, the exit condition is always read at the end of a while loop, so whatever code inside the loop is running (here: event structure), when it exits it would come to the loop end, find a TRUE and exit the loop.

---

I would say that LabVIEW does it right! 😄 It is not the timing of reading the termination condition (which LabVIEW might do at the very end, but who cares!), The reading of the local variable is the point and since you don't have a data dependency, LabVIEW as a fully parallel programming language, will execute as many independent parts in parallel as possible.

Leveraging data dependency is key to any well designed, performant, and predictable LabVIEW code and avoiding unnecessary local variables is a key skill that comes with experience. LabVIEW does not have variables, so text programmers often see local variables as substitute. They are NOT! In LabVIEW, the wire is the variable! (see my code modification above). Local variables just give secondary access to front panel elements. Processing data belong in the diagram, not on the front panel. The front panel is for the user and has it's own UI thread to isolate from the data processing..(Well, updating locals is via the transfer buffer so just adds additional memory copies and extra overhead).

The era of single core processors is long gone and strict sequential execution has become a dirty word from the stone ages of computing. So you spend thousands of dollars on a 8 core CPU and all you ever want to use is 16% of it? Historically, it is amazing that LabVIEW was fully multithreaded way before multicore CPUs became typical. Talk about visionaries!

A well written LabVIEW program can fully scale with a near infinite number of CPU core. Have a look here.

The LabVIEW compiler is an absolutely fantastic feat of computer engineering. You might want to read up on it here. It is amazing how it can untangle horrible spaghetti code, apply optimizations, and generate excellent machine code. 😄

[MaSta]

OK, but wouldn't you say it's weird to call a loop "While" loop when it doesn't work as you know While loops from other programming environments? I'd say everyone would expect it to exactly work as a While loop works. Digging deeper into structures, timing and partially badly translated documentation, LV for me is a horror and a relieve at the same time. 

However, I already learned a lot from reading what you profs had to say about my questions and approaches. Very appreciated.

[LLindenbauer]

---

@MaSta wrote:

OK, but wouldn't you say it's weird to call a loop "While" loop when it doesn't work as you know While loops from other programming environments?

---

In C, you can exit your loops at any time using return, goto, continue and break (which all have their uses) and you can decide if you want to check before (while) or after the first iteration (do ... while). Maybe you are used to a certain coding style guide in C?

LabVIEW supplies a do ... while loop. The difference to C is that you have no guarantee on the order of operations. That, however, is kind of the point of having a language that uses data dependency instead of sequential execution.

If you absolutely must have your condition checked before the loop body, you can easily do that:

It is easier to work with the tools then against them, even if we find that they don't click with our style. I remember the old joke "Real Programmers can write FORTRAN in every language".

[tst]

---

@MaSta wrote:

OK, but wouldn't you say it's weird to call a loop "While" loop when it doesn't work as you know While loops from other programming environments?

---

Different languages have different behaviors and idioms. The way it works makes sense for LV and has some advantages (such as making it easy to see just the code in a specific code path or forcing you to think about and see what can stop the loop or what the returned values will be).

As suggested, it's usually better to work with the tools rather than against them. LV definitely is different in some ways and even if they're not always the best options, they are what exists.