NI Session Manager gets slower and slower from call to call!

[Herbert Koltschik]

I have the following problem with NI-Session-Manager:

I use Session Manager a lot on my test systems. Now that I have a test system running that makes many Session Manager Calls I noticed that after a while the system gets slower and slower. I�ve attached a Sequence File, which demonstrates this problem.
This sequence file is based on the LV Session Manager Example, which ships with TestStand.

Instructions: In the UI-Msg Field of the Sequence Editor you will see how long the actual run took to execute. Every run makes 500 calls to Session Manager. You will notice that every run takes a little bit longer than the previous. After 100 runs the difference is significant.

Although my example uses a COM
port to demonstrate the problem this problem is really related to Session Manager because the same happens if I use an IVI-Instrument (i.e. NI-DMM, NI-Switch, �)


Any help appreciated!

Regards
Herbert
*********************************
Herbert Koltschik
Sagem Communication Austria
herbert.koltschik@sagem.com
*********************************

[Scott_Richardson]

Herbert -
The Session Manager is not slowing down. Instead LabVIEW is using up more memory because it is adding new references to the InstrSession to its internal cache. This is slowing down LabVIEW. Everytime TestStand calls the VI, the VI creates a new ActiveX InstrSession object. LabVIEW maintains all references to all open objects, but LabVIEW does not close them automatically until the VI is unreserved by TestStand. If you close the InstrSession in the VI, LabVIEW will instructing SMgr to close the VISA handle. What you need to do is to get the refnum once and save it in a global.

See attached LabVIEW 6.1 VI that has the changes necessary.

Scott Richardson(NI)

[Herbert Koltschik]

Hello Scott!

Thank you for you instant and precise answer.
With your help I was able to fix the problem. The affected production stations now run flawlessly since days.

Although the problem is fixed now, I have a few comments:
1) In the next release of TestStand the LV Session Manager Example should be updated to make this point clear.
2) For my point of view this is more a bug than intended behavior. Now that we have Session Manager, a centralized resource management system, I really do not understand why I have to build my own resource management system in LabView by getting the refnum only once from Session Manager and storing it in a global. This is reinventing the wheel! For my point of view really counter productive.

Best Regards,
Herb
ert

[Scott_Richardson]

Herbert -
Thanks for the feedback. I will look into item (1).

The design of the session manager was to solve the problem of only having to share an instrument within a multithread application. If the session already exists, than you get the same session and thus the same handle, and the instrument is only initialize once and closed after the session no longer exists.

In the case of a C++ based program you would have to add the session as a member variable that has a specific lifetime. When the object is release, so will the session.

In the case of an application like TestStand, you just attach the session to the execution. Once the execution goes away, the session may go away if no other execution is using it.

In the case of L
abVIEW being called from TestStand, you are using VIs as subroutines, so either the application (TestStand) must manage the lifetime of the session, or the VI subroutine must deligate the lifetime control to a "global" VI. The item you attach to the global could be the refnum itself or the SMgr session. One way of doing this would be to create a VI that serves the refnum to you but internally manages the lifetime of the ActiveX references to the Session Manager sessions. This would be a simple vector of names and their sessions. When called the VI would lookup and return a refnum from an existing session or create a new session and return a refnum for it.

Scott Richardson

[Scott_Richardson]

Herbert -
I reviewed the TestStand 2.0 example.

Looking at the example's VIs, the first VI that the sequence calls gets an InstrSession and stores the reference to a local variable in TestStand. All other subsequent VIs acquire their own reference(which will be the same handle). I did notice that these subsequent VIs are failing to release the InstrSession right before they complete. They need to do this to ensure that their reference to the session is released. Since the local variable has a reference, the handle will not be closed until the sequence completes.

We will update the VIs and add comments in a future release.

Scott Richardson (NI)