We are getting into trouble with all these run-time engine updates! Every time a new release or service pack come out we have to create a new installer with the new run-time engine and send it out onto all our customer's machines. It is not convenient to develop in 20 different versions of Labview and we like to keep our executables and updates recent.
Our instruments run on XPe with very little extra room for an additional RTE every 6 months. Asking the customer to uninstall old RTEs is painful as they are not supposed to go that deep inot our XPe build.
I would like to see a modularized run-time engine where we don't need to update the whole thing every release. I know with .NET updates are only necessary in 3-5 year increments. That would be much more acceptable IMHO
I like using Linux whenever I can, particularly when running large software like LabVIEW, since it tends to crawl on my XP systems. I was happy to realize that LabVIEW works on Linux, but soon after I was disappointed by the lack of usefulness of it when interfacing with hardware. I need to use the RealTime module to interface with my RealTime Compact-RIO. I also need Linux support for the FPGA module, as I need to program the FPGA attached to my cRIO. I'm sure I am not the only person who would like the ability to do this.
Without support for any of the hardware or LabVIEW modules I need, the Linux version of LabVIEW is entirely useless to me, and XP as an OS simply cannot perform up to par for me.
I installed LabVIEW 2020 on my PC and my friend is working with LabVIEW 2016 every time I open his projekt now it gets upconverted and if I downconvert it to 2016 I can only do it via the special option, which does not even allow me to overwrite the original 2016 files. Iam stuck with 2020 since I did not buy SSP GREAT, how is this in any way userfriendly? Its worse then the compatibility of Word with Libre office.
That was Bryans original post 12 years ago, its still the same.
Wouldn't it be nice if we can add W10 IoT Enterprise PCs as Embedded Targets, where we can create VI executable and set it as startup programs and once deployed, the target will be automatically configured to: launch the startup programs with Embedded Enabling Features (EEF), Enhanced Write Filter (EWF), Hibernate Once, Resume Many (HORM) and File Based Write Filter (FBWF) but on different volume; as presented in NI Week TS2361 & TS8562 slides.
When installing recent updates for LabVIEW 2018 an error message came up that said the installer needs access to "My Documents". However this location "file path" is not available. My company has a drive mapping package that has the my documents located on the server as well as my favorites so it is automatically backed up for recovery purposes. The installer keeps getting this error and forums state that the IT admins need to get involved every time to update & set my documents to local temporarily to install, then back to the server for automatic backups. This is very tedious and takes a lot of manpower. My colleague has the same issue with DIAdem 2018 as well. Looking to possibly have a fix where it gives the user a browse option to find the file path it needs for the install.
We like to keep the OS installation clean/stock. That is, install RHEL and any packages required for the engineering applications and try to keep the installation packages to the minimum that are required. Typically the EDA vendors will have a script that checks that all of the Linux package required the application. If we find any dependencies we install on all machines. The LabView Linux installation script wants to be run as root and install packages. Would rather see a dependency check script so that we can install the dependencies ourselves and know what is being installed.
For the application tool itself we don't want to install in /usr/local on all machines but rather install into a NFS mounted file server so that we only need to install once and not install on each machine individually. The current Linux installation script doesn't take an argument to specify an installation directory other than /usr/local.
This has been a problem since LV 2018 beta. LabVIEW deactivates for no apparent reason; and it's gotten worse and worse as the year has progressed. I now must reactivate LabVIEW every time I start it (your product support seems to be clueless).
My idea is that you design a Licensing/Activation system that behaves in a sane manner.
Propose to have RAD utility to include a "Snapshot/Clone" function that snap the image "exactly as is" the state of the cRIO/PAC at that image creation instance; that would include the entire drive structure, configurations, bit files, network settings, etc. Restoring from such type of image onto the cRIO will, without fail, guarantees its functionality (at least back to the state the image is created).
This come after the 2nd time of suspected corruption, when I deployed with error in LV causing irreversible/permanent impairment to my deployed RT application. First time being without a backup, that led me to reformat, reinstall and redeploy for one mistake in deployment. Second time being with a backup, apparently incomplete image using the RAD16 (http://www.ni.com/example/30986/en/), upon deployment failure and image restoration, the damage has not been reversed.
Hopefully to see this option developed soon, as the conventionally advised method of reformatting, reinstalling and redeploying cRIO, is not really practical.
I faced issues while creating an installer with a size of 2GB+. Unfortunately I had to upload the installer to a shared site that didn't accept files > 400MB. The want for a separate installer and process thereof delayed my delivery.
I remember from other software(s) having distro creation capabilities in size of lets say a standard CD size of 650MB, etc.
Wouldn't it help many if the app builder allowed splitting the installer in a defined packet size?
Please provide a setting to exclude unspecified folders.
I started a Mass Compile on one folder. Whoa, it did more than I expected! It changed and saved hundreds of files. I let it run for about a minute, got too nervous, and stopped it. I was surprised that I gave it one folder to recompile and it saved called Vis even if they were in other folders above and outside of the one I had specified. I didn’t think to back those up.
NI's code should be excluded! Many VIs are installed as part of LabVIEW in the C:\Program Files (x86)\National Instruments\LabVIEW folder. These should NEVER be modified outside of installs/upgrades. I started a Mass Compile and, whoa, it did much more than I expected! It changed and saved hundreds of files. I let it run for about a minute, got too nervous, and stopped it. I didn’t think to back that up. Now I fear my LabVIEW installation is dirty. NI SR#7722650 says "It does go outside of the specific folder if the VIs in the specific folder depend on another VI outside of the folder. When it goes outside, it is just opening the VI and resaving it in the current version of LabVIEW. Because your VIs depend on some VIs in the ... vi.lib it went and resaved them. But, they are already in LabVIEW 2015 SP1, so it will not change anything in them. It does this to ensure the VI is looking at the current version of LabVIEW and not an older version." If that is true, why would installation of a version of LabVIEW install VIs of older versions? Make sure all vi.lib VIs are already compiled for that version.
Mass Compile changes files that do not have a LabVIEW code extension such as ".ctl" and ".vi"! Why is it trying to load, check, and save files with extensions such as ".bak" and “.err”? The following example shows files that a prior mass compile found problems with and I renamed them and removed them from source code control.
### Bad VI: "EditString.ctl.err" Path="C:\cvs\r8000\labview\app\editor\controls\EditString.ctl.err"
### Bad VI: "MCNavigate_old.vi.err" Path="C:\cvs\r8000\labview\app\remote_control\MCNavigate_old.vi.err"
It would be nice, if during installation of LabVIEW, installer will configure Firewall as needed for LabVIEW. For example, Network Streams - is standard LabVIEW feature, but to use it, one should manually configure Firewall (as described in this KB article). I'm sure, that there are other cases when similar should be done.
Of course, then exe anyway should be added to Firewall exclusions list, but at least one could use and test Network Streams out of the box, without googling out why it does not work...
This feature could be optional during LabVIEW installation, but if it is possible to automate something - then better to have it automated, then refer to some manuals and KB articles...
To generate a VI or set of VIs with a general driver to get low-end FPGA boards to work with LabView FPGA. Parameters will only come from the users to make this dynamic, this would be the total count of I/Os FPGA type, location of I/O items (eg. buttons) in the FPGA board, etc. It would be a bit of work, but also would pay off at the end. Doing such is no more than an extension of LabView if done well, let's say written in an xml file plus it would be a very powerful tool for researchers, and would generate more sales to use LabView FPGA for more researchers, university students, and engineers who want to test a few things without full initial commitment to NI tools.
Unbelievably NI has introduced a bug into LV 2016 whereas the "Open/Create/Replace File" function does not display the input prompt to the user. In fact no File I/O functions will display the inputed prompt. Worse yet there are no prompts for finding or opening files within LabView itself. Try opening a vi, there is no prompt whatsoever. In previous versions of LabView there is a prompt telling the user what to do. e.g. "Select File to Open"
This is very bothersome when you open a vi that cannot find a called vi. Prior to 2016 there would be a prompt telling the user what vi it is looking for. Now you are left to guess what vi Labview cannot find.
This is a huge problem for me as I prompt the user to find files and folders in a great deal of my code. If I were to upgrade to 2016 I would have to go through 100's of vi's and add dialogs telling the user what to do prior to calling any File I/O functions.
The most disturbing aspect of this issue is that NI did not fix this bug prior to releasing 2017. It is beyond me how this bug could have made it to another version. This bug alone requires a fix and an upgrade for both 2016 and 2017 immediately.
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 😃
Is it possible that the contents within the instr.lib to be defaulted to read-only every time LabVIEW launches? VIs that is drag-drop from the pallet onto block diagram is currently modifiable and may cause unintentional code modifications, especially due to the 'save all' function and hasty/improper shutdown. The extend of the damage may be inherited over time.
Also propose to default modified instr.lib VIs saves to be in active project folder instead of the instr.lib.