LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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.

This is only a wish that NI could provide a Utility that converts a VI or Dir to Up or Down.

I had a project that was done in LabVIEW 5 (done many years ago by someone else); I couldn’t open in LabVIEW 8.6. I needed to do stage upgrade LabVIEW 7 and follow up with LabVIEW 8.6 and so on.

I understand there are cases that you can not simply down convert, because newer function may not be available in older version. In this case it OK, give user an option for force the convert and worse case the down convert VI is broken. Let the programmer fix it!

The utility should have a Status Report for convention.

Please..!

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

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.

Microsoft introduced a number of restrictions in Vista that makes it more difficult to save program settings and temporary files.

 

Applications can no longer write to the Program Files directory, but even worse; the common application data directories, like ProgramData and Users\Default  are by default only accessible for writes by administrators and the first user that did the write. Sessions by other users only have read access. The same goes for registry access; the computer keys can not be written by everyone.

 

As long as it is OK to not share settings between user's you have one good option left; the user's appdata folder. If you do need to share data though - you need to set the access right of the folders you create in the "common" directories. This can currently be achieved e.g. by using a tool like SetACL, however as it has been made a required action now, it should be included in the installer - AND preferably also as VIs on the file and registry (for registry access) palettes.

 

LabVIEW 2009 introduced one of the tools required to handle the UAC changes - a VI to get the paths of system folders. It should also have a tool to grant access to some of those paths...

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.

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. 

For example:

1) install based on a license: this would install only the software related to a license;

2) reinstall/update based on license OR based on what's already installed.

 

For every new update of LabView I need to select the installation  of the toolkits I want, why not make it faster?

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

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.

It would be nice if LabVIEW automatically check for updates and notifies the user of all of the upgrades available for everything that they have registered. It would be nice if patches were just down loaded and installed much like the Windows Updater function. It would keep LabVIEW, all of the tool kits, Measurement and Automation Explorer, and every licensed software up to date. It could also push down labview as long as you are on the subscription and current.
Builder should automatically attach version of LV to EXE so it can be seen in Windows Explorer. So you can always ask unexperienced end user about version. I drove 1000 km with wrong version of LV on my laptop... Upgrade to new version is not always straitforward... And I always forget to set version information manualy...

For modern application development we need better methods to detect wheter our application is called to open a file.

Currently the only help NI gives is based on command line parameters. And we need to jump through loops to get it working to react on opening a file when the program allready runs.

 

This is a major showstopper in creating professional applications.

 

LabVIEW 8.2 had a hidden event for getting this event, which unfortunatly doesn't work in later versions.

 

 

I haven't checked out LV2009 on Mac yet, so please let me know if this has already changed.....

 

When creating an installer on Windows, we have control of everything within the Project.  Cereate EXE, then create Installer with all options within the project.

 

On the Mac we have the options for the Application but not for the installer.  I know (After I spent a day looking for products) that Apple has an installer packager which ships with the OS (On the developer CD) but why can't we automate this from within the Project shell?  As it is I need to create the Application, then switch to an external program, create the installer (luckily it's relativel easy o use) and then to finish things off go to ANOTHER pogram to create the dmg file.

 

Please give the Mac the same Installer creation options as Windows.

 

Shane.

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.

We are getting into trouble with all these run-time engine updates! Every time a new release or service pack come out we have to create a new installer with the new run-time engine and send it out onto all our customer's machines. It is not convenient to develop in 20 different versions of Labview and we like to keep our executables and updates recent.

 

Our instruments run on XPe with very little extra room for an additional RTE every 6 months. Asking the customer to uninstall old RTEs is painful as they are not supposed to go that deep inot our XPe build. 

 

I would like to see a modularized run-time engine where we don't need to update the whole thing every release. I know  with .NET updates are only necessary in 3-5 year increments. That would be much more acceptable IMHO:smileyhappy:

 

As outlined in a post in the NI forums HERE, and seeing as I'm currently being forced to re-install several LV versions on my Laptop (Have been doing so since yesterday!) I want to re-iterate my affinity for having LV installed in a Virtual PC.

 

Memory problems, Hard disk crashes, Virii, stupid user: there are many reasons why an OS would need to be re-installed.  In my case it happens that my HDD was on its way out.  I think this may be linked to many crashes I have been experiencing over the last 8-9 months.  I am nor re-installing ALL of my LV versions.  This is a major pain in the tuchas.  I have backups, but I would rather re-install since I don't know when the data corruption started.

 

Being a nice law-abiding citizen (or a sucker, depends on who you ask) I don't want to violate NI's EULA by installing each LV Version (Ideally each quarterly update)on a separate VM.  This violates rather quickly the "install on 3 PCs rule").

 

Please please let us install on many Virtual PCs as long as they are not distributed amongst other users.....

 

Did I say PLEASE?

 

Shane

Hello,

 

I work as a LabVIEW integrator and for one of my customer I develop application, with maintenance goal for their installation all over the world with RS232 or Bluetooth communication for example, deployed on targets as PDA (PocketPC 2003 & Windows Mobile 6) or Touch Panel (Windows CE 4.2 to 5.0) using LabVIEW 8.6 Mobile Module.

This LabVIEW additonal module works quite well to deploy the same application in this differant targets, but I encountered some problems and I have some suggestions for Mobile Module :

 

1/ MMI (Man Machine Interface)

      -  for graphics indicators (as Gauge or Slide) graphical object ramp or multi Slider is deleted by LabVIEW when you build an EXE => I think that a graphical objets with all its graphical property could be added in Mobile Module (and works on these all targets). See examples in GraphicalObjects.PNG

      - as I say in my introduction my application is deployed all over the world and usually I used "Caption" dynamic modification for multilingual management for all my controls & indicators. But in mobile module we can't do this (but we can modify dynamically boolean text), so I think that it could be possible.

 

2/ VISA (& Bluetooth) Management

      -  I think there is a bug with VISA installation. Indeed with the installer you can choose the installation directory (default directory or specific directory : in non volatil memory) but if you don't install VISA support in default directory it doesn't work (with PocketPC 2003 for example) I think that could be resolved

-  As I said in introduction my application could communicate throught different protocols (RS232, Bluetooth) and with LV 8.6 Mobile Module we can now use VISA : great !!!. But in Windows Mobile 6, VISA does not support bluetooth (it seems to have an incompatibility with virtual aliases in the registry) ; and in PocketPC2003 it works very well. I think that could be resolved

The default LabVIEW environment option should not show terminals as an icon. 

 

IconTerminals.png

I like using Linux whenever I can, particularly when running large software like LabVIEW, since it tends to crawl on my XP systems. I was happy to realize that LabVIEW works on Linux, but soon after I was disappointed by the lack of usefulness of it when interfacing with hardware. I need to use the RealTime module to interface with my RealTime Compact-RIO. I also need Linux support for the FPGA module, as I need to program the FPGA attached to my cRIO. I'm sure I am not the only person who would like the ability to do this.

 

Without support for any of the hardware or LabVIEW modules I need, the Linux version of LabVIEW is entirely useless to me, and XP as an OS simply cannot perform up to par for me.