Specify substep module paths by expression

[SteenSchmidt]

Hi,

One of the only paths (if not the only path) that can't be specified by expression in TestStand is the substep module in a custom test step. A substep module must currently be statically defined.

For advanced architectures it would be nice to be able to define substeps by expressions instead of statically (in one project this was a showstopper to the flexible architecture we attempted to implement).

/Steen

[Norbert_B]

While i understand (and partially share) this request, there is one point which makes the current situation "understandable":

As part of the framework, the step type modules has to be stored on each machine. When keeping them in a single folder, the developers can circumvent issues with equally named versions in different folders as we know from DLLs and similar. So you can refer to that folder as "GAC" (Global Assembly Cache) used in .NET.

As pointed out, i understand your request, but without a use-case requiring such a setup, i do indeed favor the current limitation state.

Norbert

[SteenSchmidt]

The current situation:

So the custom step above can only be configured with an absolute path to Substep.vi, OR the file name Substep.vi allowing for the search directories to kick in (dangerous, and not recommended nor allowed in most of my customers' applications). Thus we're forced to use absolute paths for substep VI's.

Let me exaplain the use case then;

Envision a complete set of test files (VIs, sequences, dlls etc) exported from SCC to this path on a test station: 'C:\Test Environment\20140701-165710100\...'. That is basically a timestamped folder. That test station now makes one run which takes a couple of days (this is a complicated test that is more a CM job than traditional production testing). When that test finishes, reports are generated and the test station is free for new use.

A new use is initiated, which results in a completely new set of test files being exported from SCC, now in a new timestamped folder: 'C:\Test Environment\20140703-104530850\...', and a new test can be run all over.

The idea of the above is that we have a complete history in each of the timestamped folders, and none of which is overwritten by anything that happens in the new test. The last 10 or so runs will be maintained on the test station to revert back to, rerun tests on, and basically for traceability. The timestamp part of the path will change from run to run, so all paths in TS is set up as expressions like "C:\Test Environment\" & StationGlobals.CurrentTime & "\..." except for substep paths, for which we can't setup neither a relative path nor an expression. Those are as far as I know the only paths in TS that does not allow setting by expression.

/Steen

[dug9000]

Why can't you use search directories? It seems like from a technical point of view that using search directories would be a trivial solution to your problem. If you are worried about matching to the wrong file, then disable all search directories except for a single, non-recursive one, to the directory which contains your substep binaries.

Or just use the "Components" directory and then the default search directories will work fine without requiring any search directory changes.

-Doug

[SteenSchmidt]

For traceability it would be necessary (as you say) to specify one absolute search directory to locate that concrete code module. There may not be any chance to load the wrong file by accident. And as the code module file name is the same from SCC version to SCC version, it's necessary to be very careful programmatically modifying the search directory list.

And really, manipulating the search directory list is a poor substitute for being able to make the path by expression don't you think (not even considering the much poorer performance of using thr search directories compared to an absolute path by expression)? Would you consider removing all ability in TS to specify paths by expression to just rely on the search directory capability instead? I would find that a very poor replacement.

I must add that we have worked around this problem, I'm just considering using the search directories one such workaround. And now I'm suggesting the proper solution added to TestStand instead.

/Steen

[WireWeaver]

I'm declining this idea due to lack of community support.

-Trent