NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem calling more than one instance of a dll from TestStand

Hi,
I've posted this message in the LabWindows forum a few days ago and haven't gotten any answer. I have made a DLL with the evaluation version of LabWindows 7.1 to connect to a Telnet server and perform various commands. This DLL is used with TestStand 3.1 . In TestStand, I have to connect simultaneously to the same Telnet server twice to start an application with both of those connection, with different parameters. I use Threads in TestStand to call the DLL and everything seems to be fine on that side. I enter the DLL at the same time for both threads but it seems that the 1st thread waits until the 2nd thread is at the end of the function before he executes the InetTelnetOpen command to start the Telnet session. Is it normal that we can only have one Telnet connection at a time?

To see that I've placed some time stamps in a log. For the first Thread, almost a minute passes by between the first 2 time stamps but in the 2nd thread it take less than a second.

Yet, they both wait for eachother to exit the DLL as the time stamp at the end of the execution is the same.

I really need some enlightenment here 😉

Louis
0 Kudos
Message 1 of 5
(3,374 Views)
Hello TiWi,

I suspect what is happening is that the code in one thread is block the code in the other thread at the InetTelnetRunScript command. What is the TimeOut value you are passing to this function? The default timeout value is 25000 ms (25s). If you reduce the timeout to 50ms, do you see behavior closer to what you expect?

Thanks.
0 Kudos
Message 2 of 5
(3,357 Views)
I agree, after further investigation I believe that's what's happening. Actually in InetTelnetRunScript one of the script item runs a program for 1 min, in both threads. The timeout value that I am passing to the function is about 150000ms to give it a bit more time. If I reduce the timeout to 50ms it will timeout before my program ends, therefore they BOTH need to run the script for ~1 min. Now, is there a way to avoid being blocked by multithreading protections? Different executions, loading the dll twice in memory?

Thanks a lot!

Louis
0 Kudos
Message 3 of 5
(3,347 Views)
Tiwi,

The blocking that InetTelnetRunScript does is probably there for a reason. That method is probably not safe for multiple threads to call into at the same time. There is likely another way to do what you are trying to do that can be done in parallel. Perhaps with lower-level telnet function calls. I recommend you post to the CVI forum asking if there is another way to do what you are trying to do from multiple threads in parallel. This does not sound like a teststand issue. If you are calling into your dll from multiple testand threads, then the code in your dll function is being executed in parallel. The cvi function you are calling however, might not be reentrant (reentrant means able to be called by multiple threads in parallel) so it is making one of your threads block until the other completes. I suspect there is a different way to do what you are trying to do that will not have this problem, but I think the changes that you will need to make will be in the dll and not on the teststand side. I recommend you post to the CVI group and explain what you are trying to accomplish and see if they have a solution for you.

Hope this helps,
-Doug

P.S. Each process on the Windows operating system (of which teststand is one) can only load one copy of any particular dll at a time. Also, loading multiple copies is not something that would be likely to solve the problem you are running into. One possibility is to use the call executable step type and create an executable that does what your dll function does, but that is probably not the best solution and might still end up blocking at the same location. The best solution is probably to use an alternate method of accomplishing whatever you are trying to do with the telnet function you are calling that does not have the limitations of that function.
0 Kudos
Message 4 of 5
(3,332 Views)
Thanks for your help dug. Now that I know the problem can't be fixed in TestStand I will keep working on the CVI side. I had started a thread last week and I am starting to get feedback.

Regards,

Louis
0 Kudos
Message 5 of 5
(3,327 Views)