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

HABF?

 

An acronym for one of my favorite Spolskyisms. Great article, read it.

 

Background

 

When you discover what you consider to be a bug in LabVIEW's IDE or language, it's a difficult process to report the bug and track the bug's status as new LabVIEW editions debut. This idea addresses the transparency and facilitation of this process, and is meant to appeal to both those who create LabVIEW and those who use LabVIEW.

 

Problems with Current Issue Tracking Platform

 

"Platform" is a generous term for the current reporting and tracking process:

 

  1. The issue reporting procedure is undocumented - few seem to know how to report issues, fewer know how to track documented issues
  2. Issue tracking status is largely monitored by a squad of Dedicated Volunteer Bug Scrapers
  3. Duplication of effort (for users, AE's, and R&D) is probable since there is not a centralized, searchable repository
  4. Relies on unreliable methods including email, FTP uploads, phone conversations, forums...

Comparing LabVIEW Issue Tracking and Feature Tracking Platforms

 

Before the Idea Exchange, there was the Product Suggestion Center (PSC). What's that, you ask? It's a hole in the internet you threw your good Ideas into. Smiley Very Happy The Idea Exchange revolutionized Feature Suggestions by introducing a platform that allows an unprecedented level of public brainstorming and symbiotic discussions between R&D and customers. Further, we can watch Ideas flow from inception to implementation.

 

I want to see an analogue for Issue Tracking.

 

Proposed Solution

 

A web-based platform with the following capabilities:

 

  1. Allows users to interactively search a known bug database. Knowing the status of a bug (not yet reported, pending fix for next release, already fixed in new release...) will minimize duplicated effort
  2. Allow embedded video screen captures (such as Jing)
  3. Allow uploaded files that demonstrate reproduceable issues
  4. Allow different "Access Levels" for different bug types. View and Modify permissions should be settable based on User ID, User Group, etc... (Some types of bugs should not be public)
  5. Allow different access levels for content within one bug report. For instance, a customer may want a bug report to be public and searchable, yet attach Private Access Level to proprietary uploads.
  6. Allow collaborative involvement for adding content to Bug Reports, where any member can upload additional information (given they have Modify Access Level privileges)
  7. The Homepage of the Issue Tracker should be accessible and visible through ni.com (maybe IDE too, such as a GSW link)
  8. A more detailed Bugfix Report for each LabVIEW debut (cryptic subject lines on the current Bugfix List is not helpful)
  9. Specific fields such as Related Bug Reports and Related Forum Posts that allow easily-identifiable cross-referencing.
  10. An email-based alert system, letting you know when the status or content changes in bug reports of interest (:thumbup1:)
  11. Same username and logon as the Forums
  12. Bonus: Visible download links to patches and other bug-related minutiae

 

Additional Thoughts

 

  • I have used the Issue Tracking platform used in Betas, and the exposed featureset is too lacking to fulfill the spirit of this Idea
  • I realize the initial and ongoing investment for such a system is high compared to most Ideas on the Exchange. Both issue tracking and economics are sensitive issues, but the resultant increase in product stability and customer confidence makes the discussion worth having.
  • Just to clarify, a perfectly acceptable (and desirable) action is to choose an established issue-tracking service provider (perhaps one of NI's current web service providers carries an acceptable solution?), not create this behemoth in-house.

 

BugFeature.png

(Picture first spotted on Breakpoint)

 

Generally: you are voting for a platform that eases the burden of Issue Reporting, additionally offering a means of Issue Tracking.

 

My suggestions are neither concrete nor comprehensive: please voice further suggestions, requirements, or criticisms in the Comments Section!

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

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.

 

appversion.JPG

 

This should also be within LabVIEW so that it can work from LabVIEW Real-Time as well.

If you install anything (anything!) from NI on a computer that runs windows 8 or newer, you will get bugged by a dialog to disable fast startup. The option is enabled by default, no matter what you install. It will popup with every single install, even minor patches, and even if this option has been intentionally unchecked in the original installation to be patched. If you don't want to disable fast startup, it is a never-ending whack-a-mole of these dialogs. (... but the need to disable fast startup for some scenarios is a more general problem that NI needs to address. It could be a new idea, but I think NI is aware of this problem. It might even be something that Microsoft could address such that devices don't get lost in the scenarios where fast startup causes problems)

 

This idea is centered around executables that we built and distribute via installers..

 

While this option (=disabling fast startup) can be useful when certain DAQ hardware is used, it makes absolutely no sense for other LabVIEW programs. Most of my programs don't use any DAQ hardware and it is not reasonable to globally cripple every single computer that has them installed. People tend to click [next] without reading, assuming that the defaults are typically reasonable.

 

Currently, this install query can be silenced by editing the setup.ini and changing the entry "WinFastStartup=1" to "WinFastStartup=0". I have built dozens of applications over the last few days and it is becoming seriously annoying to constantly remember to do that.

 

I suggest that the installer builder should get another checkbox that allows us to set that option permanently. Here is how it could look like.

 

 

  • Checking that box will give the current experience where the installer asks to disable fast startup. (it could even be checked by default to mimic the current default behavior)
  • Leaving the box unchecked will skip that dialog and will not disable fast startup.

 

IDEA SUMMARY: Allow us to configure the fast startup dialog from the installer builder tool.

 

 

For all of the work the knights of the forum do, I propose that upon retirement they receive a lifetime license to LabVIEW.

  1. They deserve it.
  2. Their help on the forums for other users cannot be quantified. 

Not sure where I read it on the forums, but I think it stinks that @Ben needs to wait until the community edition is released to have a working copy of LabVIEW.

 

mcduff

It would be very nice if we could tell the installer script to synchronize its version number with the version number of a specific executable.

 

12-29-2009 2-38-53 PM.png

 

Additionally, it would be very nice to have this version information (once they are synchronized) displayed on the installer wizard (for instance in the title window or on the wizard first page).

 

PJM

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.

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.

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.

 

Related ideas:

Version-aware LabVIEW launcher

Add header to LabVIEW file to contain the version of LabVIEW

Display VI version in title bar

Version independent Source Code Saves

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.

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

 

 

PS: Sorry, got no pictures

 

One example is shown below from the Device Driver Installation dialog but there a many similar cases. It is very difficult to obtain a decent overview having such a small window for the tree display.

 

I suggest as a general style guide to always enable the resize option in a dialog box whenever the layout requires a scroll box.

 

I have a hard time to see what could be reasons not to do so.

 

dialog resize.png

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! Smiley Happy), and NI will get tons of technical support phone-calls from the resulting confusion.

If you are going to call it a developer suite, put the developer tools in it. The following toolkits need to be added:

Of course this will increase the cost of the developer suite. I find it easier to convince my boss to approve a cost increase versus purchasing a new toolkit.

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

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:


InstallShield.png

 

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?

AppBuilder.png

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. 

 

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.

 

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)

 

Problem

Many times, the bulk of LabVIEW development happens on computers that will never interface with hardware. A dozen engineers may be collaborating on code that will ultimately run on a dedicated machine somewhere, that is connected. Yet, as things currently are, I have to install more than I need on my development machine to get access to API VIs. If I am working on my laptop on an application with DAQ, RF, Spectrum analyzer, etc. components, I have to choose to either download and install all of that, or deal with missing VIs and broken arrows. This seems needless, since my particular machine will never actually interface with the hardware.

 

Idea

I would like to have the option to install only the LabVIEW VIs and ignore the driver itself. In many, if not most cases, the LabVIEW API could be independent of driver version. It could install very quickly, since it would just be a set of essentially no-op VIs. I don't care that the VIs would do nothing. They would just be placeholders for my development purposes. This would allow me to have full API access to develop my code without having to carry around large driver installations that I will never actually use.