dav2010,
Your example shows how LabVIEW's dataflow paradigm works. Any node - which can be a primitive element like Add or something more complex like the while loop - may begin to execute when data is present at all its inputs and its outputs will not be valid until it has completed execution. Nodes which have no data dependency may execute in parallel.
Now, lets apply this principle to your code. At the highest level the code has four nodes: VISA Resource Name control terminal, VISA Open, the While loop, and VISA Close. Because they have wires going from one to another, the data dependency forces them to execute in that order. Within the while loop are three independent code blocks in parallel. The Wait (ms) and the constant = 50. The case structure and the VISA Write following plus the constant 1000 and the True constant. The Stop switch terminal and the loop termination terminal.
When the while loop begins executing, any of these three blocks may execute first. If your computer has the necessary resources they may all execute in parallel. Most likely the Stop switch value will be read very early in the iteration but if it is True, the loop will not stop until everything else inside the loop has completed execution. The Wait will also probably start almost immediately. Since there is a 1000 ms Wait inside the case structure, the 50 ms Wait will complete long before the case structure. When the case structure starts executing, the True constant will be evaluated and the True case selected. VISA Write will send "String". The 1000 ms Wait and the 50+25 Add followed by string conversion will execute in parallel. When both are complete, the case structure execution ends and the second VISA Write will send "75". If the Stop button was False at the beginning of the loop iteration when the terminal was read, the loop will begin another iteration. After the loop stops, the VISA Close will execute.
So the short answer to your first question is: Yes.
As to the question about the choice of architecture, this has some severe limitations. As pointed out in my wordy description above, you will almost always get one extra iteration (and the one second wait) between the time that the Stop button is pressed and the time the VI stops. In the worst case it could be just microseconds less than two seconds from the time Stop is pressed until the VI Stops and "string" and "75" would be written twice more. If you ever need to change anything about what is sent or the timing, you need to change the program.
A better choice of architecture might be to use a Producer/Consumer (Events) Design Pattern and implement the consumer loop as a simple state machine. This will give you a more robust structure, one that is easily adaptable to future requirements changes and one that is very responsive to user inputs.
Lynn
