07-01-2011 03:35 PM
Hi,
I've done a good bit of searching and can't find anything relevant to the issue I am having. I have created a DLL in CVI containing several functions which I call from TestStand. I also have created a custom step type for each function call. Each function in the DLL has a run-time version and an edit-time version. The edit-time functions each have a user interface associated with them called from teststand. These edit-time functions are put in the custom step-type substep tab under the "edit" category. Before running a sequence with these custom steps the edit-time user interface is launched to allow the user to input values which will be passed to the run-time function. Originally I tried to set up my run-time functions as a "post step" substep in the step type properties. However, the sequences would fail to run because the step settings module tab was blank. I then selected CVI as the adapter in the step type properties and specified a default module for each type. This populated the module tab of step settings like I wanted. However, when I ran the sequence each steps run-time function was called twice, once for the post step and once for what was in the module tab I am guessing. I then went back into the step types and deleted all the post steps. I thought all my problems were solved at this point, however after doing some more extensive testing I still have one bug I have been unable to get rid of.
The problem is that two of my step types have to write data back to TestStand at run-time after they query an external device for it. I know the query works because my text log that the DLL generates shows the correct values. However, the data is not getting written back to TestStand properly. In the run-time functions after verifying valid data has been returned I try to write it back to TestStand using: "TS_PropertySetValNumber(seqContextCVI,NULL,"ThisContext.Step.ParameterValue.NumericParameter",0,(double) ushortint);"
I've checked that this call doesn't generate an error and also used the TS_PropertyExists method to verify that I had the lookup string correct. Both of these checked out so I then added another command which reads the value written to TestStand back immediately after writing it. I printed this to my log file and found that the value is being written to the TS property. So, the problem is that TestStand is setting the property back to zero after the code module executes. How do I prevent this?
Thanks for any input, let me know if anything needs clarified.
Josh Meyer
Solved! Go to Solution.
07-05-2011 08:29 AM
I have tried to find a work around for my issue and cannot seem to correct it. I created alternate step types with "no module" selected as the default module. I set up my CVI run-time calls as "post steps". I am still having the same issue though. At run-time my functions do write to the TestStand property values as I desire (checked this by immediately reading back from the value I'm writing to at run-time and printing it to a log). However, these values still are NULL or 0, depending on their respective types, when I look at them in TestStand after the sequence is done. Why are these resetting? I've spent a good amount of time reading the Using CVI with TestStand manual as well as the help files and am getting nowhere.
Any help will be much appreciated!
07-06-2011 04:00 PM
Well, I've come to the conclusion that my "problem" isn't actually a problem. I had a bit of fundamental misunderstanding of how TestStand works (I don't actually use it, I'm just writing some code that will bring an existing tools functionality inside of TS).
Anyways, what I've learned is that when you write to a property during editting/sequence setup these properties are preserved (so you can set up a sequence, save it, re-open it and be able to run it without any re-configuration for instance). The run time values aren't preserved (unless logged) becuase they are only needed at run-time. For instance, if a user calls one of these functions to pull a value from a controller they are probably doing so becuase they want to verify the value is what they expect it to be. Rather than looking at the value after exection (which is what I was assuming they'd do), they'd set up the step after the "read value" step to test the value it returned. This value is availablein "RunState.PreviousStep.valuename" during the step followint the "read value" step.
Hope I didn't confuse anyone to much, I'm completely new to TestStand.