08-18-2009 01:17 PM
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
04-02-2014 07:10 PM
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...
04-02-2014 07:42 PM
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,
04-02-2014 08:42 PM
@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.
04-02-2014 08:45 PM
04-03-2014 06:33 AM
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".
04-03-2014 12:31 PM
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.
04-03-2014 12:37 PM
On the block diagram right click on the terminal for the indicator or control and select hide.
04-03-2014 12:50 PM
@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.
04-03-2014 01:03 PM
@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.