Automatically Adding Build Date To Front Panel

[Taylorh140]

So for a while, I have wanted a good way of identifying my builds and one way is to add build date to the front panel. Typically I had done this manually, I have searched for a good solution for automating this but, but typically the answer is very obfuscated. Then one day I had a thought, I could use VI scripting to generate a VI holding a constant and in a way use it as a pre-processor to make things happen. I'll provide a rough outline and a project of how I made things work. And who knows maybe someone has an even better solution.

I suppose it was kinda obvious that this could be done, now that I think of it. I think lv scripting was introduced in 2012 and is needed for this example. 

First Create A VI that generates a constant via LV script.

Use it in your Top Level VI or wherever you would like the compile time constant to be visible.

Generate a A Pre-build Action.vi that calls your VI generator.

Now you can have compile time constants that are up to date!

I included an example project let me know if the same thing works for you.

 

BuildDateOnPanel Ver12.zip

[jacobson]

I haven't tried this myself but I bet you could use one of the App Builder functions in vi.lib to get the build number of the build specification and add that as well

[ensegre]

A potential caveat: I've used this pattern in the past to generate a VI with a default string value containing build date and git version, and included it in the project I was building. Only, when I tried to use it as a prebuild action, most of the time I got spectacular LV crashes, recoverable only by clearing the compiled object cache. I presume that something becomes stale there if the VI is marked as unmodified but in fact it is during the build. I gave up tracking down the issue, just resolved to run my tag-generating VI just before build manually, with the project closed. That was in LV2014 and 2015 at the time.

I saved some logs; the cryptic errors I used to get were of this sort:

Error 1124 occurred at ... Possible reason(s): LabVIEW: VI is not loadable. (a perfectly loadable and unrelated VI)

DAbort 0x1A7102DF in fpsane.cpp  ... Someother.vi  (another sane and unrelated VI)

The build was unsuccessful. Possible reasons An error occurred while building the application. Either you do not have the correct permissions to create the application at the specified location or the application is in use. Invoke Node in  AB_EXE.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller <APPEND> Method Name: <b>Build:Application</b> Details Click the link below to visit the Application Builder support page. >Use the following information as a reference: Error 8 occurred at AB_EXE.lvclass:Build.vi -> AB_Engine_Build.vi Possible reason(s): LabVIEW: File permission error. You do not have the correct permissions for the file. \=========================\ NI-488: DMA hardware error detected. (NI-488 DMA? WTH?)

Error 1 occurred at EndUpdateResourceA.vi Possible reason(s): LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @. \=========================\ NI-488: Command requires GPIB Controller to be Controller-In-Charge.

Edited May 10, 2017 by ensegre

[Phillip Brooks]

Look for vi.lib\Platform\fileVersionInfo.llb\FileVersionInfo.vi

[hooovahh]

Yeah that's what I do.  I read the build version from the file and display it in the about screen.  I've also thought about pulling in the file creation date which if you are using an installer to install your software, should be the date the EXE was built, and not just the day you copied the file to the computer.  I also set the build number with a pre-build which is the commit number in SVN.  So then you have the major, minor, fix number, along with the commit for source code control, and the file creation date all in the about screen, and reports that are generated so you can look up what source code went with what software.

[Taylorh140]

@hooovahh

If i could be so bold as to ask, and i am indeed very interested on how you use SVN with LabVIEW.  (Maybe we can talk at NI week 2017)

My setup uses tortoiseSVN and no plugins to SCC like the one provided by pushok. 

I have separated compiled code from VIs (although i seem to still get changes that lvdiff describes as no change)

I use externals for components that i use between projects.

What do you use to pull in the current SVN Version? Do you induce a commit during pre-build to help guarantee reproducible builds? How do you manage the configuration of the code in (vi.lib and user.lib)?

[hooovahh]

Sure we can talk at NI Week be sure and flag me down if this doesn't answer your questions.

Over on the dark side I posted some overly complicated code that gets the job done for the most part.  It is a Pre build VI that prompts the user for what you want the EXE build version to be.  If you change it, then the build has to be aborted and restarted (NI limitation).

http://forums.ni.com/t5/LabVIEW/Pre-Build-EXE-and-Installer-Set-Version/td-p/3149028

As for reading this from SVN, I have a VI that calls the C:\Program Files\TortoiseSVN\bin\SubWCRev.exe file.  All you need to do is pass in a command line switch to the fill file path you want the rev of.  Then what is returned from the command line is "Last committed at revision" which I pull out and put in the build.  So my unpublished modification to the code posted is when it is ran it shows the last Major, Minor, and Fix version, and then fills in the Build with what is from SVN.  Then the developer is prompted to change anything they want, but if they do change anything the build is aborted and has to be restarted (again NI limitation).

[Taylorh140]

When Trying this in a larger project I seem to get the following problem:

Error 1017, (I seem to see this error quite a lot since i started working from a networked drive.)  

[hooovahh]

I don't think that is related to the pre build, or setting build information.  It likely has to do with the somewhat finicky application builder.  I used to get build errors all the time when building on top of EXEs that were already built.  I'm guessing you can build it locally or to a new empty directory.  I've been using that pre build on some very large projects without any issue.