LabVIEW Idea Exchange

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

I often have to duplicate a system, and it is hard to find and install the exact same driver versions.

If I download the drivers separately I often end up with many large files since much content is added to all drivers.

 

I would be nice if I could configure a list of required drivers (with specific versions) through a web page, and then download a single installer file containing just the selected drivers.

One of the more annoying features (see also here) is the unzip operation after downloading a LabVIEW distribution. As a first step, it will unzip somewhere into the "National Instruments Downloads" folder.

 

Of course it will place the progress window right in the middle of your monitor. Typically this takes a while and actually want to do something else and move that window out of the way, so we can still watch it in the corner of the eye. Easier said than done! A simple click in the window header pauses the unzip operations and asks if I want to abort... NO!!! I simply want to move that window is the same way I can move any other window from any other application!!! Why that nonstandard behavior? Just to annoy us??? Here's what happen if I click anywhere near the top edge of the window:

 

 

 

When we righ-click the window header, we see two options "(1) move" and "(2) close". Why is close the default??? If we really want to close, the [x] button is right there another inch to the right and nobody should have trouble finding that spot. If I click elsewhere in the header, I most likely want to move that window!

 

In order to actually move it, I have to right-click the window header and select "move". That seems silly!

 

IDEA: The unzip window should should be less annoying and easy to move elsewhere. Thanks!

 

When I install a new driver package, I have to choose the language options for every driver (LabView 2011, LabView 2012, LabWindows/CVI, C, C++, ...).

It would be better, if there were global options, which languages I use with my system.

Hi,

      We know there are lot of posts in Version Conversion Board  for conversion of VIs and DLLs from one version to the other.In other programing languages like .net we can see the 'VERSION CONVERSION WIZARD'.Using that we can easily convert from one version to the other.Why there is no such conversion wizards in labview?It will be very helpful.Is there any problems for creating a conversion Wizard?

I strongly forwarding the idea of a version conversion wizard.

A customer has expressed interest in having the LabVIEW Developer Suite Installer provide an estimation on how much disk space will be required for selected components. Specifically, the application in question is where the customer sets up LabVIEW on several virtual machines through VMWare, and needs to know how big of a hard disk is required on in the virtual machine configuration options prior to going through the installation processure. 

I would like to include arguments for any/all shortcuts from the installer. Currently you can build a labview installer to put shortcuts on desktop and to the "Program Files" menu. But there is no option to include arguments. See attached image of how it would look in labview.

 

InstallerShortcutArguments.png

 

This would allow for the installer application to include file path arguments into any executable. Example: You want to include a tftp server application for the installer and embed the tftp path in the shortcut.

 

It could also be usefull to run the same labview app with many startup arguments. Like if you have a debug mode and normal mode. If you want to include both options on the desktop you could use a -debug as the argument. And include it in the shortcut from the installer. Both shortcuts would point to <application> but one would also say "<application> -debug"

 

Thanks.

 

-Corey

Just 5 min ago I was in the situation that I downloaded an example VI from an NI support forum. I double clicked it and I got the message that the LabView-Version that was used for storing the VI is newer that my LabView version 😞

Most likely the VI could run without problems on my old Version (LV2009).

 

What I suggest to get around this kind of problems are two things:

1) create a web-based service (maybe only for registered users) where users can upload single VIs or ZIP-Files with a complete program structure. The VIs should be converted to the selected LabView version and send back to the user together with a conversion report.

 

2) integrate this service into LabView: If the user tries to open a VI that was stored in a newer LV version, LV should connect (after user confirmation) to the NI-Server for automated VI conversion.

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

It would be helpful to have a way to code sign your software for Mac OS X Mountain Lion to get suppport with the new GateKeeper fiunctionality.  Having a code signing option in the application builder would be perfect.  More information:  https://developer.apple.com/library/mac/#documentation/ToolsLanguages/Conceptual/OSXWorkflowGuide/DistributingApplicationsOutside/DistributingApplicationsOutside.html#//apple_ref/doc/uid/TP40011201-CH12-SW2

I've had a look around and can't see anything in here like this already (which surprises me so I'm suspicious that it's just the search algorithm failing) but I'd like to see options in the LabVIEW Project tree for changing target hardware.

 

For example, I have a development underway using a cRIO-9114 chassis with a 9024 controller, and a 9144 EtherCAT expansion chassis. The primary chassis is about to be upgraded to a 9116, as we need a bigger FPGA, and although the hardware upgrade process is straightforward, upgrading the chassis in the LabVIEW Project is not a possibility. Instread, I need to create a whole new target, and copy and paste every VI, node, FIFO, DMA etc. across. There's quite the possibility that I'll miss something, or the new target won't have all the same settings (Scan Mode period and priority settings for example), leaving me with that niggling feeling that something under the hood will be wrong. It would be much neater if this was an automated migration.

 

