Long execution times for TestStand conditional statements

[JohnG3k]

I have two test stations – one here, one at the factory in China that has been operating for about a year. The test program uses TestStand 3.1 and calls primarily dll's developed using CVI. Up until a couple months ago, both test stations performed in a similar manner, then the computer at the factory died and was replaced with a new, faster computer. Now the same test sequence at the factory take three times as long to execute (30 min at the facotry, 10min here).

I have recoded the execution time at various point during the execution, and have found that the extra times seems to be occurring during the evaluation of conditional statements in TestStand (i.e. for loops, if statements, case statements). For example, one particular ‘for’ evaluation takes 30 ms on the test station here, but takes 400 ms at the test station at the factory (note: this is just the evaluation of the for condition, not the execution of the steps contained within the for loop).

The actual dll calls seem to be slightly faster with the new computer.

Also the ‘Module Times’ reported don’t seem to match the actual time for the module for the computer at the factory. For example, for the following piece of TestStand code:

…

Label1

Subsequence Call

Label2

…

I record the execution time to the report text in both Label1 and Label2. Subtracting one from the other gives me about 18 seconds. However the ‘Module Time’ recorded for ‘Subsequence Call’ is only 3.43 seconds.

Any body have any ideas why the long execution time with the new computer? I always setup the computers in exactly the same way, but maybe there is a TestStand setting somewhere that I have missed? Keep in mind, both test stations are running exactly the same revision of code.

[James_Grey]

Some basic things to look for:

- check if you have and pre-step, post-step, or post-result callbacks that might be behaving differently

- are you using on-the-fly report generation?

- do you dynamically load/unload modules? If so, are your search paths the same?

- are all the settings the same on both computers: tracing? result recording?

- do you have any watch expressions on the slower machine?

[JohnG3k]

- check if you have and pre-step, post-step, or post-result callbacks that might be behaving differently

Nothing significant, nothing that should be behaving differently.

- are you using on-the-fly report generation?

No.

- do you dynamically load/unload modules? If so, are your search paths the same?

All search paths are the same. The same deployment was installed on both machines.

- are all the settings the same on both computers: tracing? result recording?

Both machines have tracing and result recording enabled.

- do you have any watch expressions on the slower machine?

Don't think so. I didn't create any, and I am the only one with admin privileges to touch the computer since TestStand was installed.

I am going to see if they can send me a printscreen of the task manager tonight... maybe that will shed some light.

[JohnG3k]

Got some more results from the factory this morning:

1) Task Manager shows that the TestExec.exe is the only thing using CPU to any significant degree. Also CPU Usage History show that the CPU Usage never reaches 100%.

2) I sent a new test program that will log test execution time in more places. Longer execution times are seen in nearly every area of the program, but one area where this is very dramatic is the time taken to return from one particular subsequence call. In this subsequence I log the time just before the <End Group> at then end of Main. There is nothing in Cleanup. I then log the time immediately after returning from this sequence. On the test system I have here this takes approximately 160 ms. On the test system at the factory this takes approximately 14.5 seconds! The program seems to be hanging here for some reason. Every time this function is called the same thing happens and for the same amount of time (and this function is called about 40 times in the test program, so this is kill me).

[Jervin Justin]

Hi xanjg,

You mentioned that you have tracing enabled on both computers. One thing I would recommend checking is to make sure that the tracing speed is the same on both machines.

Also, have you tried disabling tracing and checking if they still run at different speeds?

Does this happen with all sequences or this particular sequence only? I would try and see if it was something intrinsic to the TestStand environment or something with the code modules. Do they still run at different speeds if you make a generic sequence not using the hardware or perhaps change all the step adaptors to 'None' so the code modules are not called.

Are you using the same version of TestStand on both computers? What operating system are you using?

[JohnG3k]

Problem has been resolved. Seems the database somehow got corrupted during the initial installation of the operator interface. We replaced the database with a new (empty) one, and the test times have returned to normal.