Can test setup be chained to instrument state left by previous test?

[dhfx]

Does TS have some way of keeping track of the state of instruments as left by the previous test, so that the setup for the next test will consist only of changing the settings that need to be changed? The idea is to minimize the time required for an entire series of consecutive tests by chaining each from the previous, instead of having each test be completely modular with its own setup and cleanup, as this would involve too many redundant steps. There would be one full setup stage before the first test, and a full cleanup after the last test.

Apologies if this question is too elementary, and thanks in advance for helpful replies.

David Friedman

Sr. Principal Engr.

Symtx, Inc.

Austin, TX

[Dennis_Knutson]

What type of instrument driver are you using? If you are using the built-in IVI or IVI class drivers in your application code, then the IVI driver will remember an instrument's state because IVI has state caching. That's the only thing built-in.

[dhfx]

Thanks for the quick response. We're using NI-VISA and the tests are coded in CVI.   - dhfx

[dowNow]

I've only seen state caching in IVI drivers. I've considered building LabVIEW (object oriented) instrument drivers one level above where IVI drivers are (and at a level below TestStand), and putting state caching in there, but did not implement that. You could also declare a container in your TestStand sequence to track the state of an instrument at that level. But I think it is really a function of each specific instrument, it is not built into TestStand.

Many instrument calls go pretty fast. Do you really need to save every ms, that's kind of an optimization step. Maybe you could just cache the ones that take a long time.

This is a pretty common design tradeoff, do you want self-contained steps/tests that can be moved all around with ease, or do you want a more brittle, but optimized sequence. You could always have one "big" setup group before all the tests, then have each test just do the extra settings they need, like you mentioned at the end of your post. Just a few thoughts.

Chris Clark

[dhfx]

In terms of optimization, we're trying to squeeze out as much as we can from a multi-test, high-volume process. I've already come around to realizing that TestStand has nothing to offer here and that we'll need to do our own drivers which cache the instrument state and only issue commands if something needs to be changed; that way at least it'll be transparent from the test-code level. I don't think we could use IVI drivers because we have some non-generic instruments, like a vector network analyzer.

- dhfx