multiple labview versions on single machine

[K1200LT_rider]

I found LabVIEW Version Chooser from DataAct mentioned in a LAVA message.  There was a reply message from someone at DataAct, so I sent them a message through the LAVA site (it didn't give an email address) asking if the utility is still available and if the site will be fixed.  We'll see if he responds.  I looked at his profile and it said he hasn't visited the site since 2006. 

It looks like this might be a great potential OpenG project.

- Brad

[Matthew_Kelton]

Well, I have done a little research and here is some info.  The LV version of the VI is stored in 4 bytes in the VI.  The issue is it has moved around in between major versions.  I cannot see any info as to know where it is within the VI itself (I have not spent any time looking at controls or projects yet).  Maybe someone else can ID a pointer or offset value which tells you were the version info is.

LV5.1:  position 0x8C - 0x8F

LV6.0 - LV 7.1:  position 0x2C - 0x2F

LV8.0 - LV8.6: position 0x24 - 0x27

The 4 bytes correpsond to the LabVIEW EXE version.  Byte one is major version, byte 2 is minor version and revision, bytes 3 and 4 indicate build (which for this exercise is not needed) and I have not quite figured out exactly how NI is using them.  All of NI's builds are 400x.  They represetn this as 0x800x.  I don't quite see how they make the transformation. So, for LabVIEW 8.6.1f1, the value of the 4 bytes is 0x08068001.  If you check the file version info for LabVIEW.exe for 8.6.1f1, it reports as 8.6.0.4001.

For some reason, NI chose not to use the revision for 8.5.1 and 8.6.1.  In 8.2.1, they did, so the the four bytes are 0x08218002, corresponding to version 8.2.1.4002 from the LabVIEW EXE file.

So, it would be pretty easy to write a program in any language to get the VI version and run that when you open a VI to launch the appropriate version.  But, if there is no offset/address to indicate where the version info is, it may need to be updated when a new version of LabVIEW comes out.

Message Edited by Matthew Kelton on 04-17-2009 10:08 AM

[TCPlomp]

You could also use the 'Get VI Version' applicatoin method.

This doesn't load the VI into memory.

Ton

[Matthew_Kelton]

This also handles newer versions of LabVIEW than the method runs in (i.e. LabVIEW 7.1 correctly determines version info for LabVIEW 8.6), so you could write a single program which launches the correct version of LabVIEW based on the version of the VI, and may not have to update it for a new version of LabVIEW, assuming that NI doesn't change basic installation directory structure or regstry structure (depending on how robust you make the VI).