LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Property Node -> Value vs Enforcing dataflow for Local Variable

Solved!
Go to solution

I've recently started using the Actor Framework for a project and for simple helper loops, I use a hidden boolean control to stop the while loop. 

 

When the Actor Core VI starts, I set the boolean value to false (so that the loop doesn't stop after its first iteration). This must happen before the loop starts. To enforce this ordering, I've used a Property Node -> Value, and wired the error terminal out of the property node and into other subVIs which feed the loop (directly into the loop would also work for this question).

 

This works fine, but reading on forums here, along with some of the online training and/or guidelines informs me that for local variable setting, I should use a Local Variable rather than a Property Node -> Value node. This is also reasonably easy to implement, but the Local Variable has no way to enforce ordering, so I then have used a Flat Sequence (which seem to be almost universally hated here. Also, they look fairly untidy imo).

 

Is this the better solution? Is there an alternative I've not considered (or more likely, which many alternatives did I not consider)? Should I instead stick with the simple Property Node, and say "It only runs once, I don't care about the performance cost"?

 

What's the 'best practice' here?


GCentral
0 Kudos
Message 1 of 5
(3,164 Views)

Well, without seeing the code, I'd say use a Shift Register wired to False from the "outside", make sure that False is the Default Value (this works well if you always "start from scratch", similar techniques.  Try to avoid Local Variables (subject to Race Conditions) and Value Properties (forces the Front Panel to run, which might be OK on Initialization ...).

 

Bob Schor

0 Kudos
Message 2 of 5
(3,154 Views)

One example for my Property Node use-case:SimpleActor_ActorCore.png

Unsure why it looks messed up - the ? is the 'Call Parent Node' for 'Actor Core.vi'.

SimpleActor_StopCore.png

And here is the 'Stop Core.vi', again with a missing 'Call Parent Node' for some reason.

 

The application is stopped from elsewhere in the Actor heirarchy, and then the caller of this VI will make this Actor call 'Stop Core.vi'. (At least, that's my understanding of the Actor Framework).

This 'Stop Core.vi' override changes the value (not signalling) of the 'StopSignal' boolean, which is on the front panel (although the FP is never shown for this Actor) of 'Actor Core.vi'. The boolean control is read each loop iteration, and stops the while loop once it changes to true. This allows the application to end.

 

The Shift Register does seem like a good idea for solving initialization problems, but I'm unsure how I'd be able to get access to the value from outside that VI at all. I'd have to change the value inside the while loop, which would presumably need some sort of message passing to a VI running inside the loop, either event driven or by normal message, and that seems far more complicated than the current implementation I have.

 

Apologies again for the dubious VI Snippet images. Not sure what the deal there is.


GCentral
0 Kudos
Message 3 of 5
(3,141 Views)
Solution
Accepted by topic author cbutcher

I've done both and for a one-time call, it's not worth fretting about.  I tend to lean toward write-locals in a single frame sequence with a dummy output wire for dataflow sequencing.  Property nodes get sequenced via error wire, which tempts me to insert them into an existing error chain.  This can be a bad idea as a prior error will prevent proper initialization.  Very easy to avoid though.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 4 of 5
(3,109 Views)

@cbutcher wrote:

This 'Stop Core.vi' override changes the value (not signalling) of the 'StopSignal' boolean, which is on the front panel (although the FP is never shown for this Actor) of 'Actor Core.vi'. The boolean control is read each loop iteration, and stops the while loop once it changes to true. This allows the application to end.


I would use the Value (Signaling) in your application simply because if an Event Structure is used later, the value change can be caught.  Otherwise, there is no difference between the Value and Value (Signaling) properties.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 5 of 5
(3,094 Views)