Many good LabVIEW practices will look and feel different from things you've learned for text-based coding. Use the training resources at the top of the LabVIEW forum page and experiment with examples (but don't save your changes unless you "Save As" to a new location!!!). A couple other brief tips:
1. If you find yourself reading from local variables and writing the result to other local variables, then LabVIEW-wise you're "doing it wrong". Data wants to flow through operations and functions on *wires*.
2. LabVIEW inherently wants to run everything it can in parallel unless you structure your code to prevent it. That structure will mostly be wire connections representing data coming out of one operation and into another. This data dependency is used to force execution sequence. If there is no data dependence between various sections of the code, they're all free to run at the same time.
3. Fellow forum member billko sums up LabVIEW's dataflow paradigm very nicely: "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."
If you apply that rule rigorously and make no further assumptions about execution order, you'll be able to interpret a LabVIEW program to understand what executes in parallel and what's forced to execute in sequence.
I whipped up a really simple example with an event structure and boolean buttons set for latching action. See if you can understand it, then follow up with the other training and knowledge resources.
-Kevin P
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
