LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

variables without indicators and controls

Solved!
Go to solution
Solution
Accepted by venkat_rao

Hello,

 

I recognized there is a race condition occuring and I have had to change the VI completely.

 

I am now having problems with the event structure. The problem is different from the one I described in this post, so I started a new post. 

 

The link for that is: http://forums.ni.com/ni/board/message?board.id=170&thread.id=433580

 

Please check see the new post for solutions to this problem.

 

Venkat

0 Kudos
Message 11 of 35
(1,776 Views)

I know this is an old thread, but I would like to dig it back up. I am not a big fan of lots of shift registers and wires cluttering all about, and prefer to use variables in order to clean up the block diagram. For functional controls and indicators, this is a piece of cake. However, for the occasional need to store data locally to pass to another state in a state machine structure (without a shift register and associated required but unused wiring to connect the input shift register to the output shift register in every other state), it would be nice if there were a way to create a local variable that did not require a front pannel control or indicator to be created. As it is, I create the control or indicator, then move it off screen and hide it...but that seems very crude to me...

0 Kudos
Message 12 of 35
(1,549 Views)

Hello R. Gibson,

 

If what you're looking for is a "cleaner" shift register for use in a specific region or frame of your code without cluttering the loop borders, I'd suggest taking a look at Feedback Nodes:

 

LabVIEW Help: Feedback Node

http://zone.ni.com/reference/en-XX/help/371361K-01/glang/feedback_node/

 

Be aware of their initialization requirements and configuration, but if you need to store a value that's specific to a single state of your state machine, it might be just what you're looking for.

 

Regards,

Tom L.
0 Kudos
Message 13 of 35
(1,540 Views)

@R.Gibson wrote:

I know this is an old thread, but I would like to dig it back up. I am not a big fan of lots of shift registers and wires cluttering all about, and prefer to use variables in order to clean up the block diagram. For functional controls and indicators, this is a piece of cake. However, for the occasional need to store data locally to pass to another state in a state machine structure (without a shift register and associated required but unused wiring to connect the input shift register to the output shift register in every other state), it would be nice if there were a way to create a local variable that did not require a front pannel control or indicator to be created. As it is, I create the control or indicator, then move it off screen and hide it...but that seems very crude to me...


That's like saying "I prefer no to use functions because they clutter up my text code with all those pesky returns" in a text-based language.  Wires are your friend.  They make LabVIEW run efficently.  They enforce dataflow so you don't have to.  With a wire, you never have to worry if your data is stale or not.  If you have too many aires running around in your state machine, you haven't been bundling efficiently.  Never, EVER sacrifice dataflow for aesthetics.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 14 of 35
(1,531 Views)
At first, I thought this was a belated April's Fool joke.
0 Kudos
Message 15 of 35
(1,528 Views)
These aren't "local", but you can use a Global variable, a Functional Global Variable or an "Action Engine".
@R.Gibson wrote:

[...] it would be nice if there were a way to create a local variable that did not require a front pannel control or indicator [...]


An option to avoid having a bunch of shift-registers is to bundle/unbundle your state data in one cluster and pass that throughout your state machine.  That's a very common and accepted practice, as opposed to hiding controls on the Front Panel.

 

These options aren't "local", but you could use a Global variable, a Functional Global variable or an "Action Engine".

Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

0 Kudos
Message 16 of 35
(1,504 Views)

Thanks to most of you for the helpful replies. I have not tried bundling and unbundling between states, I will try that on my next project and see how I like it.

0 Kudos
Message 17 of 35
(1,482 Views)

On the block diagram right click on the terminal for the indicator or control and select hide.

0 Kudos
Message 18 of 35
(1,477 Views)

@Viper wrote:

On the block diagram right click on the terminal for the indicator or control and select hide.


That's just a different way to use a control or indicator incorrectly.  I mean, in this context.  There are definitely times when you want to hide them, but not because you are using it as a "convenient" storage space.

 

That being said, I have been sorely tempted to use hidden controls for unmanageable cluster constants until NI added the ability to change them into icons.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 19 of 35
(1,469 Views)

@R.Gibson wrote:

(without a shift register and associated required but unused wiring to connect the input shift register to the output shift register in every other state)


If you use linked input tunnels, the wiring of all other cases is automatic. Argument invalidated!


@R.Gibson wrote:

I am not a big fan of lots of shift registers and wires cluttering all about, and prefer to use variables in order to clean up the block diagram


Trust me, local variables clutter die diagram much more than a few wires ever could. Not only esthetic cluttering, but functional cluttering, making race conditions possible.
Also, if you use reasonable data structures in the shift register (e.g. clusters with intuitively named elements), you don't need that many. Often one is enough.

Also remember that a shift register contains a single copy of the data, and the data remains typically "in place" (unless the size changes) . You can read from it on the left, modify, then write the modified value on the right. Very efficient. With local variables, you create additional data copies in memory, severly cluttering the code under the hood.

 


@R.Gibson wrote:

it would be nice if there were a way to create a local variable that did not require a front pannel control or indicator to be created. As it is, I create the control or indicator, then move it off screen and hide it...but that seems very crude to me...


You never need to involve the front panel for data storage. A "variable" without anything on the front panel is a single process shared variable. Still, wires are typically a better coice.

If you stubbornly insist on using local variables, simply hide the control instead of moving the control to an offscreen location.

 

 

0 Kudos
Message 20 of 35
(1,462 Views)