LabVIEW Idea Exchange

Current behavior:

When saving a new .lvlib inside a .lvproj the save file dialog brings me to the last saved location which is often a different repo.

Desired behavior:

When saving a new .lvlib inside a .lvproj bring me to the root directory where the .lvproj is saved and not the last saved file location. i.e. implement the same behavior as when saving a VI inside a library or a class. This would solve the issue of VIs accidentally being miss-saved outside of the project folder and then getting lost.

It would be nice to have the ability to use a Startup VI icon as the executable icon from the build specifications menu.

I've already made a post on extending File I/O operations so I figured why not make a post on my most commonly used OpenG palette, the array palette.

There are so many good nuggets of Array manipulation code in OpenG.  This stuff isn't perfect, and could be optimized, but the convenience of it makes sense especially when you realize there is so many things you can do with arrays.  Lets start with the Index Array, one of the most commonly used functions.

Here we see the native function allows for an N dimensional array to be indexed.  The OpenG function only supports 1D and 2D arrays.  And when using a 2D array, the OpenG function must specify both a row and a column, you can't index an entire column or row.  Both of those are very useful features of the native index, but there is something the OpenG function does, that the native doesn't, and that is index multiple indices.  You can pass in an array of indices and pull them all out in the order defined.  This can be used as a reorder function that takes an array and scrambles it the way you like.  Adding this feature is already on the idea exchange.

Again when it comes to polymorphism the native function beats OpenG.  The native delete supports deleting from N dimensions where OpenG is just 1D or 2D.  But OpenG allows for deleting multiple indices from an array, and if it is a 2D array you can specify if you want to delete rows or columns.  This would be a nice addition to the native function.

A conditional auto index function doesn't exist natively in LabVIEW.  You can perform a similar function with the conditional auto index tunnel on a for loop but having a single function would be useful.  This idea is on the exchange in multiple places, Link 1, Link 2.

Ever need to remove duplicates from an array?  Or remove all zeros or NaNs from an array?  These two functions do just that and on the forums all the time are requests for functions like this with no direct replacement on the native palette.  A nice feature of the remove and filter are they output the indices that were removed.  Combined with the fact that the delete, and index accept multiple indices make these very useful.  Also the items to filter for the filter can be a scalar or array which is nice.

Ever want to sort an array and know how it was sorted?  This OpenG function can do that along with specifying what order, ascending or descending to use.  The OpenG sort also supports 2D arrays where you can specify if you want to sort on rows, or on columns.

When using LabVIEW in combination with other languages, it would be really nice for LabVIEW to be able to read from and write to the stdout and stderr streams. For example, when writing a dll in C that is to be used by LabVIEW, it would be really nice to be able to see the output and error streams from within LabVIEW. As it stands you have to jump through hoops in another IDE or create a log file or some other workaround if you want to see what might have happened inside the dll to cause it to crash.

LabVIEW classes are how you create new data types in LabVIEW. But part of being a new LV data type is having a front panel representation. Although users can write XControls for displaying their classes, and they can put those XControls in the palettes, whenever a user of their class chooses "Create Control" or "Create Indicator" for the LabVIEW class terminal, they get the cube display. In order to really add a new data type to LabVIEW that behaves as well as, for example, the Timestampp or the Waveform, there needs to be some way to associate a class with an XControl and say, "This particular XControl should be used as this class' default control/indicator whenever one needs to be built."  (To prevent infinite recursion and load dependency problems, whenever you did Create Control/Indicator on a member VI of the class, users would still get the cube control/indicator.)

In LV 2011, an asynchronous Call By Reference feature was added to LV. This feature added two new nodes:

• Start Asynchronous Call
• Wait On Asynchronous Call

It would be nice if there was a way to use the LV event structure to wait for the results of an async call. For example:

I am not necessarily  proposing this is the way to integrate the ACBR with the event structure, it is just one suggestion. Instead, I hope this idea can gage the amount of interest in some sort of event structure integration. If anyone has any better ideas or suggestions, please say so in the comment.

I continually find myself fussing over the "configuration" of terminals. There are many permutations of icon/condensed view and label alignment, yet little consensus thus far for a standard.

My goal is to convince you this: Having different "flavors" of terminals does not make LabVIEW easier to understand or more "customized" to your preferences or learning style. Instead, it creates a source of confusion for new users to identify these Block Diagram components, and creates a hassle when it comes to formatting new or existing VIs to "your style". And no more label gymnastics trying to fit what should be a  into a  or a .

Just a few Common Terminal Configurations:

1. Default Alignment - Not too bad, but not so great for stacking terminals vertically
2. Block Diagram Cleanup Tool - Interesting choice of label alignment...
3. CTRL+Space then CTRL+T - This is the "best" style, but it falls short in correctly aligning label in Icon View (arguably of inconsequence, since Icon View is not "best" style)
4. The "Rogue Drag" alignment - Now where'd that label go?
5. The "Monk" alignment - Everything has to be perfectly snapped to center
6. The "There's a 'Size to Text'??" alignment - AKA - "This is what happens when I open your VI on my system" alignment
7. The "Don't Stop - Believing - Hold on to that Feeeeling" label - I can't let go of LV 4.0 or Power Ballads
8. The "But it takes up too much BD space - I'm'a remember what it's called" guy - or worse - "Neat, terminals can all have blank labels!!"

1. Default Option: Do NOT Place FP Terminal as Icon
2. Separate label locations for Controls and Indicators
3. Lable Position Options
4. Add a setting to allow different label positions for controls and indicators

I am getting tired suggesting small ideas that could all be placed under one single umbrella:

Any right-click option should also be available from the properties dialog of the item!

Here are some recent example

• Richer Property Dialogs for Structures
• Add "Loose Fit" to scales property page
• Allow access to default value on control properties dialog

But there are probably many more....

Estimate and show the Time Remaining during LabVIEW Installs, using selectable and realistic time units:

.

String functions accept array input.

Example:

Benefits:

1. Avoid placing For loop or Subvi with for loop
2. Looping performance can be improved with better logic inside the function.
3. Block diagram space saving without for loops

Thank you

Adarsh

CLA from 2014