LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

I suggest that NI clearly mark those functions in IMAQ that require a run-time license.  Perhaps color their icons pink or some noticeable color.  There is a lot of misinformation in NI technical support regarding this issue.  I wasted a lot of time developing an IMAQ program and found out later that it required a run-time license that my client did not want to buy.  So, I had to rework the code to eliminate those functions that require a run-time license.

 

admin note: Invalid link has been removed.

 

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.

Installer needs option to conditionally install files.
In some installs, like a new install, the installer should install a file but that same file should not be overwriten on an update. For example, a database file that is updated by the user will be overwriten by the installer.
The options required are:

  • Install file if not present.
  • Install file or not install if file is modified. 

InstallShield should be consulted for the various options required.

Provide an option to display a QR (2-D) code in the product activation dialog.  The QR code should contain a web address that would return the activation codes for all selected products.  For those of us stuck out in a lab or factory with only our smart phones this would provide a slick, foolproof way to enter all of the data needed.  It would save us from either making a round trip back to civilization (with a pad full of info) or getting carpal-tunnel trying to type all that stuff in on a little soft keyboard (multiple times for multiple activations = hand cramp).  We would still have to type the resulting activation codes into the LabVIEW activation screen but that's a lot easier than all the rest.

 

Idea details:

1) Provide a http link as a QR code 

ExampleNIActivateQRcode.png

2) Have the target web page auto-generate the activation codes and display them (preferably in a mobile browser friendly format)

3) As an alternative, let the user upload a picture with the QR code to the NI activation web site for the same result (works for anyone with a camera not just smartphone users -- this would also let you show off IMAQ.)

4) Profit

 

(And, once you have the QR-code generation code available, add a VI for it to LabVIEW -- see http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Generate-Barcodes-in-LabVIEW/idi-p/1283912)

 

Whenever I install a new version of LabVIEW, I have to wade through the LabVIEW options to change all of the UI settings to what I like. To make the upgrade process easier, I would like to see a dialog that:

 

  • appears on the first launch of the new LabVIEW version
  • can be easily skipped by users who would rather configure things manually
  • allows users to choose common settings (aimed at users without another version of LabVIEW on the machine)

    1.png

  • provides a user friendly way to import settings from an older LabVIEW version (aimed at users who are upgrading LabVIEW)

    2.png

This would make the process of upgrading much easier, especially for users who have very particular preferences. Some options that could be addressed in the wizard are:

 

  • control style (icon or not)
  • visible palletes
  • showing text for VIs on pallete
  • broken wire Xs
  • etc...

 

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

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.

When you install LabVIEW and MAX configuration support for DAQmx (and other components are the same) the NI Package Manager adds a number of other LabVIEW runtime versions to the list of dependencies.

When I install support for LabVIEW 2019, the package manager add LabVIEW 2014 and 2018 runtimes.

 

Surely this can be tidied up!  Please tidy up dependencies.

 

If I only have LabVIEW 2019 installed on my system, I shouldn't need the LabVIEW 2014 and 2018 runtimes to make a 2019 component work.

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

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 if you commit to installing the full NI Developer's suite and something goes wrong with the installation you can forget about using the Windows Restore feature because the installation process creates a new Restore point about every 1-3 minutes.  That is unnecessary and problematic for a number of very obvious reasons.

 

Untitled picture2.png

Does this idea need any more explanation? If someone swipes the box out of a mail slot at work and installs it at home, that becomes the "at home" installation. 

 

I realize Ideas with pictures do better, so here's a Golden Retriever puppy...

 

 

Message Edited by Broken Arrow on 06-11-2010 07:40 AM

If I'm the first to post this Idea then I'll be shocked.

The Idea is simple. We all love programming in LabVIEW, and I'm sure that we've all at one time or another had a colleague, friend or family member ask if we know how to do something on the PC. The immediate thought is I don't know where to get the software to do that, but I could write a simple LabVIEW app  in a few hours that does the job.

E.G hunt through someone's PC and move all of the jpg files over a certain size to a specific location so they can easily find their holiday snaps.

 

You can't create this simple function for them, because if you do, and build an exe, they still need the Runtime engine.

 

Surely for REALLY simple stuff (File IO, basic comms stuff in the Base LabVIEW edition ...) - not DAQ or anything like that it is possible to create an EXE that INCLUDES the runtime components that it needs and is stand alone.

 

This would open up LabVIEW for the use of making quick gadget like apps for the office as well as test and measurement.

 

I can't se how this could be a bad thing.

Currently, the version of the packed project library (PPL, extension .lvlibp) is defined by the build script which creates the lvlibp.

It would be nice to have an option there to "hook" the version of the lvlibp to the version of the lvlib, which is used for the PPL.

 

Build Settings Version.PNG

 

The advantage is to match the developement version of the lvlib to the deployed version, the PPL.

The Vision Utilities are currently installed with either the Vision Acquisition Software, Vision Development Module, or NI-IMAQ.  Since NI-IMAQ is a free download that anyone can install and deploy without any additional licensing it makes sense to include it in the LabVIEW installer.

 

