Poor TestStand performance on restarting changed sequence

[lars]

I'm seeing ill behavior in TestStand 4.0

On intial run, my sequence will execute at normal speed which seems to be a bit faster than in version 3.5. If I modify a sequence step, then hit F5 from the report screen (finished execution), the programs runs dramatically slower, probably 1/3 to 1/4 as fast. If I close the finished execution and then run the modified sequence, execution speed is normal again. If I try to run the modified sequence from the sequence's screen without closing the report screen, performance is poor.

Under all previous versions of TestStand (2.1 to 3.5), performance didn't change when reexecuting a modifed sequence this way. I am running with binary files if that makes any difference. I'm using run as Single Pass.

I wanted to enter this as a bug report, but was directed here. Sorry if this is in the wrong place.

[AndrewMc]

Hey Larry,

This forum is used in much the same way as email support, except with a community of users.  We can continue troubleshooting this through email and, if necessary, I can file a bug report.  At this point I am not convinced it's a bug.  Since nobody else has expressed this concern yet, I tend to believe that this is not a bug, but rather is most likely an issue with a difference in your configurations between 3.5 and 4.0. 

[Brandon K]

I am also observing slow execution.  I am mainly sending and receiving CAN and serial messages, in 3.5 the execution was very fast, in 4.0 I would have to say it is less than 1/4 the speed.  My tests rely on speed and the only way I have found to get the speed to an acceptable but still not ideal speed is to turn tracing completely off.  But this really hurts my testing because I am unable to see what is failing right when it occurs.  Instead I have to wait until the results are created.

[lars]

Tracing during execution is exactly my concern as well.

FWIW, I am also doing CAN, and I think those tests are the ones most affected. My tests are very serial port intensive, but the ones that don't run CAN seem to be affected less.

[AndrewMc]

Hey guys,

I'm very interested in this problem that you're seeing and would like to try and narrow it down to find out what is causing the problem.  Does this behavior occur in all of your sequences or just some?  Is it only in the cases where CAN is being used?  How many steps are in the smallest sequence that exhibits this problem?  Brandon, if you call one of these sequence files from another sequence file (that is just simply make a sequence call step from a blank sequence), do you see this behavior?

Most importantly, could you either post or email (http://www.ni.com/ask) a small example that I can work with to try to narrow down the problem?

Message Edited by AndrewMc on 06-12-2007 10:10 AM

[Brandon K]

I am unsure what has changed, but now my sequences are running at the same speed as they were in 3.5.  I will continue to monitor the speed and if anything changes I will inform you more detailed on the issue.

[AllenP]

We got to the bottom of this issue.  If you have watch expressions, your sequence may execute slower than normal.  Removing them should speed things back up.

Allen P.
NI