Feedback nodes and local variables

[AkkiTriple5]

Hi everyone,

I am new to labview and currently learning its basics while building an application. However, I have used a few local variables (even for images!), which has made the program slow but still very workable for normal standards. I was wondering whether it is better to use local variables or feedback nodes when both can be done for my program.

For example, for using a stacked sequence, I need to pass image from one frame to the next frame (Its inside a while loop). This can be done using local variables, or using feedback node since I know the data flow. I have read the local variables use up more memory, and have not found anything against feedback nodes. Which one should I use for better performance?

Also, does the same apply, for example, event structures (for just using the outputs as inputs for every case so that all operations are stored), or even case structures??

Suggestions would be appreciated.

(If it makes any difference, I am using labview 8.5 evaluation)

[cbutcher]

I'm not familiar with LabVIEW 8.5 (and since you're using an evaluation copy, I would query why you are becoming familiar with 8.5...) but I firstly want to point out that having a Stacked Sequence Structure inside a While loop doesn't have anything to do with its frames. The frames will all execute every iteration, and then next iteration, they will all run again.

Generally Stacked (and Flat) Sequence Structures are discouraged because they have some intrinsic limitations - for example, if something bad happens in frame 5 of 8, you can't skip frames 6,7 and 8 - there is no way (apart from pressing Abort) of leaving a sequence structure during its execution.

A common alternative is the State Machine. This is a Case structure in a While loop, where the behaviour is determined by a (preferably type-def'd) Enum.

Using Shift Registers on the edges of a While (or For) loop is the most common way to preserve data from one iteration into the next. This is just like having a wire looped around to the start of the next iteration. Although I don't know how the internal workings of the compiler run, my understanding is that Shift Registers have almost no overhead - it's just the same data object being passed back into iteration i+1.

Shift Registers are also used in the State Machine, to hold the Enum which defines the State. They're additionally commonly used to hold Clusters of information about the system or datasets for plotting.

Feedback Nodes, as far as I'm aware, behave very similarly to Shift Registers (but I don't usually use them (FB Nodes), because I can never remember which way around the arrows need to point, or the initialization terminal, and so on...). You should go ahead and use them if they're more natural to you, but they're less useful in a state machine, because they're localised - you can't pass data to a different state using a Feedback node.

[altenbach]

The problem with local variables is that they are always tied to a front panel element, even if the data contained in them (e.g. large data structures) is never of interest to the operator. They also cause extra data copies in memory (front panel control, transfer buffer, etc.). (OTOH, value property nodes are even worse, though, because they execute synchronously and force thread swaps!)

When you use a shift register, there is exactly one copy of the data in memory and it never bubbles up to the front panel unless you connect an indicator. If you read from a local variable inside a loop, the compiler needs to assume that the value can change between iterations (operation of the control by the user, writing to a local variable from elsewhere in a parallel process of the same program, etc.).

If the data is held in a shift register or feedback node, the data is much more protected and the compiler can make additional optimizations. There is exactly one data copy and at each iteration you can read from it (left part), modify the value, and write to it (right part), all in-place.

While similar, there are some functional distinction between shift registers and feedback node.

1. Shift registers:
   • always need to be anchored to a loop boundary
   • can only be locally initialized
   • if uninitialized, they remember data from a previous run
   • If resized on the left, can simultaneously provide multiple delays (i-1, i-2, etc.)
   • ...
2. Feedback nodes
   • Do not need any loops
   • Can be locally or globally initialized (often eliminating a first call?" primitive)
   • provide one output, but the delay can be configured (i-1, i-2, etc.)
   • you can cosmetically change the direction to a suitable program layout.
   • ...

I use each about 50/50, because each has it's own advantages that strongly depends on the use case. Learn how to use both. If a feedback node initially confuses you, start with a shift register, wire it all up, then convert it to a feedback node and see how it all ends up.

Now, let's talk about stacked sequences: Don't use them! Over my last 20+ years of LabVIEW use, I have found exactly one case where they are appropriate. (Sequence locals are NEVER appropriate!) Typically, the presence of a stacked sequences is a hallmark of bad beginner code (together with blatant local variable overuse).

In newer LabVIEW versions, the stacked sequence has even been removed from the palette, and the only way to still create one is to first place a flat sequence and then right-click convert it to a stacked sequence. Also have a look here.

So, yes, learn about state machines. It gives you all the functionality and scalability you need. (Stacked sequences are not scalable: If you even need to add a frame in the middle or rearrange the order, you need to basically start from scratch).