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
