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

State Machine Sample Projects and LabVIEW courses teach that you can create a 'stack' or 'run-time' data cluster, which is passed to every state via default tunnels and a shift register on the While Loop.  Screenshot from the State Machine in LabVIEW 2017 SP1, below:

2018-02-22 11_58_36-VirtualBox.pngNewer LabVIEW programmers need to make a leap from the structure called 'cluster' and the feature called 'shift register' in order to apply them as a very powerful, and now standard, practice of using a cluster to store the data for that State Machine.

 

My suggestion is that a unique type is added, called 'State Machine data' or 'Run-time data' so that the new user experience is more intuitive for the use of structure that promotes maintainability and readability.

In LabVIEW 201x, this could be something similar to the Channel Wire dialog, to prompt a user to input all their data types up-front, according to their design.

In LabVIEW NXG, this could be a native part of the While Loop, and the user could use the Properties dialog from the right hand side.

Once the 'State Machine Data' is configured, any Case Structure that the data is wired to will populate with a Node appropriate to that environment, such as an Unbundle or a growable Node similar to an Event Structure, in LabVIEW 201x, or a Property in NXG.

I've seen other posts about a State Machine Case Structure hybrid, but that is not what I'm suggesting.  I still believe that primitive structures should be the choice, and I'm focused on getting people to write good code, with less barriers to understanding.

2018-02-22 12_35_25-VirtualBox.png

Looking forward to the feedback.

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 envision a structure much like a case structure, in which you select your event for evaluating the code inside the structure and the values become constants at the node. The interior would allow code that may normally not be able to run on the host for example, on fpga it might allow the use of doubles and strings and resized arrays, because it isn't actually going to be executed on the host just evaluated and stored as a constant. This would allow for more configuration for fpga and even have some benefits at the traditional desktop environment. For example you could set the structure to evaluate on app build and produce a string constant that is the build date so the build date could be shown on UI to help distinguish builds. 

image.png

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.

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

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

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

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.

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

 

 

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.

LabVIEW's HTTP Request client currently does not support the PATCH method. This method is becoming increasingly more popular within RESTful API's and has been an officially recognized verb since 2010 (RFC 5789). It should be fairly simple to integrate, since LabVIEW runs cURL under the hood and cURL implements it with curl --request PATCH

 

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?

Please let me opt out from this new feature, introduced in LabVIEW 2017, permanently in the setup dialog.

Using LabVIEW for a very long time (since LabVIEW 2.0), I never wished such a feature (it got only 27 Kudoes) - and - I am even using it's "anti feature", implemented up to now, constructively to detach objects (Pull control into a structure, connect it to the new target - and "Ctrl B").

This new feature, forced onto everybody, would be less annoying, if pressing "W" would reliably disable the feature. However,  at least in vritual windows machines (Parallels) on a Mac, it does not work 50% of the time.