How Im getting rid from controls and local variables?

[HaD]

What about queues?

Message Edited by HaD on 08-08-2007 07:23 AM

[GerdW]

Hi HaD,

queues are nice - but from a diagram view you also have some wires...

Queues are really good to move data from one loop/vi to another loop/vi, but they also introduce some overhead. And you need some additional vi to be able to change the contents of the queue when you want to rebuild some "block-diagram-only locals".

The basic principle of LabView is to use wires to store/move data. It is build around this principle. It is very efficient using this principle.
What else do you want to know about wires?

Using the programming guidelines from text-based languages for LabView will lead to unefficient/error-prone programs. That's why there is a LabView styleguide

Message Edited by GerdW on 08-08-2007 02:38 PM

[smercurio_fc]

It should also be mentioned that using a lot of local variables leads to race conditions, which are often extremely difficult to debug. Your statement "In my project im using a lot of controls, beacuse [sic] i need to use local variables (i dont want to fill my diagrams with lot of wires)." is a classic example of a likely poor or inefficient design. Thus, I would start by looking at the design of the code, rather than the application used to create the code.

I have also been programming with LabVIEW for years, as well as programming in text-based languages. The programming paradigms are different, and you must recognize that and "go with the flow', rather than trying to make LabVIEW into something it is not. Use LabVIEW for its strengths. Don't weaken it by trying to transform it into something that is more familiar to you. Spend some time going through the LabVIEW tutorials as well as reading the books. Remember: one can write a bad program regardless of what language one uses.

[minnellac]

The only thing I'd add here is that I've seen people use local variables as shift registers (when they didn't know what a shift register was). That's another reason people use them (inappropriately). So I'd say, if you've never heard of a shift register, it's time to look it up. Wires really are the best way to move data from one place to another, and if your diagram is getting so big that there are wires everywhere, you probably aren't familiar with making subVIs either. I like to try to follow a rule that I learned with text based languages, "if your program doesn't fit on one screen, it should be redesigned." The same holds for LabVIEW. This gets complicated quickly, but Functional Globals, or Action Engines are an excellent way to remove wires from your main diagram, and modularize your code at the same time.

Chris

[PaulG.]

To expound on what ssk said: Don't worry about having too many wires. There are ways to prevent this. The simplest and cleanest way to store a lot of variables is with wires going into clusters. These clusters would pass data from one iteration of your program to the next with a shift register. That is the essence of a functional global. The cool thing about clusters is that when you need another place to store another variable you create the variable and label it, then bundle it into the cluster. When you need to read it you simply unbundle the cluster and get the value from the labeled name.

[tbob]

If you are using a while loop (like with a state machine), you can use a cluster to hold local variables and use a shift register to store the latest values.  Use unbundle and bundle functions to read and write to the local variables.  See picture:

Message Edited by tbob on 08-08-2007 09:43 AM

[Marc_A]

And if you had LabVIEW 8.5, you could use the new in place element structure and update values of the cluster without making any copies in memory.

Message Edited by Marc A on 08-08-2007 01:32 PM

[HaD]

Tnx for all Replays.

you helpd me a lot.

[altenbach]

If you want a "variable" without a front panel object, use a "single process shared variable". (see also http://forums.ni.com/ni/board/message?board.id=170&message.id=261144#M261144)

Of course many times you think you need a variable because your mindset is still biased by traditional sequential text-based thinking, while you actually don't need any at all. In LabVIEW, the wire is the variable. A wire is a 1D object and take very little space on the diagram while any kind of variable (local, shared, global, value properties) is a 2D object with a significant footprint. Often, such variables break dataflow that then needs to be artifically reestablished using sequence strucures to avoid race conditions. This will clutter the diagram evem more! Debugging race conditions is no fun at all and might take more time than programming the initial code.

More importantly, if you force sequential execution via these mechanisms, you will often loose compiler optimizations for parallel execution and you'll end up using only a single core of your multicore CPU.

As mentioned by others, often a shift register is a great subtitution for a "variable" of you need to read or write from one updated location. You can even isolate it into an "action engine".

"Variables" are sometimes needed for communication between independent code segments but there are often good alternatives, such as "action engines", queues, etc.

Your notion of using LabVIEW without wires is a silly proposition and quite artificial except in the scope of e.g. a brain teaser. What counts is the user interface (users should not care how you do things under the hood. They only care that (1) the program works correctly and (2) is as efficient as possible (memory footprint, execution speed, etc.). "Variables" often cause extra data copies and might even force a switch to the UI thread. These are all things that will make the code less efficient. If you are dealing with huge amounts of data, it might mean the difference between "runs fine" and "out of memory".

In the same spirit, I could write code with my left hand tied behind my back and the monitor placed upside down. Silly, right? So why would I artifically want to restrict myself from using wires? 😄

The reality:

As one example, have a look at the "Q-factor" subVI posted here: http://forums.ni.com/ni/board/message?board.id=170&message.id=264924#M264924

A relatively simple VI using an eight-frame stacked sequence and 41 local variables (all tied to otherwise unneeeded FP objects!) :o. If you look at my modification posted later (Q-FactorMOD.vi), none of the local variables were needed at all. 🙂

[tst]

---

@marc A wrote:

And if you had LabVIEW 8.5, you could use the new in place element structure and update values of the cluster without making any copies in memory.

---

Actually, the pattern shown in tbob's example (forking the wire only to the Unbundle and Bundle nodes) doesn't create a copy either. The inplace structure is useful when doing complex nesting, when using arrays of clusters and when wanting to force LV to a specific inplaceness path.