LabVIEW Idea Exchange

The current behavior of LabVIEW is as such:

The pick list of event data strips the cluster, only allowing access to the elements inside the cluster. In order to manipulate the native datatype, you must reconstitute the cluster inside the event structure, a performance hit on large data structures firing at quick event rates. This is not to mention a messy FP.

I suggest that User Events preserve the clustered event datatype, allowing the programmer to access to the native datatype on the consumer end. The option to select only the element "Clustered Typedef.Array of I32s" of course still remains, but is not forced upon you. (Note that the below block diagram is NOT a direct LabVIEW screenshot... brought to you by trickery and a paint program. I clustered the cluster on event datatype [not shown] so that the event structure could eat the outer layer)

My motivation with this suggestion is directly linked with my other post on the Big Typedef Issue.

The current implementation of the "Disabled and Grayed" state of a FP object is unusable in a professional project. It adds a shading to the bounding rectangular region around the FP object, even shading pixels that were previously transparent (see below).

This proposal brings this function up to the bare minimum of "usable". As a bonus, consider even introducing new property nodes for FP objects that define new colors for the disabled state.

LabVIEW loops are quite flexible and allow me to do just about anything I want, but I often find myself writing the same code over and over again trying to iterate across different data types and data structures. There are several situations where smarter looping constructs could greatly simplify my code. One simple example is stepping by a delta between a minimum and maximum value. Currently, I have to calculate the number of iterations required ahead of time (for a for loop) or do a comparison with the maximum (with a while loop) and use shift registers to maintain the intermediate value. I'd like to be able to wire the max, min, and delta to my loop and have LabVIEW do the required calculations for me. The iteration terminal could also adapt to the proper data type given the input parameters. Perhaps the iteration terminal would have two outputs, one with the current iteration count and the other with the proper iteration value.

Another useful feature would be allowing me to wire a queue reference to the loop count terminal of the for loop and having it automatically pop each value from the queue and feed it to me through the iteration terminal. It would do this until there are no values left in the queue or until the code stops the loop. One could write an algorithm that pushes new points into the queue from within the loop or push the current value back onto the queue for later processing.

I'm sure there are other useful iteration strategies that are fairly common, please share them with the community. 

While there are ways to temporaily disable autowiring, some should never happen in the first place. For example if the resulting wire has a net right-to-left flow, it should not be created at all!

Let's have a look at the following simple scenario (see picture):

Place an "add" primitive (or almost anything else!), then use ctrl-drag to create a second copy right below it. (Sometimes we need to add a few different things in parallel!). LabVIEW immediately connects a random input and output with a circuitous backwards wire for no good reason at all. 😞

If I really wanted them to be connected, I definitely would have placed them side-by-side!!!

Idea summary: if any auto-generated wire would result in a net backwards dataflow, it should not be created at all!