Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
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!
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.
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.
This should also be within LabVIEW so that it can work from LabVIEW Real-Time as well.
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).
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.
When you try to open VI saved with later version of LabVIEW, you get this error :
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:
- 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
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.
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.
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.
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.
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.
- 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.
I think theapplicationbuildershould be able togeneratea standalone applicationwithout the need toinstall theLabVIEWruntime engine,to reducethe userto install anduse the programto dothe stepsare toocomplicated orcomplextoinstall,orcan becalled"hiddeninstall"or "incidentalinstallation",and willinstallall the filesareplaced in aprogram(such asVIPMinstaller).Best toinstall thenon-LabVIEWfiles(like DOCdocuments, pictures, msiinstallation package, etc.).
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
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.
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
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.
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.
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 =)