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

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

Could it be possible for LabVIEW (even if only for versions 202{1,2,3} onwards etc) to make an attempt to open newer files and just break them when new features are used?

 

The comments in this Idea (LabVIEW Compatibility Modes) suggest this and related ideas, but it isn't the main part of that idea, so I'm posting it separately here.

 

An ideal solution for me would be for VIs to automatically save back in the 'oldest' version that they would support (and perhaps not be 'up-compiled' on load), but this idea has been discussed a few times and doesn't appear to be something NI will support.

 

An alternative (perhaps only possible in currently unreleased versions?) might be to have LabVIEW 202x try and open a VI saved in 202<x+n>, and then give the symbol for missing VIs (ideally with the name, if possible) for anything that isn't supported.

 

As an example, trying to open a VI using Insert into Map (if this were available for existing LabVIEW versions) in LabVIEW 2018 could produce something like

cbutcher_0-1596430804139.png

with the Context Help giving me a clue as to what was lost - I could then Google "Insert into Map LabVIEW" and try guess how I might replace it (here, probably with Variant Attributes).

 

I'm posting this idea in relation to some comments I've recently heard regarding sharing and packaging code with LabVIEW, and how even when other (text) languages add new features and so code using them will fail to compile, their users/developers can still open the code, try fix bits, or generally workaround issues (and evaluate the benefits of upgrading, if the changes are large).

New versions of LabVIEW continue to have significant new features, so upgrading seems like it will continue to be at least my preference, but not everyone has the same requirements/situation/SSP/blah blah blah.

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!

This is not directly a LabVIEW idea, but it is still an idea that impacts many LabVIEW programmers.

 

To keep my distribution small, I distribute my installers without run-time engine and instruct the users to download and install the relevant run-time engine. I provide a link to the run-time download page.

 

Note that these users are NOT NI customers and not interested in any NI products. They are my customers (well, my programs are free) and are only interested getting my programs to work on their PC. They don't even care what was used to develop the program. There is no extra hardware involved. If they already use NI hardware, chances are they already have a profile.

 

My users don't need a NI profile and don't need the follow-up phone call or e-mail from NI, etc.

 

Typical phone exchange yesterday:

 

me: "just click my installer and install the program"

him: "OK, done."

me: "now run it."

him: "OK, ...... error about 2013 run-time engine".

me: "OK, install the run-time engine using the link I sent you in the same e-mail".

him: "clicking the link to go to the run time engine page....

        (..30 second discussion to decide between downloader and direct download...)"

him: "click..(wait for it!)... .it wants me to register..."

me: "OK, let's forget about that. come down to the lab and I will do it for you."

 

End result: more delays (it was late Friday and I was ready to leave), more work for me, more hassle.

 

While gazillions (:D) of registered users sounds good on paper for NI, these are false numbers because many profiles are one-time use and quickly forgotten.

 

I think downloading a run-time engine should NOT require a NI profile. Maybe it should still offer to log in or create a profile, but there should also be a bail-out option similar to "[] I don't want to register at this time, just download the run-time!".

 

 

Note that even better long term solutions have been proposed, but this idea could be implemented quickly and does not even need to involve any LabVIEW developers. 😄

It has come up in discusssions that NI does not really cater to hobbyists. A cheap and functional version of LabVIEW is limited to the student edition, which is restricted to a small subset of potential users.

 

 From the  FAQ:


"The LabVIEW Student Edition is available to students, faculty, and staff for personal educational use only. It is not intended for research or institutional use."

 

As a suggested first step, I suggest to remove the academia restriction and mold it into a new product:

 

--- LabVIEW personal edition ---

 

Licensed as follows:

"The LabVIEW Personal Edition is for personal use only. It is not intended for commercial, research or institutional use."

 

 It would be available to anyone for noncommercial home use.

 

LabVIEW currently has the home use exemption that allows installing a copy at home. Unfortunately, if you lose your job, you not only lose your health insurance, but you also lose access to LabVIEW, thus hampering any self paced LabVIEW tinkering that possibly would improve future job prospects. I am sure many retired LabVIEW engineers would love some recreational LabVIEW use. They could be a great asset, because they will have more time helping out in the community and forums. They could even give guest presentations at user group meetings, for example.

 

The LabVIEW personal edition should include all modules of interest to the hobbyist, including application builder, embedded, FPGA, and robotics.  We should be able to distribute built applications as freeware. Support would be limited to community support.

 

Installing LabVIEW on every single private home computer in the world would cost NI exactly nothing (except for some sales of the current student edition which is about the price of a textbook, some internet bandwidth, and loss of the zero to two (?) multi-millionaires who actually bought the NI developer suite for themselves. ;)). 99.9% of users would never touch it, but that 0.1% could come up with great new application areas and would help spread the word on how great LabVIEW really is. Soon 0.2% would use it. 🙂

 

It should follow the "customer class limited" Freemium model, (as defined by Chris Anderson), i.e. limited to personal home use in this case.

 

The running applications should be clearly identified to prevent commercial use. The splash screen and "about" screen should prominently display the words LabVIEW and National Instruments and could even be used for NI advertising and product placements, for example.

 

 

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.

Currently in LabVIEW if you build an installer you end up with a hierarchy of files that look like this:

 

singlefile1.png

 

If you want to distribute this installer via the web, you need to use a third party program to zip it up, or create a self-extracting zip file.  Since LabVIEW can already create zip files with no problem, I propose the ability for LabVIEW to create a single file installer that can easily be distributed, like this:

 

singlefile2.png

 

This can be as easy as a checkbox in the current installer Advanced page:

 

singlefile3.png

NI send us the NI Developer Suite each year on DVDs all packed in a nice little NI branded dvd carry case. We are on the SSP suscription and we receive 3/years, which means I have a whole stack of them.

 

