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 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

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.

 

Savings:

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:

  • logically grouped
  • have descriptions
  • 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.

According to the increasing number of questions about this communication protocol, it would be time to rewrite the MODBUS library. I also suggest to add it to the NI device drivers installer.

 

This could be the place to list the expected modifications. Some comments and bugs are already listed in above linked page.

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.

 

 

force reinstallation.png

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.

 

 

EXE settings

EXE Builder Settings.png

 

 

Installer Settings

Installer Settings.png

 

 

Hi all,
For a lot of reasons, I have to work with several LabVIEW versions.

My biggest fear is to save something in a later version : projects are quite big, and a save for previous version is hard when using terce parts (such as OpenG, JKI, etc.)

My whish would be to have a warning message when I save a vi in a new version, such as :

"You are saving a 8.2 file in 11.0 : do you want to continue ?"

 

 

Have a nice day !

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:

 

 

Version 1.0

Version 2.0

VI Path

 

<userlib>\mytoolkit\CompRes.vi

<vilib>\mytoolkit\Compute Result.vi

Owning Library

 

none

Mytoolkit.lvlib

Connector Pane

 pane1.png  pane2.png

 

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 ...

 

Bob Schor

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.

 

How Can I Change the Hardware Used for Activation of NI Software? 

 

PS :

and now that we're talking about improving that damn licence manager, you can refactor it to include other ideas such as :

Smartphone application to activate NI Software

Add a QR Code (2D Bar Code) Option To NI Product Activation Dialog

 

[admin edit]

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.

When I build a web service in LabVIEW, there is no version number updated for each build.  If I then install that web service on my target, I have no way of determining what build has been installed.

I have solved this by creating some scripting VIs that update a VI control's default value when the build is run.  This VI is available via my web service so I can ask it what version it is.

 

I think everything that can be built from the project should have a version attached to it and that version should be accessble and reportable.  Also, it should be possible to auto-increment it.

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

[Localization] Languages=9,7,12,17,18,2052 #ForceLanguage = 9 CustomRes0009=SupportFiles\resourceEng.dll CustomRes0007=SupportFiles\resourceDeu.dll CustomRes0012=SupportFiles\resourceFra.dll CustomRes0017=SupportFiles\resourceJpn.dll CustomRes0018=SupportFiles\resourceKor.dll CustomRes2052=SupportFiles\resourceChs.dll StandardRes0007=SupportFiles\niresdeu.dll
...

by uncommenting the red part. But editing the setup.ini ??

OK, in this case the hint was there (or forgotten to remove :D)

The actual suite installer comes with a .xml  configuration file where that hint was missing or overseen.

 

I suggest something like:

 

Installer found local language version: <OsLang> ,

Install (where possible) in language: <ListOfSupportedLanguages>

 

That setting is hopefully stored for future automatic updates 😉

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 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

For modern application development we need better methods to detect wheter our application is called to open a file.

Currently the only help NI gives is based on command line parameters. And we need to jump through loops to get it working to react on opening a file when the program allready runs.

 

This is a major showstopper in creating professional applications.

 

LabVIEW 8.2 had a hidden event for getting this event, which unfortunatly doesn't work in later versions.

 

 

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.