LabVIEW Idea Exchange

Although it appears that the 2020 version of the Block Diagram Cleanup Tool (BDCT) does do a better job than its predecessors, I would still say that the BDCT’s results are still less than optimal. Most LabVIEW Idea Exchange posts concerning the BDCT talk about label positioning and alignment.  Here I would like to focus on the issue of horizontal expansion of the block diagram and a holistic view of what LabVIEW features contribute to that effect.

Like most programmers, when developing a VI block diagram, I try to keep the diagram no more than one screen wide.  I have learned a few tricks over the years that help manage horizontal expansion, such as resizing an object’s label so that the words appear on multiple lines before running the BDCT. This allows for some compression horizontally and allows for some growth vertically to compensate. Horizontal expansion of the block diagram is certainly expected to some extent because data flow happens left to right, of course; but it would seem logical to incorporate that knowledge into the BDCT algorithm to compensate and find ways to adjust the spacing so that the rearrangement creates more a bit more vertical expansion and less horizontal expansion—while still satisfying usual criteria such as no backwards-running wires.

Because data flow is horizontal, to help the BDCT work better, NI may want to think about what visual features—other than left-to-right data flow—contribute to a unnecessarily wide block diagram. I seldom have an issue with a block diagram becoming too tall.  Admittedly, poor programming technique can result in too-wide block diagrams, but let’s look at a few other things. What elements of LabVIEW’s block diagram unnecessarily consume width? Here’s a few that I could think of:

1. Long names in bundle/unbundle cluster objects, property/invoke nodes, Enum/ring constants, local variables, formula nodes, etc. – Most LabVIEW-supported languages are left-to-right horizontal. Long names, especially when using nested clusters, take up horizontal space. I like being able to use long names; it helps the code to be more self-documenting. If those type of objects supported word-wrap, that would help conserve width.
2. Expression nodes and multi-digit constants – no word-wrap available here either.
3. Named terminals of timing and event structures – They are what they are, and you cannot remove all of the ones you don’t use, and so they take up space horizontally.
4. Some native functions – There are some LabVIEW native function icons that are wider than they are tall. Some examples: In-Range/Coerce and Initialize Array.
5. Shift registers – It has a subtle effect, but shift registers are wider than they are tall. Do they have to be that way?

To fully tackle this issue, I believe you have to look at things holistically and not just as potential improvements that could be made in the BDCT.  Recognize that data flow is left-to-right horizontal and you will have long text names; you can’t really do anything about that. However, there are other things that could be done in LabVIEW feature-wise to help compensate for width-wise block diagram growth.

The current legend properties are too low level - requires a loop to iterate on active plot and set/get legend text.

There should be high level (express ?) VI's to do the most common task of labeling a plot legend.

Yes this can all be done with lower level primitives today but why waste everyone's time with coding something that is always needed.

Ideally an express VI that takes a reference to a plot and an array of numbers of strings and allows the user to generate an appropriate legend for the plot based on the array input. The express VI can be saved and modified by the user for special, uncommon applications but most users can just use express VI to quickly create legend for plots.

Since LabVIEW 2021 is announced that will adopt the advantage features of NXG, I expect some thing like:

- In NXG we could dock constants to functions & nodes. hope can also be in LabVIEW 

- In NXG we could also reduce space of block diagram by (Ctrl + mouse click & move up/left) while Down/right is to extend the space. In LabVIEW still couldn't reduce the space. all mouse direction are extending the space.

- provide unplaced terminal, controls and/or indicator pallet, is very use full.

- zoom in/out, I've no Idea why NXG can while LabVIEW can't.