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

One of the fiddly things I seem to do more than I'd like is adjust the bottom of block diagram comments to the right height. At a minimum there, but also for similar text boxes on the front panel or subdiagram labels, etc. I'd like to have a snap feature that sizes to a multiple of the text height. Examples:

 

I have several LabVIEW applications that I work on, and each of them has a Perforce workspace associated. Every time I switch to a project that is in a new workspace, I have to dig through the SCC configuration menu to switch workspaces, which takes a while.

 

It would be really sweet if LabVIEW recognized that a project file was in source control, and associated the workspace with the project file. (Especially because I could have two application projects open, each in its own workspace.)

Installers should show the public version of dependencies instead of internal versions.

 

This is a specific example, but I presume this behavior is more widespread:  An Add-On that has a dependency on LabVIEW NXG doesn’t list the (public) version of LabVIEW NXG upon which it depends.

 

The OpenG Library v1.0.0.0 depends on LabVIEW NXG v1.0.  But the installer indicates the version of LabVIEW NXG to be installed is v 4.9.3.49152-0+f0.  To someone not familiar with the internal version numbering for LabVIEW NXG, it’s not obvious that this refers to LabVIEW NXG 1.0. This may lead someone to install an undesired version of NXG.

 

Review.png

 

(I had NXG 2.0 already installed, and I assumed, incorrectly, that the version of NXG that the OpenG dependency referred to would also be NXG 2.0.)

 

By changing some NIPM settings (e.g., enable the "Show full version numbers and infrastructure packages" option), one can logically (but not definitively) deduce the public version that the internal version is referring to:

 

Review 2.png

Is anyone at NI paying attention to this thread?  https://forums.ni.com/t5/LabVIEW/Extremely-small-cursors-on-both-the-front-panel-and-the-block/m-p/3...

 

It is a very serious problem and it needs a solution fast!

Okay so lets say you have a VI that you developed, and works great on its own.  You have some nice scaling and control manipulation with panes and custom resizing code.  All works great.  Then you realize this might be handy to have in a subpanel.  So you insert it into a subpanel, which itself can be resized at runtime.  The only problem is, if code isn't written to handle the resize of the Subpanel properly, then the user could accidentally make the subpanel smaller than the minimum VI size that is inserted into it.  At which point the UI will get messed up and making the subpanel larger will not bring it back to the desired look.  Here is a thread where I post a simple example.  If the subpanel is set to fit to a pane, then you could programatically set the minimum pane size, to be the same as the minimum front panel window size, of the VI being inserted.

 

But if the Subpanel isn't in a pane, then there could be other issues.  So this idea is to have a property of a Subpanel that is "Minimum Subpanel Size".  Which will not allow the control to be smaller than a set size.  To make things even easier I propose a property that is "Set Minimum Subpanel Size to Minimum Front Panel Size".  Now when you try to make the Subpanel too small with a property node, it will generate an error, just like if you try to set the Front Panel too small with a property node.  And if the Subpanel is in a pane and being resized, this would prevent the control from getting smaller, and prevent the pane from getting smaller.

I am struggling (yet again) with LabVIEW installation problems that appear to involve LabVIEW 2017 (and possibly LabVIEW 2016 f5 patches).  After having systems with multiple (sometimes only 2) LabVIEW Versions installed "go south" (typically by having MAX stop working and Block Diagrams with DAQmx code fail to load), I've tried to "Remove All" NI software, only to discover that "bits and pieces" still remain, both on Disk and (especially) scattered throughout the Registry.

 

I've been working with NI Support for 2-3 weeks trying to "recover" from a LabVIEW corruption probably caused by installing the 2016 f5 patch.  We finally decided to do the "Uninstall/Reinstall" route.  Although I got 2012 SP1 installed, 2014 SP1 failed (could not install NI Network Discovery 14.0, "Verify you have sufficient privileges to install Services").

 

My concern is that, short of reformatting my hard drive and reinstalling Windows (which I was forced to do on two of my PCs), there appears to be no way to fully uninstall all NI Software.  I would like to propose that NI develop an "Eraser" utility (like Eraser for Microsoft Office) that searches out all files that NI puts on the C: drive (not in User Space) during installation and all Registry entries that it scatters throughout the Registry, allowing the PC to be "rolled back" to a "pre-NI" state.  Such a tool might want to be restricted to Full or Professional licenses, or maybe provided on an "As Needed" basis by the NI Support Team, but I really don't want to have to rebuild yet a third PC ...

 

Bob Schor

It would appear that NI Package Manager requires elevated privileges via User Account Control to even run.

Whilst clearly for some actions this will be required for some install/uninstall actions and e.g. changing registry entries, it isn't clear why this is needed simply to open Package Manager to view what is installed and for other actions which may only make JKI VI Package Manager type changes to VIs within vi.lib etc.

 

If the medium/long term plan is for NI Package Manager to replace JKI VI Package Manager then it needs to support the ability for developers to easily add/remove VI packages without requiring IT administrator assistance each time.

