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!
Top Authors
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

Many modules aren't compatible with Labview 2010 64 bit, but there is no warning of that before installing Labview 2010 64 bit. So the user goes through hour(s) to install the software, only to realize it won't work when he/she installs a module (Real Time Module for example), and then has to uninstall and reinstall the 32 bit version. If it isn't compatible, let people know so they don't waste hours!

I did a search and did not find this. Hopefully it is not a dupe.

 

The event structure has become an almost integral part of LabVIEW programming. It should no longer be considered an advanced tool that is only needed in the full development system and higher. Events should be included in the base package. Maybe it means slightly increasing the cost of base and slightly decreasing the price of full. I don't know. But there should not be a LabVIEW that does not include the event structure. I own (my company owns) the development suite so I get nothing out of this. But if I were to buy my own copy I could almost see spending $1,249 but definately not $2,599. I am not going to spend over a grand for events and I am not going to program in LabVIEW without them either. So maybe someday, if this idea is accepted, I will get something out of it. And so will National Instruments.

 

Capture.PNG

 

Give the user the ability to upgrade versions of Teststand or labview without bringing the test equipment down for several hours. Currently it is quicker to image the whole pc than install a new NI software version. Some of the software (from other vendors) we run has propretiary configuration and imaging isn't always feasible. I would like to be able to upgrade from Labview 8.6 to 2010 without stopping production, just upgraded from 8.2 to 8.6 and on 50computers, on a production floor, it was logistically difficult. It would be a while before I consider upgrading again, with the current setup.

We just bought LabVIEW 2010 and I noticed that there is no utility avaible for converting a function panel (.fp) to a VI.  When will this utility be available?

I often need to build applications and installers that include VIs or .LLBs that have been built  earlier on...but this is a major pain because as long as LabVIEW recognises the file type it will try to link the VI or VIs in the library to the other VIs in the project, it finds conflicts etc. There are ways to come around it yes, but not very elegant ones.

 

Basically what I want is for projects to be able to treat VIs and LLB files as non-LabVIEW files. Just like you can include a text file, a JPG picture or other files in your project and installers I want it to be simple to add "completed" LabVIEW files.

 

One solution could be to have another type of project folder. We have auto-populating folders...perhaps we could have a folder for pre-compiled / to be treated as external sources folder...? In most cases for me LabVIEW could just see that the file does not contain any source code and then treat it as a "dead" file..or at least give you the option to do so (if there is a potential conflict).

Living in the dark ages I do not have web access on my LV development PCs and so have to go to www.ni.com/activate to turn on LV after every update/install. If I am lucky I can sit my LV machine beside my web PC and type in the computer ID code and vice-versa with the resulting authorization code. If I am unlucky bits of paper, pens and walking become involved. Having to authorise on each PC is reasonable but if I need to authorize more than one product e.g. LV and Application Builder (I have the Pro version) then not only do I have to licence 2 things but I have to enter ALL the data twice - a simple 'activate another product' button at the end of the activation pages (with data like pc id and licence number and name etc retained) would make life easier. My appologies if there is one already - but if there is it needs to be more obvious.

We need the ability to manage multiple volume licenses from a single VLM instance.  We have several groups from different cost centers that use LV; however, currently all the license administration falls on me.  The only solutions available at this time are:

  1. Merge all the licensing needs from each group into a single license.  This is a nightmare for me.  For one, our internal accounting system isn't set up to easily transfer funds between cost centers, so getting the money to pay for the license has been difficult and usually leads to payment delays.  Second, it's very difficult to respond to changing license requirements of an individual group when everything is lumped into a single license file.  If a single group wants to discontinue their subscription, rather than just letting the subscription expire (which would cancel the subscription for all groups) they have to pay a fee to "break out" their licenses from the volume license.  If a group wants to add products to their license, all requests get funnelled through me.  This might be good for NI, but it's a royal PITA for me.  (License administration is something I do in my "spare" time.)  Third, it's inconvenient having to track how many licenses of each type each group has purchased and cross check that against how many licenses they are using.
  2. Maintain separate computers for each VLA.  From an ease-of-use perspective this is almost as bad as option 1.  From a practical perspective this is worse than option 1.  It's silly to have several different computers sitting around doing nothing other than running a license server.  Furthermore, it's harder to loan an available license from one group to another group (which does sometimes happen) as the user has to redirect to a new license server.

Neither of these solutions work very well.  I don't mind the license administration part of the job.  Creating installers, changing permissions, and stuff like that doesn't really take that much time.  What is killing me is the account administration part of the job.  The single license model forces me to be an account administrator for several independent groups, and the corporate culture and infrastructure here don't support that model very well at all.  What I would like to be able to do is have each group be responsible for purchasing and maintaining their own volume license agreements.  When they get the license file they can send it to me and I'll install it in the VLM.

 

I envision each VLA having it's own root node in the tree diagram.  Instead of a single "Volume Licenses" node, there would be one for "Group A Licenses," another for "Group B Licenses," etc.  (I have to be able to rename or annotate the root node for each VLA.)  The Users and Computers nodes still contain the users and computers from all the groups, but maybe those nodes have virtual directories I can use to organize them.

Currently, mass-compiling runs into problems with subversion files in "_svn" directories (files called X.vi.svn-base).  There should be a setting to exclude these directories.