LabVIEW Idea Exchange

Community Browser
About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

Do you have an idea for LabVIEW NXG?


Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!

Post an idea

I want to be able to add a dynamic tag like <my exe version> to the Welcome title and Welcome message the installer displays to the user when they run the installation.  That way, they can see what version of the exe they are installing. 

I would like a feature similar to Control-Click-Drag which creates room within a diagram.  However, this version (Alt-Click-Drag) would create a rectangle of empty space bounded by the endpoints fo the drag, but only move those objects which within the new area.  Those objects would expand outward and push any objects which they bump into while expanding.  Objects which are distant would not be pushed.

I was thinking that defining packed project libraries as the source of VIs used by the LabVIEW enviroment would speed up everything ex. loading LabVIEW, loading palettes linking dependencies, building executables etc. + solve linking dependecies conflicts.

 

The thing that we could do is just add the packed project library for the standard LabVIEW functions as the base of the palettes, but since we want users to be able to see what's inside we would still leave the VIs in the same folders - this way the user would be able to choose if he wants to use the packed versions or the versions from the disk - unpacked. 

 

This way only the ones with a specific unpacked instance would have to be loaded as single VIs, and we would have everything nice and clean.

 

Tell me what you think.

 

Pack LabVIEW.png

When you create an Installer you need to select what is the other build spec that will be used to be installed.

 

Some time in the resulting files of an EXE build spec we got files that we don't need to be included in the installer.

 

So I propose to be able to select only the file that need to be installed, not the entire EXE build spec result.

 

Currently the EXE build spec result files are grayed out and we can only select the entire EXE build spec result files to be included in the installer.

For non-integer increments, the data entry currently accumulates binary errrors due to the limits if the DBL representation, so e.g. sometimes the upper limit cannot  be reached using the increment button several times, but only when entering the upper limit directly.

 

This comes up at regular intervals, e.g. here. In one fo these discussions, I long ago suggested to make it into an idea. It seems this has not happened, so here it is! Smiley Happy

 

This limitation needs to be handled with some internal code, e.g. to coerce the value to the nearest decimal fraction based on the least significant digit of the increment value whenever the up/down buttons are used. ... or something similar. Smiley Wink

It would be nice to have a browse option in Selecting Class in the "Class Specifier Constant" to easily find the correct class. This is similar to the browse option available in VI server.

 

BrowseOption-Class.png

 

For the most part coersions can be broken down into two classes: lossy (e.g. 64L to I8) and safe (e.g. U8 to U16). Why is there only one color option for coersion dots?  Could the vi analizer have seperate settings for max allowable safe and unsafe  coersions?

Everytime I build an executable I have to provide a custom INI file just to disable the localized decimal point. Please add a checkbox for this important setting to the application builder, e.g. on the "Advanced" page.

Include view modes 'Tile View' & 'Details View'.

 

IconEditor-Modification.png

 

The Help for LabVIEW 2014 on the subject:

 

http://zone.ni.com/reference/en-XX/help/371361L-01/lvdialog/application_item_tags_scmenus/

 

is missing at least one item: APP_SC_CURSOR_BRING_TO_CENTER, which I discovered a while back while searching the forum, in this thread:

 

http://forums.ni.com/t5/LabVIEW/how-to-detect-quot-bring-to-center-quot-cursor-event-in-graph/m-p/22...

 

I suspect there might be others missing as well.

The list is long, and to some extent, not very helpful.

Where, for instance, can I get an idea of what this menu item does and where it can be activated: APP_SC_X_SCALE

 

My suggestion: Update the list of Application Item Tags for Shortcut Menus in the Help and provide some detailed explanation of what they do and which controls they are associated with.

I would like a better way to clear the list of recent files and recent projects in LabView.  It is often disireable to clear the history when changing to a different project or a different user.   Currently the user must close LV, edit the .ini file and restart LV.  I would like to see menu selections added to allow the list of recent files and/or recent projects to be cleared.

Hello,

 

I was recently working on a project where I connected one output up to an input of a different data type.  I knew that I needed a conversion VI, and went to hunt down the correct VI.  Could we please write code that would automatically hunt down the correct conversion VI, insert it into a user's code, and make all of the necessary connections, simply with a double click on the broken error wire where there is a type mismatch?  This type of quick conversion feature could be very useful.  And users could toggle this feature on or off at their discretion.

 

QuickConversion.png

find.png Arrow.png PE.PNG

Some times it is not easy to find the actual edited vi in the project window.

I would recommend to add an additional entry in the icon pop up window (front panel and block diagram window) that finds the actual vi in the project window.

It should:

  • open Project window and brings it in front,
  • jump to the actual vi in the Items view ad selects it

Simple Idea:

There should be a timed FOR loop.

 

All the same awesomeness of the Timed (While) Loop, but stops when the auto-indexed array finishs or after N executions.

 

A picture because Ideas with pictures get more Kudos:

Timed FOR Loop 2.PNG

 

Currently, when opening a command window with the System Exec function, the "wait until completion?" option performs two operations.  It causes the VI to wait until the command is completed, and it suppresses the output in the command window.  The output becomes available on the standard output terminal after the command has completed.  This causes problems if you need to see what is happening in the command window, and you need the VI to wait until the command has completed. 

 

It would add more functionality if these options were separate.  One option, "suppress output?", would suppress the output in the command window and put the output on the standard output terminal.  The second option, "wait until completion?", would make the VI wait until the command has completed.

None of the inputs to the Format Value function are required. The Format and Value inputs should be required, because without both of those the function is pointless.

Many people don't know, but there is a great VI in vi.lib called Open a Document on Disk.vi which does exactly as it explains.  If you feed it the location of any document (Word, Excel, HTML, PDF, ANYTHING!) it will open it with its default program on the computer.  Unfortunately this VI is hidden from the palette deep inside the vi.lib somewhere.  I think this should be placed on the palette as it can be very helpful in application development.

 

The VI is located at C:\Program Files\National Instruments\LabVIEW 2009\vi.lib\Platform\browser.llb\Open a Document on Disk.vi (default LabVIEW installation directory may be different) 

Wish there was an “inspection window” showing the block diagram of a sub-vi on mouse-over. (double-click & open to edit). Perhaps, it can even appear below context help.

 

(Not sure if someone has already suggested it) 

I don't like that controls, type defs and strict type defs all have the same file extension: "*.ctl".  I'd like to see something like:

 

  • Standard control: *.lvctl
  • Type definition: *.lvtypedef

(I don't think there needs to be two extenstions to distinguish between type defs and strict type defs).

Dear users,

 

Summary: Manifest / display non-standard system colours (those with active 25th bit) similar to 'T' for transparent.

 

Not sure how it should look like, some ideas here:

- display "T" or "S" for those colours as well; maybe in a colour that is in contrast to the colour displayed

- reserve a few pixels in a corner of the color box a paint those white / contrast colour

 

The system colours cannot be distinguished from the user colours easily. Right, they do not mix with the history and they have a special section in the color picker dialogue. But the issue of mistaking the system colour for a standard colour appeared several times in the forum:

http://forums.ni.com/t5/LabVIEW/Can-one-re-define-the-colorbox-to-have-any-16bit-output/td-p/2859380

http://forums.ni.com/t5/LabVIEW/Control-color-using-calculated-value/m-p/489080

http://forums.ni.com/t5/LabVIEW/System-colors-do-not-give-correct-RGB-values/m-p/868863

 

Well, some food for thoughts.