It would be much better if the application was structured such that elevation is only required when this is absolutely necessary for the actions being undertaken at that moment and/or the user is able to explicitly run the application with elevated privileges where these will be required.

I did try to post this in Additional NI Software Idea Exchange and that wasn't possible but please move this should there be somewhere more appropriate.

So you have a giant trace, and you're looking for something specific. You CTRL+F and look for it.... ok... wait... which one did it find.

Search highlight.png

(hint, it's the light grey)

 

 

You really need a bolder color for that. For instance, if I click, it does this.

Search highlight 2.png

Now THAT is a highlight

When a 1 Dimensional array of any type is showing only a single element, LabVIEW forces a horizontal scrollbar. I couldn't find any documentation or reasoning behind it. It's really annoying and ruins UI design that Vertical is the normal scrolling direction for just about everything else ever and LV messes that up for some seemingly arbitrary reason.

Title says all. Can't believe it was never proposed; if it was, I couldn't find.

Missing that, I have to that programmatically, but it's always a detour:

2017-09-28_11-42-52.png

Should be quite easy to change the property page like e.g:

LabVIEW_2017-09-28_11-02-36.png

(6 colors for system booleans, 4 for all others, as known)

 

 

When setting up In Place Element structures, the current work flow is:

 

  • Drop the structure
  • Right click, add the node you want
  • Wire the reference / array / variant in

It would also be nice to wire the references I want to use to the border of my IPE structure, right click on the tunnel (c.f. for and while loop auto-indexing context, or shift register/tunnel) and select from a sensible list of incoming element types relevant to my incoming wire.

This would be fantastic to see alongside similar ideas such as this or this.

dvr-rcm.png

Make it possible to create and modify Run-time Shortcut menus via scripting properties, and to retrieve them at run time. Any reason why not possible?

A LabVIEW application installer generated from App Builder creates multiple folders and files in the folders. It is desirable to have a single file installer so that customers see only 1 file to install.

I would like to have the possibility to "negate" some comparison functions such as "Empty String/Path?". This can avoid to add the "Not" operator.

The picture below is a possible implementation. The dot on the input (on the output ok also) is showing the negation.

Labview Idea.png

This might be good to be implemented for the following functions:

Labview Idea 2.png

NI LabVIEW allows VIs with invalid characters such as "?" in the filename inside an LLB file as shown below:

LLB.png

 

However when it comes to building a Source Distribution / TestStand Deployment that uses this file it returns an error as shown below:

Build Error.png

 

This inconsistency within LabVIEW is quite frustrating where one part allows invalid characters in the filename and another part will return an error. Since the invalid characters are allowed in VI filenames within LLB files I would suggest that the LabVIEW build tools also handle them graciously.

 

During the build process it could quite easily rename the file "pi40iv Can Connect Channel?.vi" to "pi40iv Can Connect Channel_.vi"  and link the VIs that use it to the newly renamed file. The build tools already contain the ability to rename files by adding prefixes so something like this would not be that difficult.

 

While people may argue to just rename the filename within the LLB and be done with it, the fact that the LLB is a perfectly valid file in the Development Environment but causes problems when trying to do a build is a problem that should be rectified.

 

The LLB in question is one that is not developed by us but is part of a Pickering Driver Installation obtained from the following location:

http://downloads.pickeringtest.info/downloads/drivers/IVI/

Therefore every time we install a new version of the driver we would need to rename the VI filename within the LLB file.

Once in a while I encounter a case or event list that forces me to grow the structure

- in order to keep the list readable:

Selector.png

It would be nice if the item-list would automatically "wrap" instead.  

Selector4.png

Add "Find All Instances" for polymorphic VIs. Right-clicking a normal VI's icon in the upper-right displays a pop-up menu with quick access to a "Find All Instances" item which helps greatly when navigating code to find all callers, then their callers, etc. However, when a caller happens to be polymorphic "Find All Instances" is not available and the work-flow is broken. Ctrl+F or Edit, Find can be used but the Find dialog must be manually configured: "Search for" Objects may have to be selected if Text was last used; "Select Object" must be set from a looong list of VIs. By that time, concentration is lost.

As discussed here, please incorporate the System Controls 2.0 UI elements into core LabVIEW. This would eliminate the need to visit VIPM to obtain the full functionality of the System UI control palette. System Controls 2.0 is not an additional UI style, rather it is the partial completion of the original System controls palette.

 

Including these controls in the default installation would allow the merging of these two palette entries for those that use the System controls for UI development.

 

system.png

 

 

When running LVCompare from the command-line (i.e. from my Tortoise SVN shell) it will try to open the compare tool in the last context which was active.  Unfortunately, the code required does not run in RT or FPGA contexts.

 

I would propose that LVCompare, when called int his way, should ALWAYS run in "My Computer" Context.  Or even better, in a context all of its own (new Project).