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!
When you discover what you consider to be a bug in LabVIEW's IDE or language, it's a difficult process to report the bug and track the bug's status as new LabVIEW editions debut. This idea addresses the transparency and facilitation of this process, and is meant to appeal to both those who create LabVIEW and those who use LabVIEW.
Problems with Current Issue Tracking Platform
"Platform" is a generous term for the current reporting and tracking process:
The issue reporting procedure is undocumented - few seem to know how to report issues, fewer know how to track documented issues
Duplication of effort (for users, AE's, and R&D) is probable since there is not a centralized, searchable repository
Relies on unreliable methods including email, FTP uploads, phone conversations, forums...
Comparing LabVIEW Issue Tracking and Feature Tracking Platforms
Before the Idea Exchange, there was the Product Suggestion Center (PSC). What's that, you ask? It's a hole in the internet you threw your good Ideas into. The Idea Exchange revolutionized Feature Suggestions by introducing a platform that allows an unprecedented level of public brainstorming and symbiotic discussions between R&D and customers. Further, we can watch Ideas flow from inception to implementation.
I want to see an analogue for Issue Tracking.
A web-based platform with the following capabilities:
Allows users to interactively search a known bug database. Knowing the status of a bug (not yet reported, pending fix for next release, already fixed in new release...) will minimize duplicated effort
Allow embedded video screen captures (such as Jing)
Allow uploaded files that demonstrate reproduceable issues
Allow different "Access Levels" for different bug types. View and Modify permissions should be settable based on User ID, User Group, etc... (Some types of bugs should not be public)
Allow different access levels for content within one bug report. For instance, a customer may want a bug report to be public and searchable, yet attach Private Access Level to proprietary uploads.
Allow collaborative involvement for adding content to Bug Reports, where any member can upload additional information (given they have Modify Access Level privileges)
The Homepage of the Issue Tracker should be accessible and visible through ni.com (maybe IDE too, such as a GSW link)
A more detailed Bugfix Report for each LabVIEW debut (cryptic subject lines on the current Bugfix List is not helpful)
Specific fields such as Related Bug Reports and Related Forum Posts that allow easily-identifiable cross-referencing.
An email-based alert system, letting you know when the status or content changes in bug reports of interest ()
Same username and logon as the Forums
Bonus: Visible download links to patches and other bug-related minutiae
I have used the Issue Tracking platform used in Betas, and the exposed featureset is too lacking to fulfill the spirit of this Idea
I realize the initial and ongoing investment for such a system is high compared to most Ideas on the Exchange. Both issue tracking and economics are sensitive issues, but the resultant increase in product stability and customer confidence makes the discussion worth having.
Just to clarify, a perfectly acceptable (and desirable) action is to choose an established issue-tracking service provider (perhaps one of NI's current web service providers carries an acceptable solution?), not create this behemoth in-house.
(Picture first spotted on Breakpoint)
Generally: you are voting for a platform that eases the burden of Issue Reporting, additionally offering a means of Issue Tracking.
My suggestions are neither concrete nor comprehensive: please voice further suggestions, requirements, or criticisms in the Comments Section!
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 ...
Currently LabVIEW only has support for Mandriva, RedHat and SUSE Linux. What's even worse, only 32-bit versions of those are supported. Today, 64-bit linux installations are on huge raise, and Ubuntu is getting more and more popular. LabVIEW Linux support should be expanded to include Ubuntu, and 64-bit versions are needed.
Within LabVIEW Build Specs you can specify a version for an executable that is built. You can presently see this from within the Windows add/remove program and there are some funky ways of getting this version with .net or WinAPI calls but you should be able to do this from LabVIEW similar to the app version as shown below.
This should also be within LabVIEW so that it can work from LabVIEW Real-Time as well.
Currently, if you want to install LabVIEW 64bit, you need to download it from ni.com.
My idea is to put it on the LabVIEW Platform DVDs.
It should be there. I am paying to get my software on a DVD. Please include it on my DVD.
The only reason I can think of for NOT putting it on the DVD, is that NI is worried that inexperienced users will install the 64 bit version (afterall, doesn't 64 sound bigger and better than 32! ), and NI will get tons of technical support phone-calls from the resulting confusion.
The title says it all - I'd like to have the option to inherit my configuration settings from the previous LabVIEW installation (or from a specified path). Currently I have to do this manually by copying the ini file from the previous version, but I'm never sure whether there will be compatibility issues with the new version of LabVIEW or if there are obsolete settings. The installer should check for compatibility/obsolescence issues as it creates the new ini file.
Alternatively / additionally, I'd like to be able to specify where LabVIEW loads the LabVIEW.ini file from (which could be located on a network or USB disk).
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 v22.214.171.124 depends on LabVIEW NXG v1.0. But the installer indicates the version of LabVIEW NXG to be installed is v 126.96.36.199152-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:
How many of them need "Delete Option" on Right Click Context Menu?
I feel providing an delete option in right clicking context menu for any Indicator or Control deleting will make developers easy and fast assessable and avoid too-much use of keyboard.
We use our left hand for control and Shift more offen but for pressing delete button which is at right top corner in keyboard, all of a sudden we will remove our right hand from mouse and press Del which is uncomfortable.
So, Developers share your point of view for the same and request to add Delete Option in upcoming version.
Later we will ask even Cut Copy Past... He! He! He!
I think it is useful if the installer automatically 'Force Re-install' if the same software has been already installed with the computer. This will omit the procedure to kick-start force re-installation via command prompt, some users may not be familiar with.
For all of us not running an english OS but want to install plain english versions of NI products:
Please give us an option or a documented method to install LabVIEW and MAX and driver, etc. in plain english.
While it is possible to install LabVIEW in ENG, the MAX and the driver installer lookup the OS language and install the localized versions 😞 (just tried with a new PC, W10 and LV2018 full dev suite, even set my language setting to ENG, however I have to install the localized W10) That is not helpfull if you want to look up the big commuinty help or knowledge base entries and can result in 'funny' error messages.
For the driver DVD I think I found a hack in the setup.ini
With Application Builder installers there is no way to flag a file as a 'shared' component in the build specification. This feature is used in MSI installation when files are shared or common among multiple product installers; for example, the files located in \National Instruments\Shared are common dependencies for NI products or in LabVIEW-built EXEs this could be a shared dependency between two applications, like a DLL. Currently, if two product installers built in Application Builder install the same file, when either of these products is later removed the shared dependency goes with it and the second product is broken!
Some good news is you can use MSI editors like InstallShield to edit the MSI after creating it with Application Builder in order to enable a tag/setting for your shared files:
There are also open source MSI editors available, like Inst Edit, with similar options for tagging files as shared components.
What can be done in Application Builder?
Could an option be added to 'Source File Settings' to tag files as 'Shared' so a third-party MSI editor is no longer necessary?
There have been several ideas proposed to alleviate accidentally savings vis in the wrong version of LabVIEW. While useful, I think the main problem is that LabVIEW doesn't use the information it reads from the file to preserve compatibility. I'd like to propose here that LabVIEW introduce compatibility modes for previous releases in which LabVIEW will break a VI if a feature is introduced that isn't supported by the compatibility version. It will essentially be a built-in, seamless "save for previous" mode.
By default, LabVIEW will load a VI (hierarchy) in a compatibility mode for whichever version is was saved in. If the user tries to make a change that isn't compatible, LabVIEW will alert the user and the user can tell LabVIEW whether it's ok to save to a newer version that supports the feature.
The level of alerts can be configurable, of course.
When you run the LabVIEW Platform DVD, the default setting is that LabVIEW gets installed and nothing else. You can then go pick and choose what modules and toolkits to install. I like this default because I usually only want to install LabVIEW and a few other modules and toolkits. It is faster for me to select the few modules that I want to install rather than unchecking all of the modules I don't want to install.
When you run the Device Drivers DVD, it tries to guess what drivers you want installed based on the software you already have installed. However, it usually wants to install more drivers than I want it to install. It is a hassle to go through the driver list and unclick the drivers I don't want to install because most of them have dependencies that you have to unclick first.
Idea: Their should be a button on the Device Drivers installation screen to unselect all of the drivers (see image below). I don't think the Device Drivers DVD default should be the same as the Platform DVD; a lot of new users won't know what drivers they need and installing all of the recommended drivers is a safe bet. However, many users do know what drivers they want and it saves time and hard drive space to only install the necessary drivers. Adding an "uncheck all" button would make this process faster and less frustrating.
Getting a value change event on a shared variables seems to me like something that ought to be expected "out of the box" in LabVIEW. Polling shared variables for changes is taxing on resources, and such an architecture is generally frowned upon by NI and the LabVIEW community for things like front panel interactions and the like. Why, then, should we expect to pay extra to deploy applications which such an architecture for interacting with shared variables?
I completely understand the extra license for the DSC run-time, as there are numerous other terrific tools included. It just seems to me that the SV value change events are one thing that should be freely available for deployment to everyone already paying for the application builder.
Hi, i wanted to suggest the creation of a separate utility software that would convert a VI from any version to any other version. This would save people a lot of time by not waiting to get it converted from their respective threads. Also it would serve for more people to able to reply on the forum(me included since i am using LabVIEW 8.6 and most of the posts contain VIs made in 2009 and 2010 even though most of the time the same functions are avalable in 8.6 😞 ).
I would like to include arguments for any/all shortcuts from the installer. Currently you can build a labview installer to put shortcuts on desktop and to the "Program Files" menu. But there is no option to include arguments. See attached image of how it would look in labview.
This would allow for the installer application to include file path arguments into any executable. Example: You want to include a tftp server application for the installer and embed the tftp path in the shortcut.
It could also be usefull to run the same labview app with many startup arguments. Like if you have a debug mode and normal mode. If you want to include both options on the desktop you could use a -debug as the argument. And include it in the shortcut from the installer. Both shortcuts would point to <application> but one would also say "<application> -debug"
Although new folders can be created in the application and installer build specifications, they are not created unless a file is put there. An empty folder is desireable for data output. It would be better for it to be created before running the application so that security access rights can be set by the person doing the installation if administration priveleges would otherwise be needed to create new files there. It leaves quite a bad impression on those who waste time finding out by trial and error that the folders defined in the build specifications are not created. The forum also documents complex schemes to work around this limitation by people who surely would rather have been doing something productive instead.