LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Two Telnet read VI's running at the same time interfere with each other

I have a situation where multiple tests must test multiple UUT’s on the same computer. To send commands to and get responses from the UUT's I use a telnet session. The telnet read VI uses a semaphore. Therefore when two separate top level VI's are running, each calling the Telnet read VI, if one Top Level VI is using the Telnet Read VI the other Top Level VI waits for the first one to complete before it can use the Telnet Read VI. This VI is setup for reentrant execution but because of the semaphore it cannot truly be used as a reentrant function. This causes severe problems when trying to communicate with two different telnet sessions simultaneously.

In the past I have avoided this problem by compiling everything into an executable. Then each Top Level program runs completely independently with no interdependences. However, now I am implementing Teststand and I need to call the same Top Level VI's. I need to be able to get information into them and back out of them from Teststand. This means that I can no longer compile them into stand alone executables. I did compile each top level VI into its own Share DLL thinking that then each top level program would have its own library to call upon. This did not work. Even though both top level programs are compiled into their own DLL there is still interdependency when calling the telnet read VI. One program waits for the other to finish reading from its telnet connection before it can read from its own telnet connection. Since I have to continuously read from the telnet connection, sometimes for up to half and hour, the tests do not function simultaneously. How can I get around this? Is there a solution?

Josh

PS The Telnet Read VI I am refering to came with the Internet Toolset package. Attached is a copy of the VI I use to communicat with the UUT's.
Message 1 of 4
(2,387 Views)
Joshua,

I'm a little confused about your question. In the VI you attached, you don't actually open a telnet connection, so I'm not sure about how it works. I suppose the refnum has something to do with it, but I think some additional explanation of how the attached vi fits into the overall scheme might help.

As for using multiple telnet read vis, from what I can tell, if you use multiple Telnet Open Connection vis then seperate connection IDs and semaphores should be created. Then those seperate connection IDs could be sent to the telnet read vis to read those connections simultaneously.

I suppose that if you were able to put together a small example program to demonstrate the behavior, it would help us to get on the same page. And being on the same page always helps!

Tyler S
0 Kudos
Message 2 of 4
(2,361 Views)
Sorry about the confusion.

The file I attached is in the hierarchy of two separate top-level VI's. The telnet connect is opened once and closed once in each top-level program. The ref number is then passed into and out of the VI that I attached. I use this VI to repeatedly send commands via telnet and wait for the appropriate responses. The telnet read VI is given a read line separator and reads from the telnet connection until it matches the read line separator with a text string read back from the telnet connection. If not match is found it times out and creates an error.

I am not sure how to provide an example of the overall scheme since the problem occurs when both top level VI's are compiled each into their own shared DLLs. Those DLLs are then call from Teststand and at some points they are both running at the same time on the same computer connected to two different UUT's.

The question I have is why does one DLL share functions with the other? When one DLL is using the telnet read VI the other DLL waits for the first one to finish with it before it can it use the telnet read VI. If they were both compiled separately each into their own DLL shouldn't they each have their own set of functions to call upon instead of having to share? I know that if the two top-level VI's are not compiled they cannot both execute the same sub-VI at the same time. The only way to get around this is to set the execution property on the sub-VI to reentrant.

I actually fixed the problem by setting the VI I attached and the Telnet Buffered Read.VI (called by Telnet Read.vi) execution properties to reentrant. However, I am still concerned about two separate DLLs sharing sub-VIs. Why does it do this?

Joshua
0 Kudos
Message 3 of 4
(2,354 Views)
Joshua,

After looking a little more at your question, I think I might have some answers. The Telnet Buffered Read.vi needs to be reentrant because that's where the actual read is taking place within the Telnet Read.vi. But in order for this to have the desired effect, it seems that the Telnet Read.vi itself needs to also be set to reentrant. Otherwise, each instance of the Telnet Buffered Read.vi won't necessarily be registered as a separate space in memory. I know this is a little convoluted and I admit that I don't know all the ins and outs of it, but that's what I've discovered so far. Maybe someone else will have something to add to this. I hope this helps, though, Joshua.

Have a good one!

Tyler S

Message Edited by TylerS on 06-16-2005 04:20 PM

Message 4 of 4
(2,339 Views)