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

 

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.

 

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.

 

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

 

Consider expanding programmatic modification of the Build Process.  There is already an Idea here to allow the Pre-Build Action to set the Version Specification before the Build Process (it happens during the Build process, after the before-the-change Version Specification has been cached and used in the Build).  However, other Specifications in the Build Spec would be very useful to be able to specify in a (true) Pre-Build Action.

  • Target Filename (low priority)
  • Destination Directory (I like to put Builds in Public Documents, but the Public Document folder can "move", though LabVIEW's Get System Directory can find it, so I could "pre-build" a path specific to the given PC)
  • Build Specification Description (allows the user to include version-specific or Build-Time text)
  • Version Information (in addition to Version Number, before being used, the other Fields might be useful).

I've noticed references on the Web to automated Builds, and know there are Build VIs that will do a Build.  I also know there are a set of "barely-documented" APIs that some have used for this purpose, but I don't know (other than the Set Version Specification, which doesn't work as I expected in a Pre-Build Action) of others.  I don't especially want to poke around inside the Project's XML file -- can we consider adding some other "Pre-Build" Set functions?  Could (for example) some of these "Build Properties" be set with a Property Node?  Maybe this functionality is already there and I've not found it ...

 

Bob Schor

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)

 

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

This is in addition to New LabVIEW Installation Retains Options

 

During LabVIEW installation if it detects a previous version of LabVIEW has been installed it should present the user with the option (or have a flag when running the installation to allow this to be done silently) to import all VIs which are not installed by default that are present in the following folders:

  • vi.lib (VI Package Manager installs packages to this location by default)
  • instr.lib
  • user.lib

Upon importing the VIs to the new LabVIEW installation it should also mass compile them to the new LabVIEW version so the user is not faced with having to save loads of VI dependencies each time the user opens a VI which uses them.

 

This would make the getting started with the new version of LabVIEW a lot more seamless when just upgrading from a previous version.

Incorporate NI Batch Installer Builder into the general application builder suite.

 

This tool has a lot of potential for end-user use if it is incorporated into the app builder API and suite.  Batch installers can be used for much more than just installing selected sets of NI software (Which this tool is obviously designed specifically to do).  It could be used for creating installers of multiple, cross-project user installers comprising a complete system.  To do this though, the current batch installer builder needs to be made more generic to be of use.

 

Specifically:

 

  • Add configuration options to control or disable license dialogs when non-NI provided installers are added
  • Add configuration options to control or disable the user/company license dialogs when non-NI provided installers are added
  • Add configuration options to control or disable the check for NI updates dialogs when non-NI provided installers are added
  • Add batch installer version properties to allow end users to create system versions
  • Add support for 3rd party installer inclusion (Dup from another idea, but I had to repeat it here)

Including this in the app builder would be even better since that should allow project based configuration and control of the batch configurations and potentially even programmatic control.

Currently I use LabView through a Windows VirtualBox on a Linux Mint machine. I was told by a customer support employee that I should bring this idea to this forum. I chose this method because of the limited support for Linux even with the supported distro discs. I encourage NI to expand their Linux-compatible software to have the full capabilities that the Windows and Mac versions do for the distros that are currently out, and to expand the number of distros supported. Linux Mint is one of the most widely used flavors, and yet there is no support from NI.

All the other Build Specification has already this function available. Why not the Installer and the ZIP File.

 

Dany

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.

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.

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

Just found out MathScript Module does not have a 64-bit version yet. I don't know if NI has any timetable to release its 64bit version?

 

Why do I need a 64bit version? Mainly the memory issue. I have a Matlab code which requires a massive memory allocation. Now I am trying to use the .m code in LabVIEW, but encountered a 'Not Enough Memory' warning message. I think a 64bit version shuold fix this issue, correct?

 

Besides, 64bit is the future anyway. So in case MathScript Module 64 bit is not even being considered by NI, I would like to suggest it here.

When I run the installer for my application, I want to display to the user the version of the exe that will be installed.  Since this exe already exists, I should be able to embed a tag in the installer dialog text as a placeholder for this version.  Something like:

 

This installer will install version %my_exe_version% on your machine.

 

When the installer is built, the tags are replaced with the actual versions.

This should also work for all components being installed (DLLs, web services, etc)

 

As a bonus, it would be nice to have access to user defined tags in the build spec that can be embedded into installer dialogs.  Perhaps allowing a prerun VI to populate these so we can invent new ways of adding infomation in the future.  (like accessing user information from the OS and using that to customize the dialogs)

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.

 

 

 

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