rss / atom

An irregular appearing blog about random LabVIEW topics.

How toolkits can break your deployment

Friday 05 January 2018

A couple of weeks ago I ran into an issue with LabVIEW and TestStand. It took me quite some time to identify the problem and find a solution or workaround.
I would like to share this with you all, so all you fellow-wireworkers don't have to spend that time on fixing the issue.

First let me give you a brief explanation on the project where I had the issue.

"TestStand deployment utility should make an installer with all runtimes"

My customer wants to use a combination of TestStand and LabVIEW. They want to implement TestStand sequences to verify their products during and after assembly. These TestStand sequences should use their LabVIEW drivers. These LabVIEW drivers are by-reference classes created with the Open GOOP Development Suite (OpenGDS). During development, sequences and drivers are tested from within the TestStand IDE. When the implementation is finished, a deployment with the TestStand deployment utility should make an installer with all runtimes included to install a test system.

Quick summary of my development environment:

  • Windows 7 64bit
  • LabVIEW 2016 SP1 32bit
  • TestStand 2016 32bit
  • OpenGDS toolkit
  • Viewpoint Systems TSVN toolkit

"Everything worked well until I added displaying an image"

During development of the sequences and drivers I tested the deployment frequently and everything worked well until I added displaying an image to the operator.

After I added this functionality I had conflicts in my deployed LabVIEW project.

I was 100% sure that this native LabVIEW vi was causing the issue. If I removed this vi from the driver, I didn't have any conflicts.

I looked at the code several times, discussed this with my colleagues and we did not find any issues or strange links in the LabVIEW code.

So the only reason why this can happen is that some part of LabVIEW already loads this llb (or vi's in the llb) into memory, prior to our LabVIEW project, and that these files are not in the expected location of my LabVIEW project.

"I started thinking about my installed VI packages"

I assumed it was not LabVIEW itself, otherwise we would never have been able to build and deploy with this ‘draw flattened’. So I started thinking about my installed VI packages.

My first suspect was the Viewpoint Systems TSVN Toolkit (which by the way is an awesome tool to integrate SVN with LabVIEW). This loads into memory at startup and draws overlays in my project explorer, for the VIs that are linked to our source code control. 

I uninstalled the TSVN toolkit and tried a new deployment. This was not successful, the same conflicts remain in the deployed project.

"Both installed addons were causing my issue"

Next one to try is the OpenGDS package. I uninstalled the package and made a deployment. This deployed LabVIEW project was conflict free and I was able to run the code on a machine with only the runtimes installed. Just to be sure that it was only the OpenGDS that was causing the issue, I reinstalled the TSVN toolkit and tried a new deployment. This deployment had the same conflicts again, so both installed addons were causing my issue.

For me it was clear that the TSVN toolkit most likely uses the picture.llb VIs to draw the overlays. It was and still is not clear why the OpenGDS has dependencies to the picture.llb. I think it is the OpenGDS Icon editor but I'm not sure.

After identifying the cause, I still needed to find a solution or easy to use workaround because not using the OpenGDS or TSVN toolkit is not an option. I always use these tools, in every project.

"A solution that popped up was uninstalling the 2 toolkits prior to a build"

My first thought of a workaround was having a separate development and build PC. For us at VI Technologies this is not a big issue but my customer could not have 2 systems because of LabVIEW and TestStand licensing. So I had to come up with another solution.

First solution that popped up was uninstalling the 2 toolkits (TSVN and OpenGDS) prior to a build.  It is quite easy with the VI package manager but time consuming. The VI Package Manager always checks for new versions at startup, which takes some time and the OpenGDS needs a recompile after installing. This recompile takes a lot of time.

"But how do you disable these toolkits?"

The other option was disabling these toolkits prior to a build.  But how do you disable these toolkits?

The LabVIEW.ini file has no option to disable addons.

I did a search in the files of the complete LabVIEW folder on disk with keywords GOOP and TSVN and found some ini-files in the resourceFrameworkProvidersGproviders folder.

"LabVIEW does not load the addons when the ini-files are missing or renamed"

Ini-files are typically used for configuration so I was hoping that LabVIEW would not load my addons when I remove/rename these files. A quick test with deleting these files confirmed that LabVIEW does not load the addons when the ini-files are missing or are renamed.

I created a separate program (executable) with LabVIEW to search in the GProviders folder for ini-files with GOOP or TSVN in the filename and give the user the option to enable or disable.  Disable will rename the file extension to ‘off’ and enable will restore the ini-file extension.

This additional executable does the trick. We can easily enable/disable the addons prior to a build. One thing that we miss in the TestStand Deployment Utility is a pre and post build step.  If we had these options, we could fully automate this workaround.

I’ll never forget this issue and the time that it costed to identify the cause. I’m hoping that this blogpost will help others that run into the same issue.

If you have remarks, comments or additional tips, feel free to leave a comment below.

Best Regards,
Wim Tormans.


Leave this one empty:
Don't fill in data here:
Don't put anythin in here:

Wim Tormans - Thursday 11 January 2018

Hi Cyril, indeed, renaming the vi's could be a solution. However, I can't find this option in the deployment utility. I didn't know that there is an API to automate TSD creation. I checked this and indeed this is very useful to perform pre/post build actions. Best regards, Wim

Cyril Gambini - Friday 05 January 2018

Hi, I think you can rename (apply a prefix) for identified VIs within the TSD. I guess that would have fixed the issue, no? Also, there is an API to automate TSD creation and deployment, I guess your pre/post actions could have been done within a custom builder code. Cyril