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

Question

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
[email protected]
Attachments:
sessionmgr_-_slow_down_problem.zip ‏63 KB

Answer 1

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
National Instruments