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!
It would be helpful to have Refresh Palettes operation as part of the built-in Command Line Operations. This would help fill in the NI Package's short coming of not having palette tools like VI Package Manager. My suggestion is the Operation Name to be RefreshPalettes and require any additional arguments.
It would help to have an option to ignore Bad VIs errors when calling a mass compile via LabVIEWCLI. This makes the CLI MassCompile unusable for deploying code with NI Package Manager that has API Tree VI. It would help to have an option to ignore those errors so that NI Package custom execute could run successfully. I would think it could be defined as optional argument. My suggestion for the argument is -IgnoreBadVIs true|false with a default of false.
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.
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.
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.
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).
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!
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.
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.
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.
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.
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"