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.
We can already create tasks, channels and scales in a LabVIEW project but, We cannot then use MAX to run those Tasks and we must use MAX to create a simulated device on a development machine. After a few projects the Max configuration becomes cluttered. Deployment and importing of the hardware configuration can get problematic to say the least!
On the other hand- if the Hardware, Data neighborhood and IVI session set-ups could be added to the project deployment would be a snap! just import the *.nce from the project without having to create one from MAX and exclude items not concerned for the project we are installing.
For integration and station troubleshooting the Sessions, Aliases, Tasks et al would be organized by application or project in MAX and fault identification has all the "tools" any repair tech could want to isolate a failure.
When I build a LabVIEW application, I do not include the runtime engine in the installer. Instead, I have a separate project that builds an installer for all the runtime components my applications need. That way, my users can perform the runtime installation once and then update the app separately many times. This keeps my installer sizes small and easy to distribute.
One issue I run into is when I move to a new version of LabVIEW. I need to make sure all my users update their systems to the new runtime engine before they try to install and run my latest release. Unfortunately there is no way to enforce this in the installer. You can check for an installation of the LabVIEW development environment (see image) but that is not very useful.
So, my idea is toadd the option to check for the presence of the runtime engine for the version of LabVIEW you are using to build your installer.
Additionally, it would be nice to have a way to check for other required components, such as .NET versions or other NI runtime components or drivers. This is similar to an idea I posted a while ago here.
I remember this in previous (pre-8.2) versions of LabVIEW - not sure why it was removed. I have a use case to use projects as templates (like when someone wants to write a plugin for a utility I've written, I want to be able to send them a zip containing a project, methods, etc). The project includes installer settings (so their files go into the right place under my util's plugins folder, but when they build and try to install their plugin, they get an error if another plugin bult using the same template has already been installed. This is because the "Upgrade Code" (stored in the lvproj file) is the same (it tells Windows that the two products are the same, so subsequent installs are seen as upgrades or replacements, not new installs.
My memory tells me that I used to be able to hit a "Generate" button somewhere which would give me build a new code - all I'm asking for is that back (I can add a step in my work instruction to hit that button before you build).
I don't currently have a workaround for this (other than having engineers manually edit the lvproj file) - if anyone has a better idea, I'd love to hear it for the interim!
A lot of engineers prefer Linux over Windows and would use it on there test machines if at all possible. Instead of attempting to support a wide variety of flavors, wouldn't it be better if NI would derive it's own flavor from an existing distribution and committed to having full support for all NI software and hardware for this new flavor. This would give Linux aficionados the OS they crave and NI the power to control the direction of the OS such that it makes hardware and software compatibility easier.
As software versioning becomes more and more popular also the automatic building of source code becomes more and more interesting.
Right now in our company we are using GIT and JENKINS for C-code material as our versioning and automatic build tool. As soon there is something being checked in and pushed to the main repository the builder gets notified and tries to build your source code having the output available somewhere.
As we are having many users around the globe these tools obviously run on a virtual machine or server somewhere.
Right now there is no option in buying the application builder seperatley and control it via command line. The only option is to put a complete development environment on there which is useless and a waste of money.
My request would be to sell the application builder seperatley for these purposes OR figure out an alternative way for doing this in a professional and neat way.
In newer LabVIEW versions, we can build executables that require SSE2 support an this option is even the default.
If we built an installer, we can select many other system requirements, such as the minimal OS version or the presence of the LabVIEW development system. However, there is no option to prevent installation if the CPU does not support SSE2.
This means that an application that requires SSE2 support will install just fine on a non-SSE2 system and will fail only once we try to actually run.
I suggest to add a system requirement option to the installer builder so the application will not install if the hardware is not suitable. It should maybe even be enabled by default.
Currently when you build an installer the current ini file in the destination directory gets overwritten. The user is generally unaware that this will happen and may lose configuration settings for their application. It would be nice if the user had the option to not overwrite the file during the installation.
When running the NI Developer Suite installer, first detect what is currently installed (as the device driver DVD does) then display it in both the Licensed Product List as well as the Evaluation Product List. This way the user will not doubt what they have already installed. This way you can include option to "Leave this feature installed".
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 have to support several production lines which are using different LabView versions (currently LV 8.5.1 and LV 2009). On my office PC I would like to use always the latest LabView.
If I open a project which was created in LV 2009 in a newer version of LabView, LV will try to convert all files to the new version. If I transfer it back to a PC which uses LV 2009 I can not open it.
I'd like to suggest a new project parameter that changes to storage format of all the files contained in the certain project (excluding those coming out of the LV program folder and maybe from some other excluded folders).
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.
<bakground>So i just had a silly thing happen to me, i compiled a program and deployed it to the target computer, just like i did yesterday. Then it started complaining about a missing LV 2017 Runtime ... How? Why?
I reinstalled, repaired and it didn't help, both program and RT, several times and it didn't help.
I tested another program which started just fine, so what's missing? Is it some sub-package that my custom RT-installer didn't include?
I called NI and the support technician couldn't see anything wrong either, so with him on the phone i went to the development computer to look at some installer settings he had dug up. That's when i noticed i was in LV2017 64 bit! The messages said nothing about that! </background>
Improve error messaging when missing RunTime. Include the bitness that's missing, now it only said "Missing LabVIEW RunTime 2017", if it had said "Missing LabVIEW RunTime 2017 (64 bit)" i would have reacted and understood directly, now it cost way too much time to admit. 😕
Also, isn't it time to scrap the 32 bit version and go only 64? 🙂
I am struggling (yet again) with LabVIEW installation problems that appear to involve LabVIEW 2017 (and possibly LabVIEW 2016 f5 patches). After having systems with multiple (sometimes only 2) LabVIEW Versions installed "go south" (typically by having MAX stop working and Block Diagrams with DAQmx code fail to load), I've tried to "Remove All" NI software, only to discover that "bits and pieces" still remain, both on Disk and (especially) scattered throughout the Registry.
I've been working with NI Support for 2-3 weeks trying to "recover" from a LabVIEW corruption probably caused by installing the 2016 f5 patch. We finally decided to do the "Uninstall/Reinstall" route. Although I got 2012 SP1 installed, 2014 SP1 failed (could not install NI Network Discovery 14.0, "Verify you have sufficient privileges to install Services").
My concern is that, short of reformatting my hard drive and reinstalling Windows (which I was forced to do on two of my PCs), there appears to be no way to fully uninstall all NI Software. I would like to propose that NI develop an "Eraser" utility (like Eraser for Microsoft Office) that searches out all files that NI puts on the C: drive (not in User Space) during installation and all Registry entries that it scatters throughout the Registry, allowing the PC to be "rolled back" to a "pre-NI" state. Such a tool might want to be restricted to Full or Professional licenses, or maybe provided on an "As Needed" basis by the NI Support Team, but I really don't want to have to rebuild yet a third PC ...
This is not directly related to LabVIEW but I haven't found any other thread which seems like a better fit. I'm posting it on the Idea Exchange since this is the best place for other customers to potentially agree with me.
NI drivers/software are quite often large, and above 1 GB is not uncommon and sometimes above 3 GB. Having everything in a single file is in my opinion a good thing because I don't have to look for multiple driver parts and download packages, but the file size must be matched by the download speed. Waiting three-four hours or more to download a single driver is not a fun thing to do and quite often you need more than one driver.
Sometimes the speed is okay, but as a general rule I would say it's slow. I'm located in Sweden and of course this issue is dependent on a lot of links between where I am located and the server where NI host the files.
But, download speeds of 200-300 KByte/s from NI are not uncommon but I can run speedtests on for example http://www.speedtest.net/ and get download speeds at 50Mbps using American servers.
I don't know how NI host the files, if it's internal servers or something else but it would be nice if NI looked into the possibility of somehow making this faster.
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!
Is it possible to have a USB dongle license option rather than a registration key?
When the USB dongle is attached the user will have the full access to the Labview Version s/he has registered for, when it is not the program will only run in runtime engine mode. The advantage of this is that it would allow for system developers of multiple systems to be able to debug and test programs on the machines without needing to either have several licences or continually uninstall and reinstall labview from the machines everytime a change in the software is required.
At the same time, a USB dongle can only be used on one machine at any one time, thereby making it possible to ensure that there will not be more than one user of the same license.
I've seen this work for several small software companies as well as hardware companies with proprietary software. Why not for Labview?