Wait (TimeInterval) takes too long to execute

[Alan_Bentz]

I copied a TestStand 3.5 sequence from another PC (both running XP).

The sequence contains 'Wait' (TimeInterval()) steps.

On the destination PC, these steps now take twice as long as programmed. This PC did not have this problem before.

On the source PC they execute as programmed.

So I tried a new test sequence with 2 steps:

   Wait 2.

   Wait 5.

and watched it run on both PC's. (Both machines set to allow tracing, and with maximum speed).

On the source PC they execute as programmed.

On the destination PC, these steps also take twice as long as programmed: 4 seconds and 10 seconds. And this is odd - the XML results file indicates 7.0xxx seconds execution time.

Any ideas on how to fix this?

[Norbert_B]

Alan,

does the timing on the destinition PC work properly? So if you switch on the PC and let it run for lets say 1h...does the clock tell you that 1h passed?

Norbert 

[Edit]: If it does work correctly, what is the CPU load when you run the example? If you set the waits for something like minutes, does the clock run properly as long as the execution is taking place? 

Message Edited by Norbert B on 09-03-2008 07:09 AM

[Alan_Bentz]

To more completely test the timing, I ran this sequence:

Print

[Alan_Bentz]

To more completely test the timing, I ran this sequence (bmp attached) while LabVIEW ran a VI that displayed the current time.:

    Print TestStand time

    Wait 20

    Print TestStand time

    Wait 60

    Print TestStand time

Also attached is the XML output. It indicates that TestStand thinks that it actually waited 20 seconds, and 60 seconds, and that the total sequence time was 80 seconds. However, LabVIEW and the PC time showed it waited 40 and 120 seconds respectively.

[Josh_W]

Alan,

There is a possibility that the Wait step has been modified on the target machine, and that the version is different from the version on the development machine.  Could you go to your type palette on both your development machine and your target machine and verify that the version of the NI_Wait type is the same?  You can find that type in the NI_SyncTypes.ini file.

[Alan_Bentz]

Here are the NI_SyncTypes.ini files from C:\Program Files\National Instruments\TestStand 3.5\Components\NI\TypePalettes.. The ‘problem’ one is labeled ‘H’. The 'good’ one is labeled ‘R’.

 

I compared the 2 files. Here’s what the differences are:

 

H:

[__Header__]

Path ="C:\\Program Files\\National Instruments\\TestStand 3.5\\

Components\\NI\\TypePalettes\\NI_SyncTypes.ini"

 

R:

[__Header__]

Path = "C:\\TestStand_Autobuild\\Build35\\App\\TestStand\\

Components\\NI\\TypePalettes\\NI_SyncTypes.ini"

 

H:

[DEF, Data.TypeGroups[0]]ForSubsteps = BoolSuperGroup = StrTypes = Objs[Data.TypeGroups[0]]%HI: Types = [0][DEF, Data.TypeGroups[0].Types]%[0] = Obj[DEF, Data.TypeGroups[0].Types[0]]Hidden = Bool

%NAME = "NumericArray"

[DEF, Data.TypeGroups[1]]

 

R:

[DEF, Data.TypeGroups[0]]ForSubsteps = Bool

SuperGroup = Str

(no more text)

[DEF, Data.TypeGroups[1]]

 

 

H:

[CommonResults]

%TIMESTAMP = 1129701122

 

R:

[CommonResults]

%TIMESTAMP = 1129701120

[Alan_Bentz]

I copied the 'good' NI_SyncTypes.ini file to the 'problem' PC, and restarted TestStand. This didn't fix the problem.

[Josh_W]

Alan,

I first have a question about how you are measuring the time that your execution is taking.  You mention that you are using LabVIEW and the computer's clock.  I just wanted to make sure that you know that the exectuion time that is shown in the report is the time that your Client Sequence File took to execute.  It does not include the time spent waiting for serial number entry, writing to a report or database, and any other setup/cleanup operations you may be doing.

How are you measuring the time?  Could you provide a more detailed explanation?

I also wanted to mention one theory that we have.  The TestStand Wait step depends on a Microsoft API called the Performance Counter.  According to the documentation on MSDN for the QueryPerformanceCounter() function:

On a multiprocessor computer, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the basic input/output system (BIOS) or the hardware abstraction layer (HAL).

So one thing you should try is making sure that the BIOS of your machine is up to date.

Another question that we had: Is your machine a dual-core or a dual-processor machine?  Are there any other obvious differences between your development and deployment machine?

Message Edited by Josh W. on 09-03-2008 03:43 PM

[Alan_Bentz]

I measured the actual time by watching the TS 'Trace' arrow. I noted the LabVIEW 'Time of Day' string indicator when the arrow first got to the 'Wait 20' step, when it first got to the 'Wait 60' step, and when the sequence finished.

[Alan_Bentz]

The destination PC (the one with the problem) is a DELL Optiplex GX620. Pentium D CPU. 2.8GHz.

x86 Family 15 Model 4 Stepping 7. I believe it is 'dual-core', but not sure.

The BIOS was version A06. Today we installed the latest version, A11, and also a chipset software upgrade.

After the changes, the 'Wait' steps now wait 1.5x the programmed time. (They were 2x).