NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Update step limit name at run-time

Solved!
Go to solution

I need to run through some test steps in a TestStand sequence multiple times.  This wouldn't be a loop on a single step or group of steps but probably a goto a label "for" loop in TestStand.  BTW, TestStand 2.0.1 calling code from a LabWindows/CVI DLL via the standard prototype adapter.  Each iteration I need to have the test step limit names be updated with a different suffix.  So step1 might have results0 and results1 and on the 2nd run results0 would be renamed to results0b.  How do I update the limit names, at run-time, from a LabWindows/CVI function?  I.e. the first test in the sequence's Main would update the steps below it to update the suffix.  I started down the path of using TS_SeqContextGetProperty to get the sequence handle

 

TS_SeqContextGetProperty( testData->seqContextCVI, &errorInfo, TS_SeqContextSequence, CAVT_OBJHANDLE, &seq_hndl );

 

then using TS_SequenceGetNumSteps( seq_hndl, &errorInfo, TS_StepGroup_Main, &num_steps ) to determine the number of steps in the Main tab.  

Enter a for loop:

TS_PropertyGetValString( testData->seqContextCVI, &errorInfo, buf, TS_PropOption_NoOptions, ( char ** )&rslt_name ) with buf as "Sequence.Main[0].Result.Measurement[0]" errors out with an invalid name message.  The idea is to get this value, update it based on the iteration in TestStand ( this is already acquired and working ), and then set the value back.  Then, move on to the next step and so forth.

 

Any suggestions?

Thanks.

-G-
0 Kudos
Message 1 of 7
(4,143 Views)

I think I found what enough guidance here: http://zone.ni.com/devzone/cda/epd/p/id/1181.

Programmatically Changing the Measurement Names for a Multiple Numeric Limit Test Step

 

 

 

-G-
0 Kudos
Message 2 of 7
(4,137 Views)

So, I tried the example and it works but only for a single step.  I've tried two options:  1. having a single step that programmatically changes all the result names in all the other steps in the sequence. 2. having each step update the result names itself.  For thought 1 the loop would run and the changes would occur but when the function was exited I'd get an exception from TestStand.  No real information in the details as it looked like a memory corruption error.  I then examined the details of what occurred and tried more experiments.  If I had the loop have more than 1 iteration this behavior occurred.  If I comment out the set function it still occurs.  Then, for thought 2, it works like a champ on all the steps until I loop back to the top of the sequence.  Then, on the first step ( 2nd time through ) it bombs out.

 

Attached is the code for the 2nd possible solution.

 

Does anyone know what the problem is or if there's a way to do this?

-G-
0 Kudos
Message 3 of 7
(4,000 Views)

Hello Grasshopper,

 

What do you mean by "it bombs out"?

 

An error code or message can be helpful to know why this is happening.

Tarek B
Applications Engineer
National Instruments
0 Kudos
Message 4 of 7
(3,976 Views)

TestStand throws an exception and says memory can't be read at some address ( it varies ).  -17502 is the TestStand code.

-G-
0 Kudos
Message 5 of 7
(3,964 Views)
Solution
Accepted by Grasshopper

Unfortunately, TestStand error numbers are not exclusive, so it might not be any of the below cases.

 

I saw a case where this error could be caused by not properly declaring variables used by the DLL function.

 

It could also be that the DLL is not properly released after the first run, thus causing the error during the second run.

 

Another time it shows up is when CA_DiscardObjHandle and CA_FreeMemory are not correctly used.

 

It seems to be a memory related issue, as you mentionned. Let me know if it's any of the above situations.

Tarek B
Applications Engineer
National Instruments
0 Kudos
Message 6 of 7
(3,937 Views)

I had freed a string with CA_FreeMemory and then didn't set it to NULL.  At the very end of my function I check for unfreed handles/strings and free.  In this case, the freed memory was being freed again since CA_FreeMemory only doesn't free the memory if the argument is NULL.

 

Thanks.

-G-
0 Kudos
Message 7 of 7
(3,931 Views)