Sequence frame not updating, TestStand 4.2 with DOORS

[lars]

This is really frustrating. I've been running TestStand through version 4.1 side by side with DOORS with no problems for several years. I installed TestStand 4.2 the other day and had nothing but problems with the program hanging, screens not updating, and strange screen behavior (multiple tracing arrows staying on the screen during execution for example). The problem was worse with DOORS running, but still present with DOORS turned off. I decided to go back to TestStand 4.1 and the screen udpate problems are still present. I'm hesitant to uninstall TestStand 4.2 as I'm afraid it'll screw something up in 4.1 and force a reinstall of 4.1 which I don't have time for right now. My DOORS version is 9.0.

Any words of advice, tips, tricks, fixes??? My normally stable, reliable test stand is now a constant battle to keep usable.

[StevieZ]

First of all, your TestStand behavior may be unrelated to DOORS. I don't know of any interaction with DOORS and TestStand, what makes you think the two are causing problems? Are you using Requirements Gateway as this could interact with DOORS? What are you system specifications and your processor load when the program hangs and cursors tracing? Can you open your task manager and post back with the memory usage and CPU usage during this time?

Regards,

Steven Zittrower

Applications Engineer

National Instruments

http://www.ni.com/support

[lars]

I believe you are right about DOORS. DOORS doesn't seem to be the problem, but it does seem to aggravate it. I am not running Requirements Manager. Unfortunately, the problem got so bad I could no longer run tests so I uninstalled TS4.2 and am running 4.1 again. 4.1 is running normally: stable and predictable. The hanging problem was present when DOORS was off and removed from memory (reboot and restart TestStand and LabVIEW).

When the hangs occurred, CPU loading was near 0%. Memory was at about 1.2 Gb, almost all TestStand with a little LabVIEW. This is fairly normal compared to what I've seen with TS4.1. The system is a Dell GX745 with 3Gb RAM and a 2.13GHz dual core processor. I'm running two widescreen LCD monitors. Windows XP Pro SP3

[StevieZ]

I am glad you were at least able to get back to a stable state. I actually tested your setup on our end and installed DOORS with TestStand 4.2. They work flawlessly so I'm venturing a guess that something else is causing the slow down and hangs. If you want to further investigate I'd be happy to suggest some debugging ideas. Furthermore, if you get a chance you should read up more on Requirements Gateway and it's integration with both DOORS and TestStand.

Regards,

Steven Zittrower

Applications Engineer

National Instruments

http://www.ni.com/support

[Mac671]

Hi, 

Lars the behavrior that you're describing seems like something I experienced during an NI Class when we had the TestStand I and II course.

We saw that our test sequences were causing huge performance problems when running them. ( LV 8.6.1 and TS 4.2 were used ).

We reported this to the trainer and he figured out to use the 8.6.f1 patch for LabVIEW.

This has fixed the problem.

Maybe this will also work for you.

Cheers,

Maciej 

[Manooch_H]

Macie,

I believe the LabVIEW 8.6.1f1 Run-Time Engine Patch does not pertain to this particular problem. The 8.6.1f1 RTE Patch corrects the following:

"Fixed an issue where the NI TestStand Sequence Editor slows down during certain LabVIEW steps. NI TestStand uses a function to get the checksum of the connector pane of a VI without loading the VI to check whether the prototype of the VI has changed. LabVIEW 8.6 calls this function more slowly than LabVIEW 8.5, especially when you wire an I/O control to the connector pane. This issue was tracked through NI bug ID 124319."

[lars]

Bringing this one back from the dead. I have recently upgraded to LV9 and have tried using TestStand 4.2 again with the same results. I'm not even running a sequence, just going through the menu bar, and TestStand is hanging. It will stop responding to mouse input, then the screen inside the window frame will go totally white, then eventually it comes back. It may take anywhere from 5 to 20 seconds for all this to happen. When I click another menu item, it may do it again, or I may have to click two or three menu items before it happens. When I click "Tools" and "Profile resource usage", TestStand crashes and must be shut down (windows error screen pops up).

Anyone else seen this since my original posting and found a solution???

[Manooch_H]

lars -

Did you re-install TestStand 4.2 on the same computer as before or is this on a new computer? If you simply installed it on the same computer as before, is it possible for you to test this out on a different computer? Does the Resource Usage Profiler tool consistently cause TestStand to crash? Is it the only Tool that causes TestStand to crash or are there other Tools in the Tools Menu that cause TestStand to crash?

[lars]

This is the same install on the same computer. One of my colleagues on a different network, same company, is running 4.2 successfully. I have 4.2 installed on another one of my test machines and it runs much smoother. I don't test with that PC so I don't know how well it runs an actual test. Both machines are running 4.2.0.134. On my test machine, even after switching versions back to 4.1, I still get the wierd screen update behavior where the execution screen does not update correctly. If I ignore it, it fixes itself eventually, but it takes a while. I did not see this behavior until after I had installed the beta version of TestStand 4.2. I do wonder is something left behind from the beta version may be messing with my regular installation.

As to what other things may cause the crash, I haven't dug too deeply into it. That menu sequence caused it to crash the four or five times I tried, so it's fairly consistent. There are a lot of items to click, so I haven't tried too many other combinations.

Message Edited by lars on 02-24-2010 10:27 AM

[lars · Accepted solution]

My colleague suggested deleting the TestExec.ini file in the TestStand 4.2/cfg directory under Documents and Settings. This has made a dramatic difference in how TestStand runs. I did a diff on the original file and the one TestStand created on restart and there are subtle but significant changes. The most notable is that where the original file used all absolute filenames for file locations, the new file uses relative and symbolic file names as described in the TestStand help. The Profile Resource Usage tool does not cause a crash now. I don't know if all of the problems are fixed, but the difference is dramatic enough to move forward. As I mentioned above, I think the old file format may have been the result of a leftover file from the Beta version.