flow control

[exo]

Felix, see the message I just sent Altenbach. The local (now global varibles) are for other vi's. This is not what I care about. I care about running mulitple vi's in the same program repeatly. Maybe the attached code will make thing clearer. It shows one button. I will end up with three or four.
I push a button a vi runs. When I'm done with that vi, control is returned to the main program.

[F._Schubert]

Nonono!

Going from loals to globals seems no good way. (If, You'ved ever programmed basic, thats the LV way of GOTO statements).
Please post the code of an event structure (good!!!), we help you with that, for wires sake.
Add a description how it should work.


Felix

[F._Schubert]

Put the boolean control inside the event structure.

And to altenbachs code, it skipped the initialization, but you write to your lo local indicators (right of the while loop) the value that is in Nr.2 of them, which is not defined (the vi can be read right to left as well, so it is read right to left).

felix

Message Edited by F. Schubert on 09-10-2007 03:03 PM

[exo]

Thanks

That makes sense. I'll try it and get back to you.
re : the wires. I've have to make each vi into a sub vi with terminals and wire them from one event to another. I rather use local or global varibles. Which is better?

[exo]

Felix.

Seem to do just what I wanted.

[F._Schubert]

Wires are the ONE WAY to go. Locals/Globals are 'GOTO Statements' (=bad). Sometimes, you can't avoid them.
Anyhow, wathever you thick about programming styles, wires are fast (the fastest way actually).
If you can do it with wires, do it with wires. Safes you troubles, headeach, at least tommorow.

Felix

[altenbach]

---

@exo wrote:
Altenbach,
1. Your code failed in two ways. First, and I don't know why, it didn't access the file, just the internet. Second, the second time I run it,(i.e. not in the loop but when I start it up again, it doesn't reintialize object to blank and runs the vi instead of waiting for an imput.

---

There is no way to test without the subVI, but looking at your current code, it is probably also peppered with race conditions. You really need to cleanup your coding style.

You have no case structure, so it ALWAYS runs the VI, no matter what. Could it be it depends on the state of the boolean? If the VI remains in memory, it will retain the control values from the previous call. TO start with defined values, you should feed them via connector terminals when calling.

Maybe you also want to change your boolean to "latch action" so it resets to false automatically after each press.

You really need to familiarize yourself with dataflow and modify the code correctly. Let's have a look at your code:

There are four independent parts(A,B,C,D) and all will execute once per call of the VI and it it is NOT defined in what order these four parts execute (LabVIEW does not execute left to right or top to bottom, for example). Most likely, the FOR loop will take the longest, and since it constantly writes to all these local varaibles anyway, the two code segments on the right serve no purpose at all.

In theory, you could imagine a case where "D" starts executing first and places the old, stale value on the wire. In the meantime, "A" writes empty strings to same, after which part "D" finishes and write the wire content to the indicator. You'll end up with an unpredictable value on the indicator until the subVI executed the first time and renews the indicator.

You have to know that you cannot predict execution order unless there is data dependency via wires. (You might argue that the parts depend on each other via local variables, but this does not impose any execution order. A local variable can be read even if nothing ever has written to it in the past.)

That's where race conditions come from!:)

Message Edited by altenbach on 09-10-2007 01:18 PM