Hi Mikko,
I think what you want is be possible, but it sounds like might be some bug in your code - getters should generally not throw exceptions.
Maybe try to reproduce it with a clean project and see if you still have trouble with it. If so please create an issue on our Gitlab page.
Hi John,
This is not currently supported. Why would you want to do that?
Hi Mikko, I think itâd make sense to be able to unset the value. Probably the default behavior should be defined in editor settings and in addition, it should be possible to unset values.
Iâm glad you asked!
So say you walk up to the test station, and itâs in an unknown state. Maybe the last test crashed, leaving some power supplies on. Youâd probably just assume itâs in an unknown state. Using DC power supplies as an example (and a good one as I think most test stations would have these), say the switches are also in an unknown state, as a lot of test stations will also have some kind of switching. Before you want to do any switching, youâll want to turn the power supplies off, to prevent hot switching, or worse, damage to an instrument or DUT. So when you run the test plan again, the first thing you want is to turn the power supplies off.
But when the test is done, again youâll again want to turn the power supplies off first. Yes you do have more control when the test plan ends properly (without crashing) using PostPlanRun, but the point is that you wanted them closed in the same order as they were opened, not reverse order, so the instrument dependency here doesnât apply.
Hi @john.berlien, weâve accomplished custom power-down sequences by developing power-down test steps for our various equipment, and then adding those test steps to our test plans, in whichever order is needed.
We typically nest the power-down steps under a Sequence called âPower Downâ. That allows us to easily enable/disable the whole power down sequence, and manually F10 it (for example in the situation you described where the test had previously crashed halfway through).
I think Ideally the power-down would always be handled in Resource.Close. But in situations where different Test Plans need different power-down sequences, we can just use Test Plans for their intended purpose: creating custom sequences. Once caveat is that the user may need to intelligently know when to execute the power down sequence.
I havenât played with custom power-up sequences, but I believe the same could apply. The trick might be removing the relevant power-up behavior from Resource.Open, so it can be handled in test steps.
Hi David, thanks for your response! Yes Iâve seen that as well, actually where power down is handled redundantly in test steps and the Close method. And youâre right, with the current functionality, you would have to take control of resource opening through test steps instead of the drivers, and have the Open method do essentially nothing but maybe connection/status check. If you already have a lot of existing drivers though, this would be a significant undertaking.
Hi @john.berlien, no prob! Fun discussion.
In your original comment, you stated you are powering up Instruments. When I think of powering up an Instrument, Iâm just establishing IO and presetting the instrument to a default state, with no stimulus applied yet to the DUT. So my Resource.Open methods never apply any stimulus to the DUT. Any stimulus to the DUT is subject to change from test to test (and is very order dependent), so all our DUT stimulus is handled exclusively in test steps. Of course, we have very different circumstances and requirements.
Yes thatâs right, and ordinarily it would be fine - but like the scenario I posed, where there is already a stimulus to the DUT (and switching involved in the test setup) before the test plan is even run, say it crashed during the last test or itâs just in an unknown state, then you could have the problem of a stimulus applied when the Open method is called.
Hi @john.berlien, just wanted to share a possible solution to address a similar situation. If you put your entire test plan inside of one sequence, and then a series of cleanup operations inside of a second sequence, if the test plan errors out you can make sure that the cleanup sequence still runs. To do this you need to have Break Conditions checked on the first sequence step, but then uncheck all of the conditions. As you can see in the example below, Test Case 1 is a valid SCPI command, Test Case 2 is a bogus SCPI command and errors out, and the three SCPI commands in the second sequence for âcleanupâ still run. If the tester is in an unknown state, say the PC is powered off during the middle of a test, then the second sequence can be run on its own to clean things up (same as david-wsd suggested).
In the above scenario, even when Test Case 2 errors, Test Case 3,4,5, ⌠will still run with this setup. Is there a way to break out of just the sequence rather than the entire test plan on test step error?
@brennen_direnzo do you know?
@ivan.diep I think you would use the Repeat step as a way around this. Youâd just be repeating once, but is has break out options.
