Sequence frame not updating, TestStand 4.2 with DOORS

[Manooch_H]

Lars -

Did this fix the menu dropdown issue you had mentioned before as well? Which menus did the slow down apply to? Could you replace the old version of the TestExec.ini file in the <TestStand>\CFG directory and see if the problem comes back?

If the problem does re-appear when replacing the original TestExec.ini file, could you provide both the original (bad) TestExec.ini file and the new (good) TestExec.ini file in a zip file attached to this thread?

[lars]

Yes, when I restore the old ini file, the problems return. I have attached the good and bad ini files.

Another interesting effect is that it takes about 10 times longer for TestStand to start with the bad ini file.

Message Edited by lars on 02-24-2010 03:37 PM

[Mac671]

Since I'm that collegue 🙂 can I get some kudos? 😛

Yea I know I'm terrible 🙂

[Manooch_H]

lars -

I looked at the two TestExec.ini files that you provided and noticed two things in particular:

1. You have added the <National Instruments> directory as one of the TestStand Search Directories. Additionally, you've placed it higher in the order of Search Directories than the <TestStand> directory. Furthermore, you have enabled the Subdirectory Search feature for the <National Instruments> Search Directory. This is not recommended practice.

The <National Instruments> directory contains directories for all NI software installed on your machine. Searching this directory and all of its subdirectories will surely slow down performance. Furthermore, placing this Search Directory higher in the order than the <TestStand> directory can cause unexpected behavior such as the behavior you were seeing with the Profile Resource Usage tool. TestStand uses relative paths heavily and these relative paths rely on the Search Directories to find necessary files. Search Directories are used in order, so with your configuration, you never know what version of TestStand a file will be pulled from.

For example, you might be in TestStand 4.2, but may unknowingly be using the TestStand 3.5/4.0/4.1/4.1.1 process models or tools (depending on whether you have the version installed), or you might get lucky and used the TestStand 4.2 versions. This is likely the reason you were seeing the Profile Resource Usage tool crash TestStand, as it was probably attempting to load a dependency that it should have found in the <TestStand 4.2> directory but instead found in some other <TestStand x.x> directory. Never the less, I have asked R&D to look into the crash in an effort to see if we can provide a more useful error without taking out the TestStand process.

2. You have unchecked the Reserve Loaded VIs for Execution option of the LabVIEW Adapter Configuration dialog. Again, this is not recommended practice. Reserving loaded VIs for execution ensures that you can share LabVIEW references from a VI in one TestStand step to a VI in another TestStand step. There is practically no use case for unchecking this Adapter Configuration option. I strongly discourage you from unchecking this option again in the future.

Hope this helps explain things. Thanks again for providing your copies of the TestExec.ini file so we could get to the bottom of this.

[lars]

Hi Manooch,

I don't recall even configuring the search directories. The Beta version ran so bad from the first time I ran it that I gave up before digging into configuration. They may have gotten inadvertently set as a result of TestStand's insistence on setting paths as sometimes the wording gets overlooked when the user responds to the dialog box. I often have to go back and manually change the search paths as the default dialog is bad about giving options to go to a directoy instead of a single file. So, good catch, I'll pay better attention in the future.

The Reserve Loaded VI's option is generally turned off due to performance issues and to allow debugging in real time. We have found that execution is much smoother with the large test applications we develop (several million lines, week long execution times, etc.) if that option is false. About the only time we do turn it on is when we must run background applications and distributed test applications with network communications. Interestingly, I have found very few use cases where it is desirable to have that option true, I would be interested in getting more information on the intent and thinking behind it. We share references via either TestStand variables or LV functional globals most of the time, depending on the application.

Thanks for digging into the files. It often takes another set of eyes to catch things that are normally obvious and easily overlooked. We'll try to keep  a closer eye on these options in the future.

[Manooch_H]

Lars -

Below is the text for the Reserve Loaded VIs for Execution Help:

"Specifies if LabVIEW reserves each VI to run when TestStand loads the VI. When a VI is reserved for execution, any references the VI creates during execution remain valid until the VI is unreserved. VIs LabVIEW reserves take less time to call."

"The Reserve Loaded VIs for Execution option eliminates the need to use permanent reference VIs for sharing LabVIEW references between step modules.

You can create a reference in a VI called by one step in a sequence, use the reference in a VI called by a second step, and close the reference in a third step. For example, you can create a file refnum from Open File, use the reference in Read File or Write File, and close the reference using Close File when you no longer need the reference."

The interpretation of this text is that references that are created in a LabVIEW code modules, will not be valid from one code module to the next if the Reserve Loaded VIs for Execution option is not checked.

Are you sure that you pass references back and forth from your LabVIEW code modules using TestStand variables, because this should not be working if you have unchecked this option. I know that Mac671 had run into this problem in the past when trying to pass .NET references from one LabVIEW code module to another.

I've attached an example that clearly demonstrates this. You can run this example in TestStand 4.0 and later, with LabVIEW 2009. You will see that if you do not have the Reserve Loaded VIs for Execution option checked, you will get LabVIEW Error Code 1. If you do check the option, the sequence will run successfully.

Hope this helps.

Message Edited by Manooch_H on 03-03-2010 01:59 PM