I suggest that NI start shipping USB keys instead. USB has several advantages:

 

  • USBs are smaller
  • USBs are more usable on devices without DVD player
  • Installing with one large USB means no more DVD swapping. I can go to lunch while NI installs/updates without having to change the DVD every couple of minutes.
  • USBs are reusable: when you get a new version on LabVIEW on a new USB, you can use the old one for regular usage. This also means less waste, since the USB keys are still in use after a new version ships, but the DVDs are useless.

 

Ship developer suite on NI USB keys

Yup,  Upgrading LabVIEW versions takes a day.

 

The "Process" today is:

  • Install from media
  • Configure the new LabVIEW.ini
  • install tookits (OpenG, Deploy, VIPM, TSVNtk.....)
  • Mass Compile all them......
  • Fix palatte views... and import and mass compile User.lib\ for here.....
  • Sync glyphs on the icon editor (If the link works......)
  • Add VIT's
  • Add Project Templates
  • Mass compileVIt's and Templates
  • fix "Metadata.xml"...

.

.

Yup, about a day of watching paint dry...........mass compiling, ignoring warnings etc......

"MyLabVIEW" would find all of those customizations and import them to the new version!

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.

 

Problem

When creating an installer for my built LabVIEW application, I really dislike having to choose between including the RTE installer (and having a 100+ MB installer for my application) or not including it (and requiring my users to download and install the RTE as a separate step).  Typically, I'll build two installers at the same time (with roughly duplicate build settings): a full installer w/ RTE and a light installer w/out the RTE.

 

Proposed Solution

What would be much nicer would be if my app's installer were able to download and install the RTE, if necesary.  Actually, this is common practice, these days, for users to download a small installer that then downloads larger installer files behind the scenes.

When creating an installer for a built LabVIEW application, it is very difficult (see here) to include an additional 3rd party installer (such as a device driver or application that your built application depends upon).  What I'd like to see is a solution that treats 3rd party installers as first class citizens.  I'm imagining a new "Additional 3rd Party Installers" page of the Installer build specification properties dialog.

 

2-3-2010 1-35-27 PM.png

 

This page might look something like the one in the screenshot below, allowing users to add a folder that contains the 3rd party installer files and define a command that is run inside that folder during the install process.

 

2-3-2010 1-41-08 PM.png

 

When LabVIEW builds the installer, it would suck the additional installer folders into the main installer and, after installing your app files and the additional NI installers, it would sequencially extract your additional 3rd party installers into a temp folder and then execute the command line to run.  This is a pretty simple scheme that would really simplify the process for end users.

 

I'm sure I didn't address every issue of this use case, so please, everyone, feel free to add your own ideas.  I'd love to hear your comments.

The list of available LabVIEW modules and device drivers is very long. Their names tend to be long too, which is compounded by the many levels of nesting. Modern screens are large.

 

Given all that, why are we selecting software components by scrolling around a tiny window which can't be expanded?

 

tinyinstaller.png

(Note: most of the trees above aren't exen opened yet!)

 

 

Proposal: Make the window bigger (vertically and horizontally), or resizeable, or both.

 

Thanks for listening!

This suggestion has been made before twice, in 2010 and 2011, in a more or less similar manner, and declined both times, but in light of the recent announcement of LabVIEW Community Edition I thought it might be worth a 3rd shot, so here it is with my own rationale for it (originally posted here).

 

Consider eventually also making available an (also free) "Core" edition of LabVIEW coupled with a much-reduced-in-size "LabVIEW Core Runtime", with everything hardware- and advanced-math-related removed, but allowing for commercial and academic usage.

 

There would be many benefits in doing so:

 

  1. It'd would allow LabVIEW to develop more into general purpose language, suitable for developing generic cross-platform desktop and web applications;
  2. It'd bring all manners of new developers from outside the very specialized field of industrial applications;
  3. These non-industrially-focused developer would develop new libraries and open source packages that'd expand LabVIEW's capabilities in all manners of directions;
  4. And then all these elements -- 3rd party "for core" tools, new developers, new ideas -- would provide a boost to the industrial-related versions, which would become the natural upgrade paths.

Doing this might risk losing a few sales of paid-for versions, and it'd also incur in costs as NI would have to decouple many things, which would require lots of engineering hours to do. But I believe long term it'd boost LabVIEW's usage in significant ways, and result into even more sales down the line.

 

Typical usage progressions would become something like this:

 

  • Core → Community → Base → Full → Pro → Pro + add-ons → Suite(s)
  • Core → Core + (new, paid for) Advanced Math and similar core-focused add-ons → etc.
  • Core for entry level generic programming classes → Academic licenses for classes focused on industrial applications → Academic licenses for actual research

And so on and so forth.

 

Please consider it, okay? 🙂

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.

 

 

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.

<bakground>So i just had a silly thing happen to me, i compiled a program and deployed it to the target computer, just like i did yesterday. Then it started complaining about a missing LV 2017 Runtime ... How? Why?

I reinstalled, repaired and it didn't help, both program and RT, several times and it didn't help.

I tested another program which started just fine, so what's missing? Is it some sub-package that my custom RT-installer didn't include?

I called NI and the support technician couldn't see anything wrong either, so with him on the phone i went to the development computer to look at some installer settings he had dug up. That's when i noticed i was in LV2017 64 bit! The messages said nothing about that! </background>

 

Suggestion:

Improve error messaging when missing RunTime. Include the bitness that's missing, now it only said "Missing LabVIEW RunTime 2017", if it had said "Missing LabVIEW RunTime 2017 (64 bit)" i would have reacted and understood directly, now it cost way too much time to admit. 😕

 

Also, isn't it time to scrap the 32 bit version and go only 64? 🙂

/Y

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.

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!