LabVIEW Idea Exchange

If there is one thing that tops my wish-list, that is a simple way to figure out the outcome of such simple actions as this:

Are the successive "Array" outputs going to be: {1, 2, 3} and {4, 5, 6} or {1,4}, {2,5} and {3,6} ?

I've been unable to find a good mnemonic to remember it.

So, each time I run into one of those, I've got to go through a debugging step. And since those functions are typically chained (say, convert an image into a 2D array, extract a sub-array, do some processing on it, replace the subarray, put back into image), this is a lot of debugging, which I have to repeat over and over again.

Don't get me wrong, debugging is not the issue. It is just that in language based environment, there would be no ambiguity as of which dimension of the array is read/written, because it is explicitly stated:

for (i=0; i<Nx; i++)

   for (j=0; j<Ny; j++)

       Array[i] = Input[i][j];

1D array functions are easy to interpret and use, but, at least to me, in higher dimensions troubles start with the simple "Index Array" function:

What's it going to be? {1,2,3} or {1,4}?

And if I want to access {2,5}, do I need to use this:

or that:

 ?

That may be just me (disclaimer: I can't seem to remember my left from my right), but I wished there was a more GRAPHICAL way to figure it out... I am not even starting to talk about more general N-dimensional arrays...

For 2D, here is my suggestion:

, or to mirror the actual control behavior:

Extensions to more dimensions could be looking something like:

and similarly for other array functions (I am just opening the Pandora box and running away).

Now, that does not really answer the question on how to figure out the outcome of my first example above... For this, I suggest (anathema!) to modify the auto-index design by offering an option to "expand" the auto-indexing icon and replace it with a larger, more explicit "function-like" icon:

Notice that, in my version of LabVIEW autoindex, you actually get a chance to choose which dimension is going to be auto-indexed. Of course that only works if know the dimension of the array beforehand, but that is most of the time the case.

Likewise for the autoindexing upon exiting a loop, although I am shying away from suggesting any design.

In summary, LabVIEW, which is supposed to be a graphical programming language, should offer better clues as of what some of the functions are doing. I have expressed my frustration with some of the array functions, but the same theme goes with others (such as strings! but then, LabVIEW is not a text-based language, so that would be unfair to try and compete with one).

My 2 cts.

I would like to see the functionality of the TCP and UDP primitives expanded to include more state information, better control of the connections and the capability to receive events for the connection.

Items that I can see which would be helpful would include the following:

1. Ability to enable/disable the Nagling algorithm.
2. Ability to abort a TCP connection with a TCP-RST. (The wire is there on the TCP-Close primitive but it doesn't do anything)
3. Ability to receive an event when data is present.
4. Ability to receive an event when the data has actually be put on the wire. (Currently the write VIs return as soon as the data is buffered. There is no ability to have the application wait until the data is actually delivered.)
5. More access to the IOCTLs that are available on a socket connection that a programmer has access to via Linux or Windows socket libraries.

It would be useful if we could connect a class wire to a case selector. You will be able to create a case for the children of the class. The internal connection for the selector will return the specific child class. This will eliminate the need to cast to more specific class inside of the case.

This idea came from this thread on Lava.

From an AE:

I confirmed with the Product Support Engineer for the PID Toolkit that the toolkit does not officially support the Mac OS X and therefore, we do not have an installer available for it. However, she also did mention that the PID Toolkit is created using LabVIEW code, so it is possible that you would be able to open VIs that come with the PID Toolkit in the Mac OS. I can submit a product suggestion for you to request Mac OS support for the PID Toolkit in the next release.

So here is the product suggestion. NI has gone to the trouble of building a cross platform set of VIs for PID and then stumbled in merely packaging it. Just build an installer.

Free labels and Name labels can be set to have transparent backgrounds on the Block Diagram.  For consistency of BD labels I have to manually go and set the wire labels background to be transparent to match.  If I don't my wire labels complain that they are treated as "second class labels."   Stop the discrimination! and give me the option to "Use transparent wire labels"

Provide an option to display a QR (2-D) code in the product activation dialog.  The QR code should contain a web address that would return the activation codes for all selected products.  For those of us stuck out in a lab or factory with only our smart phones this would provide a slick, foolproof way to enter all of the data needed.  It would save us from either making a round trip back to civilization (with a pad full of info) or getting carpal-tunnel trying to type all that stuff in on a little soft keyboard (multiple times for multiple activations = hand cramp).  We would still have to type the resulting activation codes into the LabVIEW activation screen but that's a lot easier than all the rest.

Idea details:

1) Provide a http link as a QR code 

2) Have the target web page auto-generate the activation codes and display them (preferably in a mobile browser friendly format)

3) As an alternative, let the user upload a picture with the QR code to the NI activation web site for the same result (works for anyone with a camera not just smartphone users -- this would also let you show off IMAQ.)

4) Profit

(And, once you have the QR-code generation code available, add a VI for it to LabVIEW -- see http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Generate-Barcodes-in-LabVIEW/idi-p/1283912)

Now that coding for LVXCC is finished (get over there and vote before November 6 in the UI Controls category!), back to the Ideas drawing board. 

A common messaging practice involves creating a messaging ref (whether Queue, User Event, or Notifier) from a clustered datatype. The next step involves sending some data along that ref, and the final step is receiving data from the ref:

Above, you can see that the first two messaging types return the entire data cluster on the Receive, thus requiring an 'Unbundle'. I like how the third messaging construct uses the Event Handler Structure to "fan out" the elements on the Event Data Node interface (well, every now and then I'd like access to the top-level data structure on the Event Data Nodes...). All three constructs require fully-formed data structure type information for the Send input.

The interface for these Send and Receive primitives could be simplified, yielding a significant reduction in the BD footprint and an appreciable decrease in layout maintenance. 

(Note, also, added a third element on the Dequeue graphic and centered the Enqueue by a pixel  )

Since the data is already strictly typed in these messaging references, additional type information is not needed in a separate Data Input Terminal.

Below I've illustrated a place I'd love to use this cleaner interface - between a While Loop and a Case Structure. We save 32 pixels - enough space to fit one more primitive into the Case Structure! 

Also note: this follows suit for current practices that allow you to "fan out" data structures on the syntax level, such as Property Nodes (with a cameo appearance😞

Discussion questions to duke out in the comments section:

1. Can the developer rearrange the order of the nodes (like in a Bundle by Name), or is the order fixed (like a Bundle)?
2. Related, can the developer select fewer or duplicate elements that are in the data cluster (like a Bundle by Name), or is the node size fixed to show the exact number of elements in the data cluster (like a Bundle)?
3. Are inputs Required, or can the developer leave them unwired to assume default data?
4. Would these nodes replace the current nodes, be an alternate display of the current nodes, or be new nodes altogether?
5. Should the Error Terminals go above the data I/O (like Scan From String) or below?
6. Do we want only the small icons (like Bundle, or Scan From String, and shown in proposed illustration) or the full data name (like Bundle by Name) for data IO on the node? Does it need to be configurable, like 'No Names', 'Short Names', and 'Long Names' on Property Nodes?

A change of inputs or outputs in a SubVI leads to the need for manually Relink all the calls to the SubVI.

As I often use the SubVI at many different places I would appreciate a function that automatic relink all the instances. Something like this: