Controlling different versions of LabVIEW

In "NI eSupport News Vol. 6, No. 11 - November 2002" you brought following, but the link does not work (wrong subject). And can't find the subject on your web. Got another link??
<==Controlling which Version of LabVIEW Opens When You Double-Click a VI in
Windows==>
If you have two or more copies of LabVIEW on one computer, you might notice
that when you double-click a VI in Windows, the last version of LabVIEW you
closed will open. The following KnowledgeBase document describes how you
can double-click a VI and have a specific version of LabVIEW open:
http://digital.ni.com/express.nsf/express?openagent&code=esup110211

Sorry about that. We'll fix the link to point to the right place, but meanwhile, here's the KnowledgeBase entry that was being referenced:
http://digital.ni.com/public.nsf/websearch/63EB67ED9D45797E86256C35006C257E?OpenDocument
Or, you can search the KB for document ID 2PEDLK2Q.
Regards,
John Lum
National Instruments

Similar Messages

Could there be independent VI paths for different versions of LabVIEW?

Hello,
When jumping between different versions of LabVIEW (6.1, 7.1, 8.5) it is annoying that the current path for one becomes the current path for the other.
If I am working with LV 7.1 in a folder dedicated to 7.1 VI's, and then open LV 8.5, I don't want 8.5 to go to that 7.1 folder by default. Alternately. if I was working in LV 8.5, closed it out, and then I click on a 7.1 VI, I don't want it to open in LV 8.5.
I've tried changing the path options in each version of LabVIEW, but that doesn't seem to help. Is there any way of isolating these folder paths from one another? One of our newer LV guys accidently opened some 7.1 code in 8.5.1 and then saved it. Luckily, I had archived code to return to, but it could have been a disaster.
Thanks for any ideas,
McSynth

You're actually asking two different questions.
The first question has to do with which version of LabVIEW gets launched when you double-click a file. This is an operating system thing. The one that gets launched is the last one that got used. (Your first question will be: can this be changed? Answer: Change the operating system. Or, play around with the registry each time you quit out LabVIEW.)
The second question has to do with search paths. These are independent. However, a VI will contain information about its subVIs in terms of where to find them. This is not a function of LabVIEW, as it is a function of the VI. Thus, it will make no difference which version of LabVIEW you use to open the VI. You can, if you wish, modify the search paths that LabVIEW uses to find VIs for each version of LabVIEW from the Tools->Options menu. However, this will not eliminate the problem, and your best bet is to keep those backups frequent.

How can I handle deploying multiple test systems on the same PC that have been developed using different versions of LabVIEW, TestStand, and/or Switch Executive?

The major issue here is that the test systems must be documented and validated before being released to the production floor. Given this if a test station has multiple test systems deployed on it that have been developed on various versions of LV, TS, and Switch exec how can I force the test system selected to use the correct versions of TS, LV, and Switch exec.? I understand that the solution would be to recomplie everything and bring them up to the latest version but that would then require re-validation according to the QA department. Any advice would be greatly appreciated.
It would be nice if theTS deployment was more like an LV executable... meaning when a LV executable is launched it always knows what LV runtime engine to use when there are multiple engines installed on a PC.

Hi,
Multiply versions of teststand can reside on the same system, but only one version can run at a time. They is a utility that has to be run to set the active version.
The SequenceFiles have a version number, and you will find an error will be generate if you try to Load the sequencefile in the wrong version of TestStand.
The labview VIs will only work providing the correct version of the RTE is also installed on your system, even a labview executabe requires the correct RTE to be installed, either as part of the executable installation or as a seperate installation, before the labview exe will work correctly.
I'm not fimilar with the Switch exec but I would expect that it will also require the correct lower level device drivers to be available for the version you are using.
Therefore, as you are indicating that some of your system are at a older version, its difficult to image how you could achive this, considering if you say you have different versions of the software(s). For a start, you may have the problem that newer code/ sequencefiles using additional functionatily not available in the older versions.
I would think your only solution would be to have different deployments covering the different versions you have, or at least bring all your test systems up to the same version of teststand.
Regards
Ray Farmer
Regards
Ray Farmer

