programmatically get Labview Editor bit Version

[Xite]

We have a build process. Now we like to support 32bit and 64bit version of LabView.

Who can i identify which version the actuall running LabView Editor has?

Because, we like to separate the build VI into different folders and commit them to version control.

I found a few answers, but this functions delivers the same version number for 32bit and 64bit of LabView:

How Can I Determine the LabVIEW Version That Was Used to Save a VI?

Get VI:Editor Version Method

How Do I Determine Which Version of LabVIEW I Am Using?

[Norbert_B]

There are many "indications" which enable you to see which "bitness" your LV development environment has.

1. Open "About LabVIEW" window in LV (Menu item: Help)

2. Locate the installation directory:

• C:/program files/National instruments/.. would be the 64bit version on 64bit OS.
• C:/program files (x86)/National instruments/.. would be the 32bit version on 64bit OS
• 32bit OS only supports 32bits LV

3. Start Menu item from Windows possibly shows directly e.g. LabVIEW 2014 (32bit). I think LV 2013 already had this, not sure though.

4. With LV 2014, NI introduced a different Task Bar icon for the different bitness: 32bit is brownish, 64bit grayish

hope this helps,

Norbert

[Xite]

Thanks Mr. Brand,

i know that visually i can see that at a lot of different places.

But i like to get it programmatically.

I like to build my VI via the build.vi inside LabView. So i start at the first time LabView 32Bit editor and build it to the 32bit folder. Then i start LabView 64bit and build it to the 64bit folder. All in the same project build folder.

      Tool_XY

            |

           V

       builds

            |

            V

32bit      64bit

The build tool should automatically switch to the right folder, depending on the Editor Version.

LabView.exe path is a good idea.

How can i get that path inside a VI?

[Norbert_B]

Use the property node "App.Dir"

Norbert

Hint: i used the "short names" of the property node. Full name starts equally to short name per property. A dot separates the "levels" of objects.

[rolfk]

---

@Norbert_B wrote:

Use the property node "App.Dir"

Norbert

Hint: i used the "short names" of the property node. Full name starts equally to short name per property. A dot separates the "levels" of objects.

---

A much better one, than trying to parse the installation path would be probably App.Target.Operating System.

One may have to get the appropriate application instance refnum, depending if you want to know the bitness of the default instance (no refnum input) or a specific target instance (RT system, project, etc).

[Xite]

Ok, i tried now several things and put it into an test.vi.

The Output for 32Bit LabView 2014 Editor:

And the Output for LabView Editor 2014 64Bit:

What we can see here is that the VI Editor Version stays the same.

The Operating System Version number and installation path are the only two parameter where i can separate the bitness.

Put this can only be a work around. This information is indirect and can maybe change at a new operating system version.

NI should enhance the properties Editor Version and Editor Version Number!

There should be a field for bitness, ServicePackage Number and patch number of the used editor!

[GerdW]

Hi Xite,

NI should enhance the properties Editor Version and Editor Version Number!

There should be a field for bitness, ServicePackage Number and patch number of the used editor!

That's why there is a LabVIEW Idea Exchange!

Post your idea over there!

[Xite]

I know, but first i want to be sure that i not miss a solution, which is already there.

I will write an new idea

[rolfk]

Well, the Target OS can indeed change with newer versions of LabVIEW and since it is an enum that would potentially cause wire conflicts if you upgrade a LabVIEW VI to a newer version, but there is a trick for this. NI only adds new enum items at the end of this enum!

So with this code you avoid broken arrows altogether when loading the code in a new LabVIEW version with extended target OS enum:

It won't support new platforms such as Mac OS x64 in LabVIEW 2014 out of box when upgrading from an older version, but that requires at all times an edit of the VI code to explicitedly add the new enum value. On the other hand, knowing the new labels in LabVIEW 2014 you can edit this code in 2011 to support it and it will work in all versions of LabVIEW from your edit version up to the version you want to support as latest. Obviously we can't at this moment guess what labels might be added in 2015 or 2016, but that problem remains even with your proposed addition of String items. And NI can't just go and chang the existing string text of those properties as some user code may be dependant (and some most likely does depend) on the exact syntax they used in the past and would break if loaded in the new exteded version of LabVIEW.

[Xite]

Ok, wrote a new idea. You can find it here:

Property to get LabView Editor bitness 32bit / 64bit and patch level