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!
I am a big fan of LabView! This idea is meant to be a positive suggestion, and I hope it will be taken as such.
I almost wish this post was in jest; it is not. This is a serious suggestion that, in my opinion would improve the NI LabView program, save cost, and be much better for the environment.
I recently purchased Application Builder for LabView (both Great products). I received my Application Builder via FedEx. It comes in a very nice looking heavy mailing package with the bold label "NI LabVIEW 2010 Add-On Software. I think there must have been a FedEx overwrap with the following forms:
-Printed shipping manager page with the FedEx Bar Code
-Printed packing Pick Slip (two pages) with a certificate of conformance on page 1 of 2 and a signed page 2 of 2 by the Vice President of Quality and Continuous Improvement (I am not making this up)
Now, inside of the envelope is
-The standard folded yellow installation instruction page
-A certificate of ownership! (same serial number as is printed on the outside of the heavy mailing envelope)
-A card which says (really!) "Where is my Media?" The card says: "In an effort to reduce the impact on the environment, National Instruments no longer ships media with these kits.
Now, I assume by this point everyone sees the irony here, and where I am going with this New Idea for LabView!
IDEA: Upon successful purchase and proper payment of a LabView Add-On Software package: Email the serial number to the authorized user.
Optionally (if required by legal), send the paper Certificate of Ownership (one page!) to the authorized user, or if allowed by legal, Email a PDF of the Certificate of Ownership to the authorized user.
Beautiful outer envelope and stack of printed pages made in Ireland - Well, not needed (Give them other work, I don't want to see lost jobs)
Shipping cost and impact on the environment (Ireland to Austin) SAVED
Storage cost and space at NI Austin SAVED
Shipping cost and Air Freight Austin to end user SAVED (less jet fuel impact on the environment)
Less paper to be recycled by end user SAVED, positive impact on less energy needed for recycling!
Make it easier to find the right product in the uninstaller
If you install a lot of National Instruments developer tools the uninstaller becomes very crowded. You can have 50-100 components, often with similar names and varying name structure. Finding the component you want to uninstall/modify/repair can be difficult.
The fact that things a split into so many separate components is practical, but the components should be organized better:
They could be:
there could be a search/filter function available (that accepts wildcards)
Allow us to specify a new source location
If I want to repair or modify an installation it might turn out that the original source for the installation is gone, or I have a new (identical/compatible) source that I would like to use instead. It would be nice if the uninstaller handled this, instead of insisting on the original.
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 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.
If someone would have asked if there was a setting to run a VI after an installer was build I would have said yes, until today when I realized I needed it and couldn't find it. When building an EXE there is a Pre/Post Build Actions section where you can specify a VI to be ran before the build or after it. But this appears to be limited to building EXEs and not installers. There are several limitations to the NI building process, and I'd like to improve them by having functions get ran after a build of an installer is complete.
With the increasing size of the LabVIEW ecosystem, there is a growing number of third party tools written in LabVIEW that are versioned independently from LabVIEW's version number. For example, I could create an API that has versions 1.0, 2.0, and 3.0, and all three versions could be compatible with LabVIEW 2009 or later. Tools like VI Package Manager make it easy for content creators to publish multiple versions of an API, and for users to upgrade and downgrade between those versions. However, this ease of use disappears if significant changes have been made to the VIs in an API, such as:
Changing VI connector panes
Renaming or moving VIs on disk
Adding VIs to a library
If any of the above changes are made to VIs in an API between versions, it can become impossible to migrate code between the two versions without a lot of manual searching, replacing, and relinking.
LabVIEW should provide a mechanism to define mappings between old and new versions of third party toolkit VIs. Consider the case where I make the following changes to a VI from my toolkit:
I should be able to create a mapping file included with version 2.0 of the toolkit that describes the changes made between versions 1.0 and 2.0 of the VI. This way someone could write an application that calls version 1.0 of the VI, then upgrade their toolkit to version 2.0, and the application source code would be able to find, load, and relink version 2.0 of the VI without any hassle.
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 ...
As you can read in the link below the licence manager uses the MAC addresses of a computer to create computer ID used for the activation process.
The trouble is that when you use a NI PCIe 8235 (Quad-Port GigE Vision Frame Grabber) you are adding 4 Ethernet ports to you computer and any change to any of these ports (even a fix IP change of one of the ports) will change the computer ID and therefore you will need to re-activate all your NI products... As day to day users we simply cannot work that way.
The knowledge base article below explains that in such cases we can get the hard drive serial number, send it to NI and they'll give us a computer ID based on that HDD serial instead of the computer ID given by the licence manager and we can then use it for the activation process.
The point of this idea is to ask NI to improve the licence manager so we don't have to go through this issues, I think the licence manager should inform the user about what the computer ID is based on and tell him about the options (MAC address or HDD serial) and let him choose between the 2.
I am copying the workaround posted by crossrulz in the comments to benefit users having these issues who find this idea: "Here is a work around if you want to play around in the Windows registry:
In "Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\National Instruments\License Manager" add a string value named "DiskOnly" and set it to "true". The license manager will now only use the HDD serial number."
All service packs should be useable for the version you own, regardless of your SSP status. Currently, service packs are only good if you have a SSP active or had enough forethought to buy it in the middle of the year between versions.
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.
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
Dealing with fonts in LabVIEW can be a nightmare due to the variations in fonts, types of fonts, rendering variations, resizing, etc. If you are deploying a LabVIEW application on another machine, frequently the fonts or settings on the target machine don't match; creating a very ugly looking panel.
When developing for Windows in the past I have always edited my LabVIEW.ini file to include the following:
appFont="MS Sans Serif" 13 dialogFont="MS Sans Serif" 13 systemFont="MS Sans Serif" 13
And when deploying an application; I include these in the app's ini file also.
This seems to work for most windows targets since MS Sans Serif appears to be a common font. I suspect this will produce unpredictable results in OSX or Vista for that matter.
What I expect as a developer is not having to deal with these font issues. I expect that when I develop an application that it has the same look and functionality; regardless of where it is deployed; even as a VI being edited on another machine with different font settings. This means that the font information must be encoded and stored with the VI itself. I would expect that both the LabVIEW editor and run-time engine would be able to recognize detailed font encoding within the VI and adjust the display accordingly based on the local machines font capabilities. This is what one expects when printing or viewing an Adobe Acrobat PDF file; and the behavior of LabVIEW code; particularly since it is so graphical in nature; should also be similar. I wouldn't expect that the actual font bitmaps be stored within the VI itself; but some detailed metrics about the font should be; height, width, kerning, etc. Thus if a font substitution takes place when being deployed on another machine; at least the text will occupy the exact same extents as the original.
Though I don't know exactly what the detailed implementation would be; it does need to be transparent to the LabVIEW programmer, i.e. zero code; zero hassle; zero worries. It should just work. I hope we can all agree on this.
One thing prevent our company to upgrade to newer labview is that the run-time engine gets too big. Even I really like the features in later version, I still have to save the files back to 7.1 then to 7.0 to build application installer. Under 7.0, the run-time engine is very small, and the installer is less than 10MB and I can easily email the program to customers. In version 8.0, the run-time engine is 65MB and now the latest version is well above 100MB.
What I would like to see is that application builder get smart, only pick what is needed and build slim app.
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 v220.127.116.11 depends on LabVIEW NXG v1.0. But the installer indicates the version of LabVIEW NXG to be installed is v 18.104.22.168152-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:
When the Developer Suite DVD binder arrives, the first thing I do is find a black Sharpie, cross out the name (e.g. 2010) on the binder label, and write the version of the software it contains (e.g. 2009 SP1).
Rarely if ever do I care which year the DVD binder shipped to me -- all I care about is the version of the software (the most important being LabVIEW) it contains.
Now that LabVIEW and most other NI software products are on an annual release cycle and named according to the year and service pack, I would love it if the Dev Suite binders were named the same way.