LabView TestStand interoperability with LabView runtime adapter

[ThorstenBuchheim]

I would like to get some background information on how the interoperability of LabView and TestStand works.

We are using LabView steps mainly for some minor tasks in TestStand projects.

We do not use the regular deployment way as proposed by NI, but simply use one or more VI folders from which we reference LabView steps.

Deployment is done by copying the whole TestStand/LabView folder structure to the target machine.

We use the LabView runtime adapter within on our deployed systems.

We never mix LabView versions within one project.

Now, we frequently face the situation that the exact same project structure on two different machines has problems with the LabView steps.

So one changed VI runs on one target machine while the other after copy deployment is broken. Due to the same project structure and the virtual drives the paths must be the same.

A mass compile usually solves the situation.

So this is mystery number 1.

Today, I had the same problem, however I did not mass compile the full VI folder but simply some folders which I assumed had changed.

One VI which was referenced by TestStand was not mass compiled and was declared as broken by TestStand.

All I did was opening the broken VI in LabView Development System and nothing was obviously changed by LabView.
I closed the VI  and pressed the Reload VI button on the TestStand step and the VI was working again, however the sequence file now had changed somehow (* at file name).

Another phenomenon:

An existing project on a machine was running with a certain user.

After switching the user, the VI steps of the project were suddenly broken.

My questions?

1) Why do VIs which run in the development system flawlessly  become broken in the runtime?

2) Does the runtime use different search paths than the development system?

3) What kind of information does the mass compilation produce and where is it stored.

4) What kind of information does TestStand store along with the VI?

5) Is there a way to diagnose the problem with the runtime adapter ? With the runtime adapter I cannot open the VI to see what is the problem and in the developer mode it works.

[Teuch1]

Hi

My first suggestion would be to use the deployment tool utility provided in TestStand and build a deployment image and installer, it may seem laborious but the once you are familiar with the build process it becomes much easier.

The deployment tool will only build an image with the files needed. It will also highlight any issues you have with labview code modules,  common problems seen are Vis with the same name, Vis that are not included in a Project, TestStand Paths to the Call module not being relative.Configure the deployment tool to create the deployment image (Teststand sequences, Labview Code modules and associated files) in  Public Folders, this way all users will be able to use the same TestStand search directories.

Test the deployment Sequence from your development machine by simply changing your teststand search directories and Labview adaptor to RTE. Once your happy copy the whole image to the deployment machines public folders.. 

SF..    

[Teuch1]

And... before using the Deployment utility make sure that you are using a TS workspace with TS projects to organise your Sequences and CodeModule libraries.  

[ThorstenBuchheim]

I know about the Deployment utility as mentioned in my post.

I also know about the common LabView issues and how to solve them.

My intention was about getting background information to explain the mysterious behavior of TestStand in combination with LabView.

[Teuch1]

What TS licence do you have installed is it a base deployment?

I believe that the LVRTE does not use the files contained in the C:\Program Files (x86)\National Instruments\LabVIEW XXX folder if only a TS base deployment or debug deployment licence is active. Hence the need to build a deployment image using the TS tool. 

If a development licence is available and has been used then there is a grace period when the development licence will still be active think its 2 weeks which could mask your problem for a while.    Have no doubt that following the correct NI deployment procedure you would find, understand and fix the issues you are seeing. 

[ThorstenBuchheim]

Yes, we use a base deployment, but it is not a license problem. I am aware of this isse.

In case of VIs which are not available in the Runtime environment we build a LLB but this is rarely the case.

As I said, we can solve the problem by a mass compile and on our PC installation where the project is deployed we do not have a LabView development suite installed.

[Teuch1]

The deployment method you use seems open to issues. The NI deployment tool was developed to get round the issues you are seeing

1. Building an LLB I assume manually, with all the labview files that are not present in your development folders must take a lot of time ? You would then need to recompile all your Projects and save them to use the new VI paths and this would require checking every project and of course you would need the development suite to do this?  

Why would you waste time doing this when the TS Deployment tool would do this automatically ?

2. Using your deployment method means that you can't do any testing of your deployed solution until its on the new clean machine.

Using the Deployment tool you would be able to test the deployment image on the development machine, by editing the TS search directories?     

3. Continually needing to recompile the VIs means that probably some of the projects or VIs still have conflicts (VIs found in unexpected paths or more than 1 copy with same name).

Of course you will need development rights to fix this problem. Deployment tool takes care of this.. 

4. Different User logins could well need to use different search directory paths , i have no idea of the file structure you are using so again open to problems with paths. Saving the Deployment image to Public folders would fix this..

Its worth a try using the NI deployment tool, but if not Good luck.. 

SF...

CTD

[ThorstenBuchheim]

Again my intention:

I asked for background information to explain the phenomena listed in my original post, not for a solution with the deployment tool.

Thanks.

[Daniel-E]

First, to clarify a few points:

1) It is not necessary to use a workspace for TestStand deployments. You can specify a directory of source files for a TestStand deployment.

2) TestStand licensing should not be affecting this issue in any way. TestStand licenses do not have any impact on LabVIEW VI execution in TestStand.

Thorsten,

The issues you are describing are likely being caused by the LabVIEW VIs needing to be recompiled. The runtime engine is not able to recompile VIs, but the LabVIEW Dev System can, so this explains why you are able to execute again after opening the VIs in LabVIEW Dev. it also explains why a mass compile fixes the issue.

There are a variety of reasons why this could be happening. One scenario that could cause this to happen is that you make a change in one VI, but the change causes a second VI to need to be recompiled. This could cause a problem if you redeploy only the VI that you changed, because it will not be able to work properly unless the second VI is recompiled, which cannot be done by the LabVIEW RTE alone. This can happen because the LabVIEW compiler will optimize certain operations in the compiled code depending on where data is used--for example, the compiler will try to avoid allocating a copy of an array if it does not need to be accessed by multiple pieces of code at the same time. As you can imagine, this type of optimization might be appropriate for one version of your code, but might not be appropriate if a subVI changes such that it needs access to the array in parallel with the rest of the code. 

The specific example I mentioned is called the Inplaceness Algorithm, and is described along with much more information about the LabVIEW compiler in this whitepaper. This might help explain the reasons a LabVIEW VI would need to be recompiled.

One potential solution to your problem that would allow you to keep your current deployment method would be to use packed project libraries (PPLs). You could have multiple PPLs for different parts of your code that you want to be able to update individually, which would allow you to make small changes to your codebase without having to deploy the entire set of code at once. A PPL is a self-contained set of compiled code that does not change, which should avoid the recompile issue from occurring.

[ThorstenBuchheim]

Thanks for shedding some light on the mass compile functionality.

For us it is no problem to do a mass compile over the whole LabView files.

We are using a version control system which we also use to deploy part or our software to different systems with totally equal setup and paths.

The systems are clones of each other and only the LabView files are changed from time to time and kept in sync.

All systems use the LabView Runtime except for the developer system.

We notice when a VI has been changed so we can do a mass compile of everythin, save the changed files and deploy all changed VIs to the other systems.

As said we do not have complicated LabView project structures so it is easy to keep an overview what is being used.

However, it happens frequently that on the developer system, we do a mass compile, switch to the runtime adapter to assure that everything is working,
commit the changes to the revision control system, and after checking out the changes on other systems, those do not work anymore.

We suspect that LabView modifies files somewhere else than just in the project directory.