NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Operator Interface not responding

Hi,
 
My operator interface is written in C#. Hi am launching lots of  executions (between 5 and 40). Each execution runs for a while (around 4-5 hours). I am sending few UserMessages to the GUI. Basically, these executions send Telnet messages to UUT and expect for answers. We then do the parsing of these answers using a C# .dll, even if a lot of it uses TestStand calls.  
 
What I noticed is that I am using quite lot of CPU, even though I set the priority of my executions to -1 or -2. After a while, I am always getting my application Operator Interface to be Not Responding.
 
I am completely out of idea where to look at. Is it something common? Is there something I should do  (adding Wait everywhere? ...)
 
Regards,
Alex
0 Kudos
Message 1 of 4
(3,682 Views)
Alex,
 
Based on your description, it sounds like you either have a memory leak or a intensive resource consuming loop somewhere. If your code is consuming increasing amount of memory, it will eventually taken all the resource even if it has a low execution priority.
 
The best way to troubleshoot these problem is to narrow down the problem to a specific section of your code. Try commenting out chunks of your code gradually and see if you still see the same behavior. We also have a tutorial here that could help you with memory leak problem. If you send us a small sample of your code that reproduces this behavior, we'd be able to provide more specific answers.
Regards,

Song Du
Systems Software
National Instruments R&D
0 Kudos
Message 2 of 4
(3,655 Views)

Hi,

It appears that the problems comes from the communication between TestStand and c# using the UserMessages. When I don't send any User Message to my GUI, everything works fine. However, the moment we start sending asynchrones messages (and we send quite a few), even if we don't process them in the GUI (we return immediatly in the user message event handler), the GUI hangs when we have too much of these threads running in parallel sending these messages.

We checked already for memory leak with profiler tools, but it appears there is nothing significant (we can see the types that are created and not released). It does not look like the problem.

Unless you (NI people) tell me it is impossible, I believe there is a limitation in the user messages feature with an operator interface. Probably I will have to modify my tool so that I write in files from my TestStand sequences, and I start timers in my Operator interface to read from these files.

Regards,

Alexandre  

0 Kudos
Message 3 of 4
(3,652 Views)
Is there a reason you are sending these messages asynchronously rather than synchronously? Sending asynchronous messages can become a memory leak in itself if you are sending them faster then they can be processed. Most likely this is what's happening in your case, your executions are probably posting messages faster than they can be handled so the queue of pending messages is growing unbounded.

In most cases it's best to send the messages synchronously. Not only will you avoid this problem, but whatever you are sending the message for will happen synchronously with regards to your executions.

Hope this helps, if you have more questions about this please let us know.
-Doug

0 Kudos
Message 4 of 4
(3,631 Views)