LabVIEW Idea Exchange

It is common, in writing reusable code, to handle arbitrary clusters in variants.  To access the elements of the cluster, one wants to convert the cluster into an array of variants containing the individual items.  After access, one needs to convert the array of variants back into the original cluster.

There are several examples of packages that use this on NI.com and in the LAVAg.org Code Repository.  They mostly use functions for working with Variant Clusters from OpenG; however, these can be quite slow.   Recent LabVIEW versions have had the ability to do much of the functions quicker, however, there is a very imortant missing native ability: to convert an Array of Variants into a Variant Cluster.

The other direction, Cluster to Array of Variants, works like this:

But trying to reverse the process breaks:

So my idea is make the second image work; make an Array of Variants interchangable with a Variant Cluster in the "Variant to Data" LabVIEW primative. The interchangability should apply to contained subclusters/arrays also.  The matching of array to cluster elements can be by cluster order rather than element name.

This would greatly aid the performance of reuasable packages that operate on arbitrary clusters.

There is a missing property that it will be very useful to have to access the menu reference.

Old way:

New way:

This way it's more clean and we can open a reference to the menu from another VI

Dany

If you right click on an array wire and choose "insert - array palette - inert into array" you geht this:

It would be better if this happens:

Must have been discussed a zillion times, but just in case, there it goes:

what's wrong with this picture?

apparently nothing. If I grab the function and move it:

Note that LV must have "computed" something here to reroute the wires, etc.

But wait, what happens if I grab the wire and move it?

Oops! I did not connect the output of the function to the indicator. Instead, I inadvertently connected the input.

Needless to say, this is a F-ing nightmare to debug... unless you think of verifying that the value before the function and after the function actually gets incremented. Which you will, eventually, but not until after having wasted a lot of time thinking of all other possibilities elsewhere in the code.

Bottom line (this is only an example I just encountered for the umpteenth time a minute ago), LV does not provide much in terms of warning for this kind of potentially very damaging error. This is very much related to the discussion I started here with very limited success (man, am I an upbeat person!). 

Suggestion: not only allow to define VI outputs as REQUIRED but also add warnings when a function that has its only or most important output(s) unconnected.

And if not everybody is interested in this kind of sanity check (I am talking about functions), you could offer this "warning" as an option (in a warning definition panel in the Preferences).

I tried searching for a similar suggestion but couldn't find one but I would bet that this has been suggested several times.

Why is the routing to multiple adjacent array terminals (or similar) so terrible ? The top Build Array shows the standard routing chosen by LV when wiring from a group of refs starting at the top. Starting from the bottom isn't any better. The lower Build Array is what I always change it to !!  Why is this not the standard routing ? 

I'm sure all of you VI meisters with OCD can sympathise.

There is something wrong with this VI, although you wouldn't know it unless you ran it (and I should warn you that it will annoy you if you run it):

What's wrong with it is that auto grow has been disabled and there's some annoying code hidden there beyond the loop boundary. This is one of my least favorite things about LV - it allows us to hide code completely and get away with it. I don't think it should.

LV already has auto grow enabled by default to handle some of the cases which cause this issue, but I know that many many people don't like it when LV automatically plays with their BD layout (and rightly so) and auto grow only covers some of the cases, so I think we need something more encompassing and less obtrusive, and I would suggest breaking the VI if it has hidden code.

I also know that LV has warnings and VI Analyzer has tests for this, but I think this needs to be something which doesn't let you get away with it.

I think LV should break any VI which has any of the following:

• Objects beyond the visible boundaries of structures (including wires and constants).
• Objects behind other objects (possibly not including wires).
• Overlapping tunnels on structures (or maybe just not allow them to overlap at all)?
• Anything else?

Hello (again),

Well, this idea has haunted me for a couple of years, and now I think it's time to break it. I feel the For-loop, the While-loop, and the Timed loop are so similar that they are begging for a merger. It would simplify, and with a little thought strengthen, the API, to have a single configurable Loop Structure instead. What's the difference between a While-loop and a For-loop with a conditional terminal anyway? Have you ever wished for iteration timing information being available inside your For-loop (I know I have)? "Oh but those structures have been around forever, we can't touch those"... Well, what happened with the stacked sequence structure? Please read on for a minute or two and tell me if I'm losing my marbles here. And please chip in with your own modifiers, since LabVIEW is growing in (sometimes unnecessary) complexity. Thus:

Instead I propose the Loop Structure which when initially drawn looks like this:

The above is basically a loop running forever (don't worry, you can stop it), but it can be modified to do many many other things, just be patient . One feature of the loop structure is the box in the upper left corner, which is quite similar to what we have in a For-loop today. This will, no matter the configuration of the loop structure, always show the current iteration setting of the structure. By default that is never-ending, but if you drag in a conditinal terminal you change the loop behavior to a While-loop (note that I suggest a simpler way to get to the terminal than via the right-click context menu):

Arrays can be wired to the structure border as usual to give a For-loop like behavior. The count terminal changes from "Inf" to an "N" to indicate that it's a finite albeit at edit-time unknown number of iterations:

You can wire out of the count terminal inside the loop structure as usual to get the count at run-time of course. If the iteration count can be deducted at edit-time a number will appear instead of the "N":

This number is blue to indicate that it is automatically calculated. You can just type in a new number if you wish to run a different number of iterations, in which case all the usual ideas on this Idea Exchange about what should happen to auto-indexed tunnels apply. If you override the count manually the number will be in black text:

You can of course combine different exit conditions, in this case a fixed number of iterations with a conditional terminal wired as well for possible early exit:

The automatically calculated count terminal aids in determining if the loop actually runs the desired number of times:

All the usual stuff about tunnels, shift registers and so on apply to this structure as well, but on top of that it can also be configured as you're only used to within a timed loop. Consider how valuable some of these parameters and settings could be for ordinary loops, for error handling and for timing for instance. But the main feat is that this is still the same loop structure - it will simplify the palette a lot:

And now an additional feature that ties some of the parameters from the timed structure together with ordinary loops: this loop structure is event-enabled! I propose stuff like this (we're only scratching the surface with this image):

It's late where I am now, so I'll stop now, but all of the above makes it extremely easy to do things you simply can't do today - what about a Priority Structure?:

So, is it time to consolidate the ever-evolving loop code of LabVIEW into one structure to rule them all?

Cheers,

Steen

Hi,

I just thought of a small thing when I enabled the Dynamic Event Terminals on an event structure for the zillionth time - why don't they just appear automatically when I wire a compatible wire to the structure border? Like this:

Of course once in a while you don't want to wire to the Dynamic Event Terminal, but instead want that wire to tunnel through the structure border, but a dab on the CTRL or ESC key could make the Dynamic Event Terminal "suggestion" disappear.

Cheers,

Steen

Simple idea is to make the icons found in the palettes, the block diagram and help all match.

The icons in the columns are all the same function, however, there are some significant differences. It is reasonable to expect the help menu icons are expanded to show additional functionality, but there is no reason why the palette and BD icons should be different. The core of the icon in the help menus should be the same too.

These icons screen shots are from LabVIEW 2018.