From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

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

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

Within LabVIEW Build Specs you can specify a version for an executable that is built.  You can presently see this from within the Windows add/remove program and there are some funky ways of getting this version with .net or WinAPI calls but you should be able to do this from LabVIEW similar to the app version as shown below.

 

appversion.JPG

 

This should also be within LabVIEW so that it can work from LabVIEW Real-Time as well.

If I'm the first to post this Idea then I'll be shocked.

The Idea is simple. We all love programming in LabVIEW, and I'm sure that we've all at one time or another had a colleague, friend or family member ask if we know how to do something on the PC. The immediate thought is I don't know where to get the software to do that, but I could write a simple LabVIEW app  in a few hours that does the job.

E.G hunt through someone's PC and move all of the jpg files over a certain size to a specific location so they can easily find their holiday snaps.

 

You can't create this simple function for them, because if you do, and build an exe, they still need the Runtime engine.

 

Surely for REALLY simple stuff (File IO, basic comms stuff in the Base LabVIEW edition ...) - not DAQ or anything like that it is possible to create an EXE that INCLUDES the runtime components that it needs and is stand alone.

 

This would open up LabVIEW for the use of making quick gadget like apps for the office as well as test and measurement.

 

I can't se how this could be a bad thing.

If LV can create .exe file independent to LV runtime engine, that's will make her more pretty than other programing tools(e.g VC++) 

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

A LabVIEW application installer generated from App Builder creates multiple folders and files in the folders. It is desirable to have a single file installer so that customers see only 1 file to install.

I use the Labview Development Environment usually on multiple PCs (my working place, my laptop, the customers development PC, etc.).

 

It takes a lot of time to install the whole environment and I think nothing can be done about. But it always angers me that there is no way to transfer the settings so that the environment behave exactly the same.

 

It should be possible to transfer the following settings easily:

- user.lib

- all changes done to the labview pallets

- settings in the configuration

- user added templates (VIs and projects)

and so on

 

Mayby that should work like the Easy Transfer Function for Windows from Microsoft.

This would speed up the installation and on every system I could experience the same behaviour of the development environment

Add an  option in the installer build to run cleanup-programs during uninstall.

 

On the advanced tab in the Installer build there is an option called: "Run executable at end of installation", but there is no such option for the deinstallation.

 

We use the existing option to run a batch file that installs and starts the application as a service. If the user decides to uninstall the application we would like to run another batch file to stop and deinstall  the service - but there is no option to run an executable during deinstallation.

LabView uses the "primary" MAC address to identify a machine. If the MAC address changes, LabView assumes the software no longer has a valid activation and displays the following:

 

license.png

 

Like many developers, I have to use a VPN to connect to a corporate network. My VPN client creates a pseudo-interface with a (random?) MAC address each time I connect. LabView inspects this MAC address and decides I've installed LabView on a new machine, forcing me to go through the activation process again. I have to activate LabView about every 10 days. I have contacted support about this, and they have given me various work-arounds such as non-expiring activation codes (which required manually entering 10 activation codes, one per product, and only work until the next LabView service pack), or tying activation to the Disk Volume ID, which frankly I did not bother trying since the "eligibility on a case by case basis" did not mesh with the reality that every point release of LabView requires re-activation.

 

Now, I don't want to make too much of this. I've never had the activation fail, and it is pretty fast, so it's really not a big deal, but it is kind of silly to identify a machine based on a mutable property. Heck, on linux it's trivial to change the MAC address to anything you want! (I tried this with my VPN client, but it had none of it.)

 

I suggest the activation process something more stable, like the CPUID on Intel processors or, barring that, restricting the MAC address search to physical interfaces.

 

Thank you!

 

Rob Calhoun

When you try to open VI saved with later version of LabVIEW, you get this error :

Sans titre.png

But when you open VIs in a given version with a later version of LabVIEW, you have no information and that could cause big problems.

For many reasons I have to work with different versions of LabVIEW (right now I have 8.6, 2010,2011 installed at the same time), and it's a major problem when I open a project and by mistake choose the wrong version of LabVIEW.

 

Someone proposed to display a saving selection popup Here

But when you have already made some modifications, it's enoying to discover that you won't be able to save it.

I propose instead to display a message when opening a VI, and let the user chosse either he want to upgrade is VI version or not.

At least he can see his mistake and decide to open the VI with the good version of LabVIEW.

 

 

Hi all LabVIEW fellows and users,

 

 

I know this has been asked many many times but one more might still help getting it.

 

Everybody agrees to say that today LabVIEW has became a great general purpose programming environment not only dedicated to test, measurement, instrument control or data analysis but able to manage virtualy any kind of requirement which is very cool for us LabVIEW programmers.

 

