Typed variables

[MarkGrindell]

In none of this do I want to use a control or even define or use more than a very limited number of controls; I want to perform sequential programing with minimal graphical content.

I understand that I can use enumerated types, albeit with difficulty, since Labview is inherently graphical and not as easy or elegant as text programing. But I do not see any indication about to how to create a variable of a particular type, or several of them, without placing graphical images on my "front panel" that would not belong there and have nothing to do with what I want to display. I work occasionally with the book "Labview for Everyone", but the book neatly avoids any such discussion. In real life, I find that Labview applications have huge numbers of unwanted screen objects that, for some reason, have to have Front Panel representations and simply cannot be confined to the Block Diagram and the algorithmic basis of the software. With critical software, this is a huge embarrassment and impediment.

Can any thing be done to remove the huge amount of clutter?

Many thanks

Mark

[altenbach]

The wire is the variable. If you need the front panel to store data that only belongs on the diagram, you are doing it wrong.

One possibility is to use a cluster in a shift register and interact with elements using bundle by name and unbundle by name or the IPE structure.

---

@MarkGrindell wrote:

... since Labview is inherently graphical and not as easy or elegant as text programing.

---

Graphical programming is significantly more elegant as text, IMHO 😄

Can you show us what you are currently doing? You mention "Sequential". What do you actually mean by that? Sequential execution is typically controlled by wired data dependencies. No "variables" needed.

[GerdW]

Hi Mark,

why don't you attach an example of your clutter, so we can show you how to clean it up!?

The general answer to your generic complaint is THINK DATAFLOW! 😄

[crossrulz]

---

MarkGrindell wrote:

In real life, I find that Labview applications have huge numbers of unwanted screen objects that, for some reason, have to have Front Panel representations and simply cannot be confined to the Block Diagram and the algorithmic basis of the software.

---

As other have said, that is typically due to the developer not understanding data flow.  "Variables" should be held in shift registers so that you can update them with every loop iteration.  For many variables, they are usually grouped in a cluster (or a struct for you C programmers).  And do make a Type Def out of your clusters so that you do not have to make a ton of edits when you need to add an item to the cluster.  Use the wires to dictate the order of functions instead of a sequence structure.

[drjdpowell]

Hi Mark,

I'm afraid you did the LabVIEW equivalent of posting on a board of C experts that in real life the typical application is a nested mess of GOTO statements so how come the textbook neatly avoids discussing this?