Can NI-PSP be used to communicate between machines developed with different versions of LabVIEW?

Hi all,
A customer has a large PC application developed with LabVIEW 2010 SP1.
They would like to add extend their system with a cRIO-9075. According to this document (ftp://ftp.ni.com/pub/devzone/tut/crio_software_versions.htm ), the minimum supported version of LabVIEW (with Scan Engine support) is LV 2011.
To minimize risks, it is preferred that we don't upgrade LabVIEW for the main application, which is atively being used in production.
I was thinking of developing the cRIO software in a newer version of LabVIEW (say, LV 2013 SP1), and using shared variables only to communicate between the PC and the cRIO.
Is this a viable option? Does it matter if the PC and the cRIO have different versions of the LV runtime?

It shouldn't matter, but then with shared variables you can never know for sure -- there are so many things that can make them break.
You might be money ahead to write the comm using TCP/IP. You know that will work.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

How to run stand alone executables developed with different versions of LabView on the same system

I am using LabVIEW 8.2 to develop a stand alone executable for a target system. The target system already has a stand alone executable written by another vendor, using LabVIEW 7.1. I installed the LV RunTime Engine for 8.2 which left the 7.1 engine intact (as it should). The problem I am now having is that the drivers installed on the target system are incompatible with the NI-DMM vi's that I am using. My concern is that if I replace the old drivers with the ones I am using on my development platform I may end up breaking the old software. What would be an appropriate work around to ensure that the target system will be able to run both executables? (FWIW the system will NOT be running both executables concurrently.)
The target system is an embedded PXI card cage, running Windows XP, with a NI PXI-4070 DMM (among other instruments, however I have had not had this issue with the NI-DAQmx drivers).

Hi Yerffejj,
Thanks for sharing your issue with the community. I am struggling to see what you mean by "break the software." If you only have the two executables and LV Run-Time versions 8.2 & 7.1, then you just need to go to http://www.ni.com/support/ » Drivers and Updates » Search within Results: » enter "NI-DMM" » GO to get the DMM driver you need. To see the driver you were using on the development machine, just go to Measurement & Automation Explorer (MAX). The DMM driver should also automatically install DAQmx, NI-VISA, and NI-IVI, fyi.
Best wishes to you, and please let us know if that does not solve your problem.
Regards,
Dan Richards
Dan Richards
Certified LabVIEW Developer

Shared variable of different version of LabView

Hello!
I have two PC computer with windows XP. On one computer is installed LabView 8.6.1 on second i like to install Labview 2009. Currently is not possible to install LabView 2009 on first PC. Is some problem to exchange data via shared variabe. Are necesarry to preform some specific settings?
Tanks for an answer!

- After start of computer is service status indicated as started (status_sve.jpg)
- When i try to manualy stop the service is after long time error reported (stop_sve.jpg)
- When i try to start service manualy is another error reported (start_sve.jpg)
Attachments:
status_sve.JPG ‏40 KB
stop_sve.JPG ‏85 KB
start_sve.JPG ‏106 KB

Converting All Files to Different Version

Is there a much quicker and happier way to convert my entire project to a different version of LabVIEW other than opening every single one of the 2000+ files? I've considered perhaps creating a VI to do this. Use VI Server to just open each .VI, save it, then close it. This would then hopefully include every single .ctl, yes? Thoughts, suggestions?
Remember, code does exactly what you tell it.

It is not entirely clear what you want. To convert to the current version, try masscompiling.
To convert to an earlier version, the "save for previous" menu entry is available in the project window. No need to open any VIs.
LabVIEW Champion . Do more with less code and in less time .

Using mutliple versions of LabView

I am using 3 different versions of LabView right now (7.1, 8.0, 8.2). Mainly because I haven't had time to upgrade all our software to 8.2. Some of the programs I don't want to upgrade yet because I don't have time to fix the bugs that come with updating them to newer versions of LabView. My question is weather LAbView knows which version of LabView to use to use to open VIs when I open them through windows explorer or if it just defaults to the last one used.
Regards

Basically, LV opens VIs in the last version you started (although 8.2 has an apparent bug in that area).
If you force explorer to open VIs in a different version (right click the VI and select Open With...), then it should start trying to open them in that version.
Dataact makes the LabVIEW version chooser, which I believe should make it easier to select, but I haven't tried it.
Try to take over the world!

Managing Multiple Versions of LabVIEW on same Computer

With a new version of LabVIEW coming out every year, and service packs every 6 months, what is the best way of keeping different versions of LabVIEW (8.6, 2009, 2010 SP1) on the same computer, without being effected by new installations?
I have read up on some people using virtual machines to do this. From past experience with virtual machines, I remember only being able to
use a single monitor with the VM. However, it is very helpful to have 2 monitors when programming; are there VMs that can run in 2 monitors (just like
a normal OS?)
Thanks for the input.
--CLD--
LV 6.1, 8.6.1, 2011 SP1, 2012 SP1

Hi Jim,
I have installed multiple versions of LabVIEW on the same PC. When doing upgrades, such as a service pack, it does not affect other installed versions. This was done as a regular install in the OS, not using Virtual Machines.
I have been doing this since 2001, and for some customers, they have versions ranging from 6.1 to 2009. Only in one recent situation has there been an unusual event with multiple parallel installations. It was due to a DAQmx driver installation (long story).
Overlaping drivers should not be an issue. The issue with the DAQmx driver was that I forced to revert a LV8.2 driver by cheating on the installation. It worked for 8.2 but screwed up something in 2010. That was because I did not install the DAQmx drivers the way they were supposed to be installed.

How can I read pdf files from LabVIEW with different versions of Acrobat reader?

How can I read pdf files from LabVIEW with different versions of Acrobat reader?
I have made a LabVIEW program where I have possibility to read a PDF document. When I made this LabVIEW program it was Acrobat Reader 5.0.5 that was installed on the PC. Lather when the Acrobat Reader was upgraded to version 6.0, there was an error when VI tries to launch the LabVIEW program. And Later again when we upgraded to Acrobat Reader 7.0.5 I must again do some changes and rebuild the EXE files again
It isn't so very big job to do the changes in one single LabVIEW program, but we have built a lot of LabVIEW programs so this take time to due changes every time vi update Acrobat Reader. (We have build EXE files.)
The job is to right click the ActiveX container and Click "Insert ActiveX Object", then I can brows the computer for the new version of acrobat Reader. After this I must rebuild all the "methods" in the Activex call to make the VI executable again.
Is there a way to build LabVIEW program so I don't have to do this job every time we update Acrobat Reader?
This LabVIEW program is written in LabVIEW 6.1, but I se the problem is the same in LabVIEW 8.2.
Jan Inge Gustavsen
Attachments:
Show PDF-file - Adobe Reader 7-0-5 - LV61.vi ‏43 KB
Read PDF file.jpg ‏201 KB
Show PDF-file - Adobe Reader 5-0-5 - LV61.vi ‏42 KB

hi there
try the vi
..vi.lib\platform\browser.llb\Open Acrobat Document.vi
it uses DDE or the command line to run an external application (e.g. Adobe Acrobat)
Best regards
chris
CL(A)Dly bending G-Force with LabVIEW
famous last words: "oh my god, it is full of stars!"

Why do different versions of the LabVIEW Run-Time Engine not compatible?

LabVIEW Run-Time Engine to become more and more big
Why do different versions of the LabVIEW Run-Time Engine not compatible?
" 一天到晚游泳的鱼"
[email protected]
我的个人网站：LabVIEW——北方客栈 http://www.labview365.com
欢迎加入《LabVIEW编程思想》组——http://decibel.ni.com/content/groups/thinking-in-labview
Solved!
Go to Solution.

jwdz wrote:
LabVIEW2020 ....... ，it look like?
You need to express your ideas more clearly. We cannot fill in the blanks and read between the lines if the post has no substance.
jwdz wrote:
It will affect the future development of LabVIEW, right?
What is "it"?
There are many things that affect the future development of LabVIEW, starting with NI management, all the smart people in LabVIEW development, the economy, the LabVIEW users, etc.
If you are worried about the increasing size of the distribution, the good news is that the cost of data storage and data transmission has dropped much more dramatically. Even though newer versions are bigger due to great and welcome new features, the improvements in infrastructure have actually made the distribution and storage significantly easier over the years and will continue to do so. Trust me!
Nobody wants to go back to a LabVIEW version that fits on a floppy disk!
LabVIEW Champion . Do more with less code and in less time .

Is there a way to programmatically tell what version of LabVIEW a VI is compiled in?

Is there a way to tell programmatically what version of LabVIEW a VI is compiled in?
LabVIEW seems to know. If you click on "List Unsaved Changes", it (sometimes?) tells you the version of LabVIEW that the VI is already saved under (i.e., 8.0 instead of 8.0.1). So if LabVIEW knows, maybe they've provided a way for us lower-echelon folks (i.e., customers) to know too, eh?
Is there a way to get this from, say, VI Properties (i.e., Property Node gets passed a ref to a VI & I select the right property name)? I couldn't find any property name that has "version" or anything like that, but maybe what I'm looking for is using terms that are so different than what I'm expecting that I just can't tell.
Or by some other method? (I gvimmed a few .vi files, and see some stuff that looks like I *could* get the version by parsing/searching the file itself, but parsing the binary might give pretty unreliable results.)

Just dro a proerty node on the diagram and select property: "Application...Version number" and display the resulting string output.
Message Edited by altenbach on 07-02-2006 11:33 AM
LabVIEW Champion . Do more with less code and in less time .
Attachments:
version.png ‏9 KB

Different versions of a program, subvies location

Hello everybody,
I have problem when I try to keep two different versions of a proyect in my PC. I have developped a project with one main VI and severals subVIs. This project is working properly but now I want to make some modifications. Then I have created another folder with a copy of this program (kind of security copy). However, when I open the new version, there are conflicts with the subvis of both versions(the old one and the new one). And I wouldn't like to make some changes and to modify the security version and every time I open one version have to be resolving all the conflicts either.
Do you know any way to avoid this problem?
Thank you!!
Solved!
Go to Solution.

If you are not using revision control software, a simple trick to store a "backup" copy is to zip the entire folder that contains your project. Especially if all your files reside within the folder.
R

Master iPad configurator question concerning cart syncing with different versions of iPads.

I have a question concerning configurator syncing.Can the master iPad be a different version of iPad than the other synced iPads? For instance can iPad 2 be the master iPad to a group of iPad Air's? The iPad 2 has some fewer capabilities than the Air, would some settings or restrictions be left off of the iPad Airs if they were set up this way? Thanks.

There is no such thing as 'master iPad'. If you're using Configurator or Profile Manager control of the setup is done from a Macintosh.

Running executables that have been compiled with different versions of a same vi

I am writing a LabVIEW 7 program on Windwos (NT 4.0 up through XP) that will have to simultaneously call and run at least two executable modules. Both of these modules will be written using some of the same utility vis from my user libraries. How can I run the two modules if they have each been compiled using different versions of the utility libraries (i.e. the two executables will have vis with the same name but with slightly different code)?
I know i could dynamically call each vi by reference node, but that can get a bit cumbersome with dozens of vis...

Hi meludwig,
Unfortunately, LabVIEW keeps track of the different VIs in memory using the VI's name. Therefore, if you want to load multiple executables that use the same VIs but with different code, you will want to rename those VIs. LabVIEW cannot distinguish between 2 VIs with the same name but with different code. Dynamically calling the VIs using VI Server, like you mentioned, will also potentially cause problems because the executables might try to load same VI name into LabVIEW memory at a time and this will still causes problems.
My suggestion would therefore to be to rename the utility VIs to another name and save it as a custom subVI in that program. Then, make sure to include that custom subVI in the App Builder executable and you should b
e golden.
Kileen C.
NI

Controlling different versions of LabVIEW

Similar Messages

Maybe you are looking for