The Vision Utilities provide superior image management , are owned by NI-Vision (meaning they are actively developed), and best of all are free.  Including the Vision Utilities in the LabVIEW installation will expand their exposure and use.  Below you'll see the first three results returned when one seraches for IMAQ on ni.com and sorts by examples.  In addition to the examples shown below you can find a list of all the VIs currently included for free in NI-IMAQ here.

 

Region of Interest Spotlighting With IMAQ Functions                

Spotlight front panel.png 

 

Semitransparent IMAQ Overlay

Front Panel.png

 

IMAQ Skew Image

skewimage.png

There is a logical glitch in the App.Version property; If you read App.Name you get the name of the built application...but if you read App.Version it's not the version of the application - it's the version of the RTE.

 

I use the application version in splash screens etc. - however today I have to manually write this multiple places because I cannot read the version number I used when building the application.

 

 

 

Activating an NI Software licence on a computer without internet access works fine but take too long and is user mistake prone because we need to type long strings of characters.

 

Now we have to :

 - go on PC/tablet/smartphone that has internet access

 - go to ni.com/activate,

 - select the product type,

 

 - select the product version (be carefull to select the version we installed, not the version we recieved*),

 - type the serial number,

 - type the computer ID,

 - then we obtain the activation code that we have to type on the computer.

 

Bold steps are human-error prone.

 

If you've done that once from a smartphone, you know how painfull and error prone this process is.

This process should be shorter and much less error prone, something like :

 - the PC without internet show a QR-code that contains product type, version needed and computer ID,

 - launch the "NI Soft Activation" app on your smartphone

 - scan the QR-code

 - type the activation code given by the app onto the computer.

 

Only one human-error prone step in that process.

 

 

 

* : when you purchase a runtime licence from NI you automatically recieve a serial number that can activate the most recent version of the product, but you can use it to activate older versions of the product as well. Say youwant to activate Vision Development Module RTE 2010 but you recieved a serial number valid for up to version 2012, when you go to the ni.com/activate you have to be carefull to select the correct product version (2010 in this case), one more possible human mistake.

With LV comes a decent icon editor. It's the one that starts when you look at Build Application settings -> Icon -> Icon editor.

This seems to be the only way to start this program, there's no entry for it in the Programs Menu.

So what i've done is to create a shortcut to iconedit.exe and add it to my Programs Menu, and i feel this should be part of any and all LV installations!

 

So: Add an icon to Lv's Icon Editor as part of the installation.

 

/Y

 

This is not directly related to LabVIEW but I haven't found any other thread which seems like a better fit. I'm posting it on the Idea Exchange since this is the best place for other customers to potentially agree with me.

 

NI drivers/software are quite often large, and above 1 GB is not uncommon and sometimes above 3 GB. Having everything in a single file is in my opinion a good thing because I don't have to look for multiple driver parts and download packages, but the file size must be matched by the download speed. Waiting three-four hours or more to download a single driver is not a fun thing to do and quite often you need more than one driver.

 

Sometimes the speed is okay, but as a general rule I would say it's slow. I'm located in Sweden and of course this issue is dependent on a lot of links between where I am located and the server where NI host the files.

But, download speeds of 200-300 KByte/s from NI are not uncommon but I can run speedtests on for example http://www.speedtest.net/ and get download speeds at 50Mbps using American servers.

 

I don't know how NI host the files, if it's internal servers or something else but it would be nice if NI looked into the possibility of somehow making this faster.

 

This idea is about a new LabVIEW feature, the Packed Project Library.

 

To statically use a packed library as a dependency, you need to add the library to the LabVIEW project.  After that's done, all the callers link to the packed library.  If you're strictly a library user, then whenever you need a library update you simply ask the developer for one.

 

But what happens if you're a packed library user and developer of the same library.  You can't use a packed library as a static dependency until you build it and replace the lvlib with the lvlibp...but you can't develop the packed library after it's been built and replaced in the project.

 

If you're a user and developer, it makes sense (to me) to maintain two separate projects.  One manages the packed library resource, one manages the application.

 

What if there were a way to revert the packed library to the LabVIEW library from the same project?  You could use the spiral development model and simply switch between the two types of libraries during development.  You could also (and this IMHO is the most important part) incrementally deploy and test the project.  If you're strictly a packed library developer, hopefully you're incrementally testing anyway.

 

My final pain point with the packed library is with respect to upgrading the application.  Similar to above, if you're strictly a user, you pray the developer is still in business and ask nicely for an upgrade.  If you're a user and developer, and you didn't maintain two projects, you might think to replace each static packed library subVI in the application with the original source and then rebuild the lvlibp.  Or you might think to create a new project that includes the lvlib and rebuild the lvlibp yourself.  I haven't tried it, but I hope that you can replace the original lvlibp with the lvlibp from a new project (not the one that created the original lvlibp).

 

This leads me to a best-practice for lvlibp: always use them as dynamic dependencies.  That way, you can maintain and develop the packed library in the same project that uses the packed library.  You'll simply reference the resources differently.

 

Even if you don't kudo this idea, I'm very interested to hear your feedback and experiences with the lvlibp.

 

Thanks!

 

Steve