Determining an RT Application Version

[skol45uk]

I am using LabVIEW 2012 SP1, programming a cRIO 9074.

Is there a simple way to determine the version number that a real-time application has been built

1) before deployment i.e. while it sits as a .rtexe on my Windows machine;

2) after deployment i.e. while it sits on my cRIO;

3) and if the application is executing.

On Windows I can right-click a Windows .exe and see File Version, Language, Comments, etc... Is it possible to do the same from an .rtexe?

If not, is there code I can embed in my RT code to make determination possible?

I've noticed that you can set version information within an RT Build Specification, but how you subsequently get at it I have no idea!

Thanks for any help.

[Vijay_J]

You can get the executable version.

Follow the link: http://forums.ni.com/t5/LabVIEW/File-version-info/m-p/361945?jump=true

[skol45uk]

Hi

Sorry if I was not clear, but I am working with cRIO 9074. Not specifically Windows. I may be wrong, but I am not aware that .NET and other Win32 VI support actually exists on the cRIO. I think cRIO's actually run vx-works?!

The .rtexe built will not run on Windows.

There is also no user display, and except for a network port, no way of communicating with the cRIO-9074 once the application is set as a startup and the unit itself deployed.

Thanks

[Vijay_J]

I got that after reading your reply.

.Net as well as Win32 API wont work with RT.

[Vijay_J]

Check if the attached VI works. 

[Greil]

No, your code is not compatible with Real-Time System.

Run button is broken because of Error:

"Wire: Type not supported in current target."

After a decade of having Real-Time Systems, I want this works with Real-Time too:

"Hist.Revision" (History:Revision Number Property)

[Bob_Schor]

I don't currently have my PXI updated with the appropriate LabVIEW RT stuff (I'm running a later version of LabVIEW), so I can't test, but you might see if the Get Build Specification Version (on the Application Builder sub-Palette of the Application Control Palette) works for RTEXEs.  Note that it is still up to you to set the Version Number yourself when you build the RTEXE (or you could write a utility to programmatically set this using the Set Build Specification Version, but be careful as you need to do this before you start the Build, as the Pre-Build Action is not really "Pre-Build" -- there's an Idea (from me) to have NI "fix" this, but they have been arguing that "Pre-Build" does not mean "Before the Build happens" (check out my four-year-old Idea and Kudo it before NI decides that it doesn't have "enough interest" to fix).

Bob Schor 

P.S. -- oops, I didn't notice you were using LabVIEW 2012.  I believe that Get/Set Build Specification Version were introduced around LabVIEW 2014, initially as "Hidden Gems in LabVIEW" in the LabVIEW Tools Network.  Before NI introduced this utility, I had poked around in the Project .lvproj file and found Build Spec information embedded in it, and had written some utilities to parse this file and extract the information, but NI's way was so much easier (and "official") that I abandoned my paltry efforts.

[AshwiniWini]

Hi Bob Schor,

I am also trying to read RT application version on cRIO 9049 and on IC-3173, I tried 'Get Build Specification Version' from Application Builder sub-Palette, but it throw an error while deploying code: 

It seems my RT target is missing mxLvProvider.mxx. After searching on web, i found mxLvProvider.mxx is available for windows not for Linux system. 

Can you please help me to understand how to install that supporting library on my cRIO     OR      is there any other way to read RT application version on Linux system?

Thank you,

Ashwini A Pandit

[rolfk]

---

@Vijay_J wrote:

I got that after reading your reply.

.Net as well as Win32 API wont work with RT.

---

It's not just .Net or the Windows API that is the problem here. This version information is stored under Windows in the version resource inside the PE (Portable Executable) file format for Windows EXE and DLL files. Other OSes have none or different means to store such information. Apple MacOS uses bundles to store that information as part of the executable file (its really a directory structure containing the binary executable resource and various XML files with the information, but the MacOS Finder will treat it as an object that you can't easily browse into.

Linux has in true Open Source tradition no standardized way to do this 😁. Each desktop manager tends to do it in its own way. Accordingly the NI Linux RT build executable do not really utilize the version information that you can provide in the according Build settings in a LabVIEW project! I have solved this usually by adding a specially designated VI to each rtexe build and a pre-build step that extracts the version information from the project and stores it in that VI and some utility function in the exe that retrieves this information from the VI to use in application about dialogs or remote version queries. Unfortunately this does not solve the problem to identify the version of an rtexe file on disk without running it in a target. And to the best of my knowledge there is no way to do that other than adding an additional functionality to above mentioned pre-build step (or maybe rather a post-build step) that would create an extra file along the rtexe that simply is a text file containing the version.

It's these kind of low level problems that always makes me wonder a bit, how much the LabVIEW developers have actually thought about features. It would be relatively little additional work for the LabVIEW developers to provide such features as built in capability. The same mechanisme could have been used for PPLs too, instead of packing PPLs into a PE file under Windows to have that version capability, but leaving all other platforms behind in that respect.

[Bob_Schor]

Rolf,

     Have you submitted an Idea Exchange to add the RT Application Version to the .rtexe file?  I (and other readers of this Thread) would be glad to Kudo it and get the Developers to incorporate these settings.

Bob Schor