Timing differences between TestStand and Run-time operator interface.

[SGarcia]

I have a sequence I built in TestStand and it calls LabVIEW test VIS. When I run the sequence in TestStand, it will pass the tests consistently, but when it is run within the Run-time Operator Interface, it sometimes will fail some tests. There is an obvious timing differences between running sequences in these two environments. One that we actually measured. The entire test takes about 70 minutes to finish. TestStand will finish running our test vis a minute or two after the same sequence is run with the operator interface. We have been trying to 'tweek' the two timing delays that are in the LabVIEW Run-time Operator Interface Main Messaging Loop and the Main Event Loop (in the 'No Event, Default'
case). The reason is that there has to be less 'overhead' when using the operator interfaces vs. TestStand and running the same sequence. My questions are:
1) How did NI come up with the values that are in the Main Messaging Loop (10 ms)and the Main Event Loop, No Event case (100 ms) to make the operator interface execute like TestStand? Were these delay values chosen such that the operator interface will execute sequences in the same amount of time as TestStand?
2) How can these delay values be quantified so that the execution time for a lengthy sequence is the same regardless whether the sequence is run within the sequence editor or with the runtime operator interface?

[mikeporter]

To answer the questions in item 1:
It is highly unlikely that those loop times were choosen based on anything other than personal preference. Think about it, how could they trim those values to make things match when they don't know how fast your computer is, how much latency there in in Windows, or what else your system is doing? I have several loops in my current project that all run with 100-125 msec delays. Why? Because that's what I always use and it works well to prevent a loop from monopolizing LV's execution time (which is why the delays are there in the first place).

To address the broader question of why the overall problem exists, my guess is that you have a race condition either in the code or your test system. Perhaps also an instrument isn'
t getting all the settling time it needs. Start by looking at the specific test steps that fail. If running the test VI in single step mode or with execution highlighting turned on causes the test to work when it normally doesn't, you have a timing problem.

Sorry this is rather general, but without knowing the specifics of the test and the instrumentation you're using all I provide are hints as to what the problem might be.

Mike...

PS, If TestStand really runs your code that much slower than LabVIEW, I think I'd be asking myself whether TestStand is really earning it's keep... But that's just me...