Change boolean value programmatically without using local variable and property node

[mthheitor]

Hello

I have a question about changing states inside the block diagram.

My code plots and save data gathered from a infrared sensor (see image below)

The "Elapsed Time" and "XY Graph" needs to reset every time a test is completed (but the VI cannot stop, it needs to be always communicating with the sensor).

The solution that I'm using now (the Reset Button boolean control and a local variable) is working, but isn't a "optimal" solution. The Reset Button is a control hidden in front panel, cause the final user will never interact with it.

There is way that I can create a boolean that have TRUE the first time this loops executes and FALSE in the others cases?

I've tried the "First Call" function, but it doesn't worked because my VI cannot stops.

[BertMcMahan]

Replace the control with a shift register. Use whatever logic you need to use to determine when the reset needs to fire, and wire a True to the shift register when it needs to reset, and a False other times.

[altenbach]

---

@mthheitor wrote:

There is way that I can create a boolean that have TRUE the first time this loops executes and FALSE in the others cases?

I've tried the "First Call" function, but it doesn't worked because my VI cannot stops.

---

• Please attach VIs saved in a normal mode, not in "run mode" with all menus hidden. That can confuses some.
• Also, please don't maximize the front panel and diagram to the screen. Very annoying.
• There is only one loop, so I assume "this loop" is the while loop. To get a true the first time, do an "=0" on the iteration terminal, but I think you are talking about newly getting back into a particular state. Maybe you could use a small feedback node to see of the SAVE button just changed from FALSE to TRUE.
• Your Code is highly flawed. You should never hide event structures deep inside stacks of case structures.
• If you just want to reset the "reset button" to FALSE whenever it is pressed, just change the mechanical action to latch. In fact, all your buttons could be latch action, toggling states when pressed. You cuold add an LED if it is in "SAVE" mode.
• If you think you need a "reset to default" for latch action buttons ("SAVE"), there is something wrong in your execution order. That should never be necessary.
• Pressing your "stop button" while "SAVE" is false will permanently lock up your code, because the event cannot be reached, but is set to lock the front panel until the event completes. (Well, you wiggle the visibility to artificially prevent that, but still...)
• You simply need more states, one for each desired action.
• Yes, as has been said, keep the various booleans in shift registers.
• Your big flat sequence structure is not needed. Dataflow alone enforces the correct execution order.

[mthheitor]

---

@BertMcMahan  escreveu:

Replace the control with a shift register. Use whatever logic you need to use to determine when the reset needs to fire, and wire a True to the shift register when it needs to reset, and a False other times.

---

Thanks for the tip. I'm not very experienced with data flow... yet 🙂

[Bob_Schor]

The very first thing I learned when starting with LabVIEW was the Principle of Data Flow.  It is so central to how LabVIEW works, to understanding how variables inside and outside of Structures change, of the importance of "sequence wires" (I'm thinking here of the Error Line) that I can't imagine being able to write reliable and efficient LabVIEW code without understanding it!

Go find a Tutorial (or Textbook) for LabVIEW and review the first few chapters.

Bob Schor

[mthheitor · Accepted solution]

---

@altenbach  escreveu:

---

Your big flat sequence structure is not needed. Dataflow alone enforces the correct execution order.

---

Thanks @altenbach for the feedback.

1) Sorry about the annoying VI configs, I forgot to change back the VI to normal mode without hidden menus. My bad.

2) Yes I have only one loop and the "save mode" is going to execute a few times during the tests. But the VISA cannot stop. The iteration terminal will not help in this case. I implemented Bob's "Retriggerable First Call " function and it worked (http://labviewinsights.blogspot.com/2008/09/retriggerable-first-call.html)

3) The feedback node is new to me, thanks for the tip.

4) Added more cases in my state machine

5) About the event structures, thank you for showing me what are "locking up my code". I'm learning how to deal with event structures and LabVIEW Core 1 isn't very clear about these structures

6) The flat sequence is something my superior likes a lot... (I removed from my attached new code)

Please take a look at my new code, if it's ok or if there's room for more improvement.

[mthheitor]

---

@Bob_Schor  escreveu:

The very first thing I learned when starting with LabVIEW was the Principle of Data Flow.  It is so central to how LabVIEW works, to understanding how variables inside and outside of Structures change, of the importance of "sequence wires" (I'm thinking here of the Error Line) that I can't imagine being able to write reliable and efficient LabVIEW code without understanding it!

---

Hello @Bob_Schor.

The "secret" about putting Boolean Constants inside a shift register (in my vision) is not about the data flow method itself, but more likely a logic problem. I think only experience (training) will make these "tricks" more clear to me.

LabVIEW have things like Event Structure that isn't "strictly" Data Flow (dynamic events, property nodes, local variables, queues...). This is something that we almost have to use in all long programs and can confuse inexperienced users (like me).

And about Tutorials (or textbooks) for LabVIEW, do you any suggestion? I'm using LabVIEW Core 1 but not liking it.

Thanks for the help

[Bob_Schor]

When I typed "Data Flow, LabVIEW" into Google, I got several "hits", including numerous NI citations, including the implications of Data Flow.  An interesting one is Going with the (Data) Flow, and another is Block Diagram Data Flow.

[billko]

This my favorite:

Dataflow Programming Basics, and that's just because it has this one sentence in it: Remember that a node executes only when data is available at all of its input terminals and supplies data to the output terminals only when the node finishes execution.  Armed with that one sentence and some determination, you can predict the dataflow of just about any LabVIEW code you encounter.