Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
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!
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:
Newer 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.
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.
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 v18.104.22.168 depends on LabVIEW NXG v1.0. But the installer indicates the version of LabVIEW NXG to be installed is v 22.214.171.124152-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.
(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:
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.
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.
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.
NI LabVIEW allows VIs with invalid characters such as "?" in the filename inside an LLB file as shown below:
However when it comes to building a Source Distribution / TestStand Deployment that uses this file it returns an error as shown below:
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:
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.
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.
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.