Before I go into the details, here is the basic rules to remember. Everything that comes into memory is given its default value. So we can take that one off the table.
Objects not connected to the connector pane probably behave as you expect. The have the value written to it via local, terminal, or value property. The primary exception is the latched button, which will reset to default when read via the terminal. Objects connected to the VI connector pane take on a few new behaviors in order to make function calls more predictable. If not passed in, an input parameter will use its default. If this weren't the case, it could take on the value of the last call. This could be made useful, but would be annoying most of the time and would require wiring most inputs in order to have consistent execution. Output objects wired to the connector will normally update the value written to them during the diagram execution. But what happens when the terminal is inside of a case and never written to. Should it return the value in the control, which would be the last value written to it? Again, this would be useful sometimes, but othertimes it would be annoying. These are typically called conditional indicators. > in a vi with only a boolean indicator, indicator NOT connected to > connector pane: > indicator comes in at default when loaded. > indicator is NOT set to default when vi is run > OK > > in a vi with only a boolean indicator, indicator IS connected to > connector pane: > indicator comes in at default when loaded. > indicator IS set to default every time vi is run > OK This is because this is presumably an unconnected or conditional indicator. > > in a vi with only a boolean indicator, indicator connected to a read > local of itself: > it comes in at default when loaded. > it does NOT set to default when vi is run > OK > This isn't a conditional indicator since it is written to. It will return the last value put into the Boolean. > in a vi with two boolean indicators, 1st is connected to connector > pane, a read local of the 1st is connected to the 2nd: > both come in at default when loaded. > manually change state of 1st (but not default value) > neither indicator is set to default during first run > the 1st is set to default on the second run > > What is going on here? To simplify things a bit, delete the second Boolean and wire the value of the first to an empty sequence or another node. You see the same behavior, but it is simpler because the second Boolean has nothing to do with it. This is an odd case in part because the value of an indicator is being set interactively. This cannot happen at runtime except to set it to its default value. What is happening is that the first time the VI is run, it seems that the Boolean was changed since its last run -- the change is interactive, but it is a change none-the-less. So the first run, the Boolean isn't reset since it appears like it was changed. For the second run, nothing happened to the Boolean, so it is rerun. If you are to run the VI once, then toggle the button twice, then rerun, it will not toggle since again, it seems that the value was changed between runs. So, is this a bug? It is consistent with the conditional indicator, but it is fooled a bit by the fact that the user is modifying indicators, something that doesn't normally happen. I hope this sheds a bit of light on your riddle. Was there any more to your question? Do you have a VI with indicators being read and operated in edit mode? This isn't likely to change, but I'm curious about an application that is heavily affected by this behavior. Greg McKaskle
