operator interface crashes in Windows 2000

[versebandit]

Whenever I get a test fail using the TestStand v2.0 Operator interface on Windows 2000, instead of the sequencer indicating fail, it returns to the serial number entry panel and indicates that the sequence is stopped. I cannot restart and have to kill all threads. Why is this happening?

[Jason F.]

Hi Versebandit,

We will need a little more information about your situation in order to help you. Please consider the following questions and suggestions:

Which Operator Interface are you using (LV,CVI,VB,or Delphi)? When you are saying that your test failed, how do you actually know that it did since the pass/fail banner didn't pop-up, are you actually saying that an error occurred and you chose to continue or abort? Does the same behavior occur when running the sequence in the Sequence Editor? What happens when you run one of the example sequences that comes with TestStand in the c:\TestStand\Examples\Demo directory, do you receive the same behavior? If the example runs fine, then there may be a problem with your sequence and single-stepping through it m
ight be of help.

Jason F.
Applications Engineer
National Instruments
www.ni.com/ask

[versebandit]

Thanks for the response. I am using the CVI operator interface. As to the answers to the other questions, I am still trying to sort them out. Win2k isn't our normal OS and I am in the middle of evaluating it. I need to book more time on our evaluation PC to answer the questions, but I was going to do that anyway, hopefully today. I will be in touch.

Steve

[versebandit]

I now have a bit more info. The behaviour exists no matter what sequence I run (i.e. including samples). The batch runs fine the first time. When I select next batch, the serial number entry panel comes up just fine. I enter the serial number and get a system exception error. I managed to trace the error to Sync With Controller--GetUUTSerialNumber in sequence TestUUTS--Test Socket Entry Point in BatchModel.seq, but I can't find any reason for the error. I am able to step through the above sequence no problem, but when I step back out into the calling sequence, the error occurs. Any ideas?

Steve

[Jason F.]

That is peculiar, because there have been no reported instances of the behavior you are describing, and if I run the c:\teststand\examples\demo\c\computer.seq example sequence in the CVI OI using the BatchModel.seq I cannot reproduce the error you are describing.

Are you using the original unmodified BatchModel.seq process model file located in c:\teststand\components\ni\models\teststandmodels directory? Or have you modified it slightly and are using one from the c:\teststand\components\user\models\ directory? If you could run the same example as I described above with the original version of this process model and the error still occurs I would have to say that there may be something unusual with your particular system. Possibly some memory us
age issues or system software stability issues.

Have you tried closing and disabling any other auxiliary software that is running at the same time as you try this? Meaning, exiting all other processes that are not directly related to the OS (i.e. virus scanning software, programs that are loaded on startup, etc...). Do you have another Windows 2000 machine that you could install TestStand 2.0 on and perform the same test scenario I mentioned above? If so, does it exhibit the same problem? Have you tried reinstalling TestStand 2.0 on this particular system?

Since the problem is not reproduceable in house the best things to try are what I mentioned above to narrow down the cause of the problem. Let me know if you can discern anything new after trying these things.

Jason F.
Applications Engineer
National Instruments
www.ni.com/ask

[versebandit]

Thanks. I am actually able to run the samples without problems. It failed last time because I tried running my own sequence first so system stability was already compromised. I did modify modelsupport2.dll, but only in a very superficial way and when I restored it to its original state, it made no difference. I now suspect my own clean up or setup step group functions which make heavy use of the TSAPI. I think Win95 is letting me get away with something that Win2k won't. So the next step is for me to trace those functions and see if I can pinpoint where the exception is occuring exactly. When I found out more I will be in touch.

Steve