Code Reuse

[Big jazza]

As I imagine is the case for many TestStand users, the product I test changes during the life of the test solution I provide. Iterations of the product involve minor changes to some but not all aspects of its design, so some parts of the test solution software need to be rewritten, but others can be reused. The test solution has to be able to handle both new and old versions of the product.

I’ve yet to find a satisfactory way of organising the TestStand code which implements this test solution. I’ve tried using limits files to control which version of a TestStand sequence gets called, but this makes the TestStand code difficult to navigate, because you can not click into a sequence from its caller in the Sequence Editor.

What I’m looking for is a way to achieve, or at least simulate, inheritance in TestStand. I could call C++ DLLs to achieve this, but that would entail losing TestStand’s report generation facility, which is not acceptable.

I searched the TestStand discussion forum for "code reuse", and found just one thread, dating from 2001.

Any suggestions?

Mark S

[Norbert_B]

Mark,

as far as i understand your description, you are searching for a solution for something, which is very difficult to solve and has to be done specifically for every project.

There are, of course, a couple of suggestions, but i am not sure if they fit your needs:
a) SOURCE CODE CONTROL: a decent way to do versioning providing code security and (hopefully) documentation. But this will only work for one version at a time, so you can (at least should) NOT mix up different versions within one project.
b) MODULARIZATION: The best way to keep code reusable. If you have a nice modularization, you can just switch modules for a different behaviour. E.g. if dataaquisition changes, just use a new daq-module which has the same set of parameters. The rest of the sequence will not change except for (perharps) limits.
c) PARAMETRIZE: Keep as many settings changeable via parameters as possible. So the set of the parameters define "which version" of the software you will run.

TestStand has an interface to all of those suggestions, where b and propably c is something, i would premise. So, if you have severe problems doing such things in TestStand, you have to make a concrete example.

hope this helps,
Norbert

[Big jazza]

Norbert,

Thanks for your suggestions.

Using source code control isn't workable, because I want/need the same software on all test stations.

Modularization is what I use at the moment, but it makes the TestStand code difficult to navigate.

I also use paramerization. The trouble with this is that I end up with large limits files which are unwieldy.

Mark S