LabVIEW Idea Exchange

Post an idea

For distribution, only package necessary libraries in installer packages built with the project. A lightweight UI, server, or client does not need a full 70MB+ installer that bloats out to a few hundred MB's once installed! A colleague has remarked that the total size of our LabVIEW application+RTE EXCEEDS the entire size of the XPe image running on the embedded computer! This becomes an issue when distributing software upgrades to places in the world without high-speed internet connectivity.

View All (11)

NI updater kindly informed me that LabVIEW 2014 SP1 was released (even though I uninstalled it shortly after I tried it last year) and out of curiosity, I took a look at the known issues list.

I learned a few interesting things I did not know about, and also that some problems had been reported as long ago as version 7.1.1. This type of stuff looks like bugs that won't be fixed, ever.

For instance, CAR #48016 states that there is a type casting bug in the Formula Node. It was reported in version 8 and the suggested workaround it to use a MathScript Node instead of a Formula Node (where is the "Replace Formula Node by a MathScript Node" contextual menu item?).

Problem: the MathScript RT Module is required. Even in my Professional Development System, this is not included by default. Does this really count as a workaround?

I read: we don't have the resources to fix that bug, or we don't want to break code that expected that bug.

In any case, this bug with most likely never be fixed.

The bottom line is, we can waste a lot of time as users, rediscovering bugs that have been known for a while and will probably never be fixed. As a user, I would really appreciate a courteous warning from NI that there are known traps and have a complete description handily available with the help file related to the affected function.

My suggestion: add a list of known issues (with link to their description) for all objects, properties, functions. VIs, etc, in the corresponding entry in the Help File.

View All (1)

I search the idea forum and I see many Labview Upgrade suggestions as "DECLINED".

I know there are others out there like me, I HATE upgrading Labview. All the time required to update your custom configuration takes weeks. Heck, Labview upgrade isn't even smart enough to know all the software you're entitled to install...instead you have to force Labview to download and install your paid software individually.

Here's the deal, most of us don't have the time to upgrade because of all the maintenance we do to support our software. For instance, I have a paid Maintenance Agreement (as I do every year), I have been working in LV2015 and now it's time for me to upgrade my computer and I'm installing LV2018.

My wish, Have National instruments create a tool that would allow you to export all your custom settings, device drivers, and software requirements, etc..., so you could import these settings into a new version of LV. Making the upgrade process easier with a single tool.

Since it's so difficult to upgrade, I often wait 3 years or more before I try to upgrade. If it was more seamless to upgrade, I'd probably upgrade every release!

Anyway, we are all so busy we don't have the time to search these forums, so this request will be DECLINED too.

Perhaps NI should accumulate all of these requests to Upgrade and total them as one. Each individual request dies in a year because so many people are sticking with what works...often older versions of LV.

Sure, NI has a few upgrade tools, but, nothing that leaves you upgraded to the latest version of Labview without missing a step.

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

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!

NXG needs an Idea Exchange. The feedback button is a lame excuse for a replacement. Why?

I can't tell if my idea has been suggested before. (And maybe someone else's suggestion is BETTER and I want to sign onto it, instead.)
NI has to slog through bunches of similar feedback submissions to determine whether or not they are the same thing.
Many ideas start out as unfocused concepts that are honed razor sharp by the community.
This is an open loop feedback system.

Let's make an Idea Exchange for NXG!

View All (2)

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.

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.

View All (5)

View All (3)

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.

View All (7)

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

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.

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.

When installing a new version of LabVIEW, I always find myself resetting all of the options I previously changed from the default settings in the Tools -> Options menu. This means I have to spend my time remembering what options I changed and where in the Options menu I need to change them. It would be nice if a newer installation of LabVIEW looked at the older version's Options settings and then applied those settings to the new installation.

The same idea applies to how I configure the palettes on the block diagram. It would be nice if newer installations looked at how I configure my palettes and then set them up the same way.

With these changes transitioning to a newer version of LabVIEW might be even more seamless for users that change their settings from the default settings.

View All (5)

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.

View All (4)

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:

The issue reporting procedure is undocumented - few seem to know how to report issues, fewer know how to track documented issues
Issue tracking status is largely monitored by a squad of Dedicated Volunteer Bug Scrapers
Duplication of effort (for users, AE's, and R&D) is probable since there is not a centralized, searchable repository
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. 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:

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
Allow embedded video screen captures (such as Jing)
Allow uploaded files that demonstrate reproduceable issues
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)
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.
Allow collaborative involvement for adding content to Bug Reports, where any member can upload additional information (given they have Modify Access Level privileges)
The Homepage of the Issue Tracker should be accessible and visible through ni.com (maybe IDE too, such as a GSW link)
A more detailed Bugfix Report for each LabVIEW debut (cryptic subject lines on the current Bugfix List is not helpful)
Specific fields such as Related Bug Reports and Related Forum Posts that allow easily-identifiable cross-referencing.
An email-based alert system, letting you know when the status or content changes in bug reports of interest ()
Same username and logon as the Forums
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.

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

View All (14)

View All (1)

View All (5)

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

View All (1)

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

LabVIEW Idea Exchange

Segment the LabVIEW Run Time Engine (RTE) to ONLY Necessary Components

Include longstanding "known issues" in the help file

Upgrading Labview From Old to New Versions - Not Easy!

Have Post / Pre Build VI For Installers

Reduce Impact on the Environment

Rewrite MODBUS library

Warning when saving in LabVIEW later Version

Idea Exchange for NXG!

Uninstaller improvements

Fix font behavior between windows versions, platforms & executables

Add a native File Open event

Slim app builder

VI Migration Independent of LabVIEW Version

Developer Suite release names should be software year and service pack (e.g. 2009 SP1) instead of DVD shipment year (e.g. 2010 DSx)

New LabVIEW Installation Retains Options

All build-able targets should have versioning

HABF: A New Platform for Issue Tracking in LabVIEW IDE

Service Packs

Support for Ubuntu Linux

Improve that damn Licence manager!