However, to my opinion one thing is still slowing down the use and spread of LabVIEW for developping general purpose applications that is the HUGE SIZE of its run-time engine!!! An average executable size for an application ranges from 1mb or less to 10 or 20 mb for quite large applications. The run-time for being able to execute it is at the very least 10 to 20 times larger which makes it very difficult to release over the internet.

 

I recently created a small application that monitors the state of the caps and num lock key and indicate the state with a tray icon since my computer is not equiped with those LEDs. I know some other users would appreciate to have that little piece of code since they might experience the same problems I had. How can I explain them that the application and installer is about 200 MB for such a tiny little piece of code? Don't you think people might believe that the proposed application is stuffed with malwares of that there is a BIG probleme with it?

 

Please dear NI decision makers make LabVIEW a "real" general purpose developping environement by adjusting the installer size to only what is required for the application, the whole community would appreciate so much at least make this option selectable.

 

Hope this will be listened.

 

Best Regards,

 

Brice

 

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.

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 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 think the application builder should be able to generate a standalone applicationwithout the need to install the LabVIEW runtime engine, to reduce the user to install anduse the program to do the steps are too complicated or complex to install, or can becalled "hidden install" or "incidental installation", and will install all the files are placed in a program (such as VIPM installer). Best to install the non-LabVIEW files (like DOCdocuments, pictures, msi installation package, etc.).

When building an installer have the builder scan all .vi's in order to include all addition installers that need to be installed.

I recently retired from my job as an electronics engineer. Prior to leaving I had been using LabVIEW to create a number of scientific instruments based on data collection and logging. I attended a couple of training courses in Newbury and was getting quite comfortable with the software. Unfortunately I no longer have access to LV and the educational discount option available from the company no longer applies for me.

 

However just because I have retired does not mean that I do not want to generate more projects using the knowledge gained during employment. My main area of interest is home automation, alt energy monitoring and control etc. I am finding it very frustrating that things I could do quickly and easily in LV have to be achieved using other software, this means yet another learning curve.

 

I downloaded SignalExpress LE a while back and was hoping that the software may go just a bit beyond data logging but it does not. There is no way to manipulate data in real time so again I have to look for other software.

 

The full version of LV is priced too high for my application and it occurred to me that there may be an opportunity for NI to provide a stripped down version of LV for consumer use. This version would need to include vesa, basic arrays, basic math, boolean and charting etc. The inclusion of drivers for 1 wire devices would also increase the appeal plus ready made vi's for the usb acquisition hardware. Pricing may be an issue but for non-commercial use it would have to be well below £100

 

Incidently I was contacted by customer support shortly after downloading SE LE and it was during our conversation he suggested that a post on this site may be appropriate.

 

 

 

 

 

 

Right now, we can build an installer which embeds other installers (e.g. the LVRTE).  So we can distribute the installer and allow our customers to install everything they need using one installer.  This is great.  But I find that it sometimes disturbs my customers when they see that my application is also installing other things (i.e. LVRTE, DAQmx, etc).  They are curious about the "3rd Party Components".  I totally understand this.  When I download an installer, and see things like "Click here to also install Google Chrome" or Google Earth or some other spyware garbage, I am immediately suspicious.  Or worse, when I am not even warned about.  Bundling other installers is a common way to spread adware.  

 

Problem:

- Bundling third party componenets into an installer is suspicious to many users. 

- Bunlding extra installers also makes the un-intall process more complex (you have to uninstall things the extra stuff in a different step).

- Current method of bundling extra installers does not inform the user about all of the components being installed

 

 

So my suggestion:  Allow these components to be bundled (i.e. hidden) in the application directory.  I believe this is already possible with other run-time engines like the Java Runtime Engime.  And I see that something similar is possible with LabWindows/CVI (see here), though I have never used LabWindows.

 

I guess another way to do this is just to somehow hide the extra stuff from the user.  Do a silent install of all the 3rd party componenets.  But I feel like that is a bit devious, and might piss off some customers.

How come you can't tell which version a .vi was created in until you open it? How come you can't just tell whether it was created for 7.1 or 2010? An idea is to have it save a different .vi extention, much like in Microsoft Office, for exampe, a 2003 version would not open a 2007 version, and you can tell before opening because of the .xls or other extension.  For labview, it could be like for 7.1 it was .vi71 and for Labview 8.2, .vi82, and for 2010, how about .vi2010?

Maybe this could come in handy for those who are looking for certain vi's of a certain version.

I have used Labview for about 10 years, the last 4 years complete full time as my actual job requires it, several times I have gotten a tired sight which made difficult to read Labview code, I really wonder if there are plans to add some zoom functionality.

 

In fact it would be nice to have a magnifying glass on the tools pallet, with a sort of resizeble frame that let you follow the code. There should be an rights explanation, because I feel this idea is kind of obvious, and also I am sure that tons of new users quit trying because this lack of functionanlity.

 

anyway let me know your comments,