LabVIEW Idea Exchange

Post an idea

It might be worth exploring the feasibility of having an online vi upgrade/downgrade service, where you could submit your vi, and receive back the new vi.

I realize this wold be a huge undertaking, however, a reasonable fee could be charged. It could be a second option, in case the customer:

Has tried to do this on their own and failed

Does not have the intermediate versions to perform the required jumps

Isn't worth their time considering the cost of the service

In the case of upgrading a vi, this could serve as an added incentive to invest in the latest version of Labview, especially if the customer is several versions behind.

Would it be great to have free labview license that would allow to read VIs and save them to the previous version you have?

Immediate upgrade to new version does not happen in my case. I can not justify it for my boss, it adds a lot of work to upgrade all customers to new version, I hate idea of supporting multiple versions of code.

The main reason I need later version(s) is forum posts, other solutions that I would be able to open, save to the full one for real use. May be I will see the beauty of VIs in new versions and agree to upgrade 😃

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:

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

For LabVIEW users,

How many of them need "Delete Option" on Right Click Context Menu?

I feel providing an delete option in right clicking context menu for any Indicator or Control deleting will make developers easy and fast assessable and avoid too-much use of keyboard.

We use our left hand for control and Shift more offen but for pressing delete button which is at right top corner in keyboard, all of a sudden we will remove our right hand from mouse and press Del which is non comfortable.

So, Developers share your point of view for the same and request to add Delete Option in upcoming version.

Later we will ask even Cut Copy Past... He! He! He!

View All (1)

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.

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.

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

View All (2)

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

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

View All (2)

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

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,

View All (5)

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.

View All (2)

View All (5)

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

LabVIEW Idea Exchange

Online service to convert Labview vi to different Labview version

Single file installer

Read-only labview license

Product Activation Should Use Stable Machine Identifier

How many need Delete Option on Context Menu?

Packed LVCLASS Package: .lvclassp

Allow installer to embed the LVRTE into the application directory

LabVIEW version alert

Transfer Labview Development Environment settings from one installation to another

Upgrade LV Project RT targets

Cloud Preferences

Missing Software Pop Up

set conditional disables in build scripts

Reduce LabVIEW Runtime size to only what is required for the *.exe to run

Labview Version-Dependent name extention, not just .vi

Applications Builder

Why Labview doesnt have ZOOM tools on the Blockdiagram side?

Include Events In Base Package

Scan for installers

Get EXE version in LabVIEW