Shift Register Indicator?

[ajsdwilson]

This is likely an easy one...but I can't seem to reason it out. (Relatively new to Labview)  I have a State Machine set-up...I would like my Front Panel to show what Case is currently active.  I suspect I need to pull data off the Shift Register, but not sure how to approach it.   Any ideas?

[tyk007]

Simplest approach - attach an indicator to your shift register outside the case structure. That way it is executed for every state of your state machine.

[natasftw · Accepted solution]

As that last post was a tad confusing, I'll clarify.

The shift register doesn't have indicators.  It's just a memory location that's reserved for your data.  Between the case structure and while loop, you have a wire that's feeding the next state into the shift register.  Place an indicator here.  If you'd like to create one easily, right-click on the wire and choose "create->indicator."  This will create an indicator that is updated after each state is run.  You can get similar behavior by placing the indicator prior to the case structure.  Your code should be responsive enough to the user that either of these will appear to behave the same.

[ajsdwilson · Accepted solution]

Great...thanks!

[CoastalMaineBird · Accepted solution]

One thing that helps to remember is that a WIRE is a VARIABLE.  practice that thought...

Everything else just works with variables.  A Shift Register is a place to temporarily store a variable value.

A wire comes FROM a FP Control = the control SETS that variable.

A wire goes TO a FP indicator DISPLAYS that variable.

Two wires go INTO an add function = the code ADDs those two variables.

With that in mind, your reasoning should be clear:

What do you want to do?

   See the state that is currently active.

Where is the current state kept?

    In a shift register on a WHILE loop.

Where do you determine the current state?

    At the selector terminal of a CASE structure.

Where does that info come from?

    A wire from the Shift Reg

How can I look at a variable?

   Attach an indicator to the wire (or attach a PROBE to it).

[ajsdwilson]

AWESOME...Thanks!  Hadn't thought of it that way!

[CoastalMaineBird]

Seriously, repeat that thought (a WIRE is a VARIABLE) several times to your self.

That explains several things:

If you wire a CONTROL to a CONTROL, you get a BROKEN wire.  (which control sets the variable?  you don't know).

If you wire an INDICATOR to an INDICATOR, you get a BROKEN wire. (Nobody sets the variable).

If you wire a source INSIDE a case structure to a destination OUTSIDE the case, then you have to have a source for ALL cases (otherwise there's a case that doesn't set the variable, and we can't have that).

If you wire a source INSIDE a sequence to a destination OUTSIDE the sequence, then you must NOT wire more than one frame to that tunnel (otherwise you have two sources trying to set the same variable, and we cannot have that).

  a WIRE is a VARIABLE.

 a WIRE is a VARIABLE.

 a WIRE is a VARIABLE.

[tst]

Wires are NOT variables, and I would suggest you not think of them that way. It can certainly be helpful for someone who has a background in programming to have it explained that wires fill the same role that variables do, but the two are not equivalent and thinking of wires as variables can be detrimental, because that doesn't mesh well with the dataflow model which LV uses.

Rather than thinking of wires as variables, once you understand that they fill the same role, it's much more useful to think about data and values - the Add function needs two values to operate and it will execute after it has received both values. If you think in terms of variables, you think of explicit assignments, you think of canonical data stores (which might be an issue for people who won't understand that a split in the wire now means that there are two copies of the data), etc. In dataflow, the data is just data - you have to think about where it's coming from and what it represents, not about how it actually gets around from place to place.

[Yamaeda]

@tst there was a thread about it a long time ago (1-2 years) and I side with the "the wire is the variable". From wikipedia "In computer programming, a variable or scalar is a storage location paired with an associated symbolic name (an identifier), which contains some known or unknown quantity of information referred to as a value. "

With that as definition, the wire is a variable. It's a storage location with an identifier (the wire itself) and refers to a quantity of value.

The dataflow paradigm mostly change how it's best handled, not the function.

/Y

[ajsdwilson]

I have been thinking this one through...have to agree with TST. (Although, I am stil a Padawan in the ways of the Labview)  A hose is a conduit...we are never sure what will go through it, how fast it will go through, or how much pressure will be applied...it is all dependent upon the pump on one end and the tool on the other (Cylinder, etc).  A wire would be the same way...it is a conduit that moves something...true, it is variable, but it seems to me like it ultimately is not responsible for it's own variability?