Teststand implementation

[Nick1991]

Hi everyone,

At the moment we’re reviewing our teststand framework because we want to make use of “shared instrument drivers” including a HAL from a library but we can’t find a way to accomplish this. With this post I hope some of you guy’s could share how you use teststand in combination with labview (instrument drivers, HAL), .net dll, python scripts, … to have a stable and easy to maintain teststand framework for multiple developers and multiple deployment stations.

Our situation now:

We use a modified version of the batchmodel (included serialnumber input, validation, enabling/disabling sockets/ results reporting to operator). The code modules used for this are stored in a folder relative to the batchmodel.seq. This folder also acts as a “library” for our shared code modules amongst all developers. Then teststand search directories are set to point to this location so that we can use this modules in our product specific sequences. We do not use labview libraries or projects (yet), we just let teststand resolve the path based on the name and the search directories. But, spoiler alert, we now and then have to deal with VI conflicts.

The model (including all code modules in this “library”) are deployed and distributed separately from our product specific sequences. So after deploying this folder, we call it “our model” but in fact it is also a sort of library, it is stored on a network share. All deployment stations are using this model as this is our shared code (serial number input,…). On the deployment stations the search directories are pointed to this location.

Now, if we need some specific labview code, we save it in a folder relative to the product specific sequence file (also not in a project or LV library, just some vi’s).

The problem with the instrument drivers is, they can be used in 2 ways:

• Directly from teststand (search directories)
• As a subvi from a product specific VI

How can we make sure that in both ways the very same vi’s are used? Because, when we deploy our sequence file, the instrument driver becomes a “support vi” and is copied over to the corresponding folder while direct calls from teststand are pointed to our shared “model lib”. This is very confusing and will definitely lead to all sorts of problems.

Any tips and tricks?

Thanks in advance!

[Oli_Wachno]

Hi, 

you are referring to several crucial points here:

Generally speaking: you must clearly define the (potential) UseCases for your Framework to be able to decide what goes where

As a general rule of thumb: the reponsibility of the ProcessModel is to provide a frame, in which arbitrary TestPrograms / ClientSequences can be run.

Using the ProcessModel (and its' directory structure) as library is IMHO a design flaw.

This get's especially difficult, if you are integrating hardware-access in the ProcessModel.

Even more difficult when accessing this hardware (repectively the drivers) vom the ProcessModel as well as the ClientSequence File.

Though I have to admit, our framework is also not completely free from this flaw.

Regarding Search Directories:

If you find yourself in the situation of having to add two or more additional paths to our Search Directory List you should rethink, what you are doing (another one of my rules of thumb)

There are several mitigations for this, like using TestStand Environments or even simpler: using properly organized Project Folders and TestStand Workspaces.

Regarding Process Model Modifications as such:

Sam Roundy held a great presentation, in which he stated that modifying the ProcessModel is only neccessary for some very very rare cases, which I doubted at first. After having an inspiring discussion with him, I am pleased to agree completely.

Currently, we are moving to a non-modified ProcessModel, implementing our UseCases merely with PlugIns.

Let's jump to the LabVIEW part:

I don't think I have to say, that not using Libraries and Projects doesn't scale and is the road to cross-linking hell due to not having namespaces.

So, yes: change this first, since this will make subsequent usage of Code Modules much much easier. 

Caveat: be careful when specifying a project in TestStand when calling a Code Module: TestStand will use a seperate Application Instance for every project, which can lead to troubles if VIs from differnent projects need to communicate.

Allen C. Smith held a great presentation about libraries and dependencies at this years' GDevCon. When starting to use Libraries, this amount of information might be hard to digest at first. Yet it will get clearer as you go

Hope this can serve as a guidance!

Oli

[Nick1991]

Hi Oli,

I watched both presentations and there are for sure some things I didn't knew. So thanks for the links.

Regarding LV libraries: I know and I agree that we should make use of LV libraries. They are going to solve VI conflicts and cross-linking problems. This is something we can implement easilly.

Regarding Process Model Modifications:

I understand why you shouldn't modify these (maintainablility), and also that you should make use of plugins (we also have some).

But let's take a simple example: Serialnumber input dialog and validation. We want this to be the same for each and every test sequence we develop, in a way we can easily change and deploy it.

Options:

• Implement in PreBatch callback in the processmodel (like we did now), processmodel is deployed seperately and changes requires to only deploy the model.
• Implement in Prebatch in each and every sequence file -> This will not allow us to easily change the bevaviour as this requires deployment of every sequence file.
• Implement in Prebatch in Station callbacks, probably this is better than our aprouch because it does not require a modification of the process model.
• Implement in model plugins, same as the station callbacks option

If you don't modify the processmodel, then this shouldn't be deployed because this can be installed as part of teststand installation on a deployed machine. But if the serialnumber input dialog is implemented in a plugin, then how do you deploy your plugins? Together with every sequence file? Then again, we can't modify it in a common place.

So still we need to deploy these plugins seperate from our test sequence files, and then we have the same problem with the code modules which are shared amongst these plugins and our test sequence files.

Regarding teststand projects and workspaces:

At the moment we don't use these anymore, what are they actually used for? We used to deploy from workspace file, but all we did was add every file in the workspace and select this workspace file in the deployment utility. As we did not see any advantages of doing this, we skipped this step and now we deploy it right away from a folder.

[Nick1991]

Hereby a schematic overview of our current setup:

[Oli_Wachno]

---

@Nick1991 wrote:

[...]

Regarding teststand projects and workspaces:

At the moment we don't use these anymore, what are they actually used for? We used to deploy from workspace file, but all we did was add every file in the workspace and select this workspace file in the deployment utility. As we did not see any advantages of doing this, we skipped this step and now we deploy it right away from a folder.

---

Hi Nick,

a Workspace File ofers the possibility to work with different SourceFile Locations. Still the general paradigm applies that distributing your code over too many file locations causes problems, but using Workspaces for this kind of contains this by keeping the Search Directory list "clean"

It is an additional tool for structured programming.

[Oli_Wachno]

Thanks for the picture, this makes things a lot clearer.

I will take a detailed look at it and provide feedback, yet unfortuately I don't expect do make it before the end of this year.

[Oli_Wachno]

---

@Nick1991 wrote:

---

Hi Nick,
 

sorry it took me so long to answer!

Your approach looks well structured: your dependencies point into a single direction, no circular ones, so your Product Programs all point to the same Model code base.

What does your deployment look like? Guess you have a package for the Model Directory and one for each product?

Have you faced the neccessity the run different Product Programs using different versions of the Model Directory?

Are your .net dlls registered in GAC?

[Nick1991]

---

@Oli_Wachno wrote:

---

@Nick1991 wrote:

---

Hi Nick,
 

sorry it took me so long to answer!

Your approach looks well structured: your dependencies point into a single direction, no circular ones, so your Product Programs all point to the same Model code base.

What does your deployment look like? Guess you have a package for the Model Directory and one for each product?

Have you faced the neccessity the run different Product Programs using different versions of the Model Directory?

Are your .net dlls registered in GAC?

---

Hi Oli,

Yes indeed, we have one package for the model and one for each product.

We don't need different models.

So in fact there is nothing wrong with this approach 🙂

Regarding the .net dlls:

Our current dll's are not working anymore (teststand 2024Q4) because they use some dependencies which are no longer accessible in .net core (serial port).

Because of this and some other things, we decided to migrate these dll's to python.