Furthermore, as the hardware is not here yet, I need to create the new target and all it's modules manually, which will take me quite some time. An automated migration would save me that trouble.

现在的这个生产安装程序注册表只能填定值啊,能不能添加一些动态的值,比如用户选择的应用程序安装目录等。

 

还有当第二次安装的时候,安装目录应该直接指向上次选择的目录啊,

 

现在生成的安装程序,和常用的安装程序相比还有很多差距啊,希望改善。

Hello!

 

For anyone who works on a PC that is not connected to the internet, but is is using a third party instrument, they could experience problems trying to view example VIs that ship with the instrument driver.

 

Currently with LV 2010, if one does not have an internet connection on a PC and navigates to Tools » Instrumentation » Find Instrument Drivers..., the NI Instrument Driver Finder Dialog Box will close after displaying the following pop up:

 

InstrDriver.png



Please made the NI Instrument Driver Finder available for PCs not connected to the internet.

 

Since the customer already installed the driver for his third party device, the Agilent E8364C, I made him aware that all of the top level, demo VIs are located on his machine in the *.llb file of his driver under the instr.lib folder.  This work around will suffice for this customer, but anyone without knowledge of our directory structure would struggle with this.

 

Thanks!


Shawn S.

Hi,

I am currently working on a quite large project, addressing different customers / users. Therefore I have in this project several specifications for executables and for isntallers. The point is, I would like to be able to right-click an installer build specification, choose build, and every executable used in the installer specification is built as well. Today, I have to remind and select all required executable specifications, and build them prior to installer building.

 

It would be great if the installer destinations property matched up with the system directory type parameter to the GetSystemDirectory.vi.  These should go hand in hand.

 

http://zone.ni.com/reference/en-XX/help/371361H-01/lvdialog/destinations_install_page/

When a VI is deprecated in vi.lib or other LabView libraries, please include the word "Deprecated" or some similar, standard word, in the VIs description. When upgrading the LabView version, I can then easily search for any deprecated VIs in my application and can consider rewoking the code to use the replacement VI. 

 

I would like to be able to specify an autrorun.inf, an autorun.ico file and a copyright file in the Build properties for the LabView (or CVI) installer properties to be copied to the ..\Volume directory for the built installer. I can then simply build a DVD from the installer's ..\Volume directory and the DVD will autorun on insertion (if autorun is enabled). Of course, I can manually add these files to the DVD build, which I do, but if it is simple fix to the installer, well, Ithe next person who takes over my projects is less likely to make a mistake.

Would like to see LabVIEW implement "Cloud Preferences". Basically store the LabVIEW.ini file in my NI.com account and be able to log into LabVIEW and have it download the ini and use it. Even allowing it to be *easily* stored on the network would be an improvement.

Hello LabVIEW Experts,

 

I thought of this recently when I was setting up a test computer.  I started up my LabVIEW project file and opened up my host VI only to find that I had some broken wires... DOH!  After looking over MAX and googling a few error codes, I found that the test machine I had didn't have RT installed.  That's when it hit me, wouldn't it be great if the VI would have recognized that I was trying to connect to a cRIO chassis and gave me a little pop up telling me what software I was missing and where to get it?  Sure would have made my day easier.

 

 

I find conditional disables very useful for managing complex applications that require multiple configurations.  Often I have several versions of an application with some features removed (disabled depending on hardware support or target platform)  and use a conditional token to turn on or off these features.  What i find frustrating is that this is not connected (at least as far as I know) to the build process.  I would like the project conditional disable symbols to be overridable in the build script so that I can have several build scripts with different settings.

We are a site that use multiple NI software products(LabView, Realtime, Vision, sound & Vibration, etc.) and multiple copies of each so we use the Volume License Manager.

 

My idea is to simplify installation, maintenance, and updates for folks that have a large usage base by:

 

  1. Stop needing to keep a record of all my S/N's of products and type them in when I need to do an install by:
    1. Allowing the install CD to query the License Manager for licensed products on the target and then automatically select them for installation without needing S/N's since the LM has that info.
  2. Make the NI Update Utility configurable to allow it to update all software available(service packs, and new software releases like LabView 2012) not just bug fixes.

 

The current system is pretty abusive to admins who need to maintain 50+ systems...how about a little help out here 😛