LabVIEW Real-Time Idea Exchange

About LabVIEW Real-Time Idea Exchange

Have a LabVIEW Real-Time Idea?

  1. Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
  2. Browse by label or search in the LabVIEW Real-Time Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  3. If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW Real-Time Idea Exchange. Be sure to submit a separate post for each idea.
  4. Watch as the community gives your idea kudos and adds their input.
  5. As NI R&D considers the idea, they will change the idea status.
  6. Give kudos to other ideas that you would like to see in a future version of LabVIEW Real-Time!
cancel
Showing results for 
Search instead for 
Did you mean: 

Add a version number to RT EXE files

Status: In Development

When working in the Windows development environment the application builder has the ability to implement a version number for the built executable. Additionally LabVIEW has the ability to querry this version number through a property node. I would like to see this feature carried over to RT systems as well. It would be very helpful in determining what particular build of the startup.rtexe file is running on the target.

 

14 Comments
Active Participant
Status changed to: Completed

Versioning is an option when you build a component definition file (.cdf), which includes an rtexe and its dependencies. This is an option when you build your rtexe in the Real-Time Application Properties dialog box>>Component Definition. Creating this file allows you to deploy the real-time application using MAX or programmatically with the LabVIEW System Configuration API. You can choose to manually specify the version number when you build the application or LabVIEW will Auto increment the version number each time you build. The first build would be 1.0.0.0 and the next time you build it, it may be 1.0.0.1...etc.

Deborah Burke
Senior LabVIEW Product Manager
Certified LabVIEW Architect
National Instruments
Member
Member

I would not declare this point as completed.

 

.rtexe versions and cdf-versions are not the same.

If I deploy an application direct from the project, the cdf will not be touched.

 

I think, gsussman's intention was the same as mine, to increment the version of an real-time application (.rtexe) each time it is built.

Only with that I can be sure about the correct version of the .rtexe.

From the cdf-version only, I can not determine if the application (.rtexe) had been updated meanwhile.

 

Active Participant
Status changed to: In Development
 
Deborah Burke
Senior LabVIEW Product Manager
Certified LabVIEW Architect
National Instruments
Member

Obviously not "In Development" since 2015 Smiley Wink

However, versioning of RT Targets can be tracked easily when using images.

The image name/version is available from MAX and programmatically.

Systems Engineering
LabVIEW 5.0 - 2018
Member
Member

James,

I agree, image names / version and component definitions are possible solutions to handle a version on RT targets.

Anyways, in both ways you can exchange the .rtexe-File by deploying or FTP-transfer with a newer version without getting rid of it.

 

best regards,

Martin

 

Active Participant
Obviously not "In Development" since 2015

You don't know that.

Member

I would also like to see this completed.  Using the CDF file is a bit of a hack because you have to write your own custom code to extract the version from the XML file and it only works if it deployed in a specific way.  It doesn't prevent someone from deploying code from their local project and getting a different version.

Member

In my developments I have a workaround for this : I store the version number in a constant in the top-level VI of my RT application, and I use a "Pre-Build Action.vi" (see attached vi snippet) to update this constant each time i build the application.

Most often the version string is published by a network-published shared variable but it could be published by many ways.

 

Pre-Build Action VI.png

Yohann L.
Member

Thanks Yohann!

 

This solution looks like it would be a good option for many users and easy to implement/control.  Many years ago I used a diagram constant to write to a shared variable, but could forget to update the constant before a build.  This solution fixes the problem with that method by adding the automation.

Can you also share the contents diagram of the subVI to save people time trying to find the correct properties to drill down to the current Version Information (Major.Minor.Fix.Build) in the Build Specification?

 

Thanks again,

 

James

 

Thanks again,

 

James

Systems Engineering
LabVIEW 5.0 - 2018
Member

The SubVI "Get Build Specification Version.vi" is part of the "Application Control" -> "Application Builder" palette of Labview and the diagram of this VI is password protected.

Yohann L.