Labview not listening to teststand whilst connected to telnet

[NIcurious]

Hi,

I have a telnet connection open to some hardware and I am passing in variables to my labview which is talking to this telnet.

The telnet is running from my command prompt (which I launch as an executable at the start of my sequence in teststand).

My problem is when the command prompt is launched and the connection is made the variables being passed from teststand to labview are ignored (this may be due to labview being single threaded to the telnet session?). I can't stop the connection to the command prompt at all (if the connection is lost the test fails) so I am looking for a solution where I can leave the telnet session running while my labview is still listening to what's being passed from teststand.

I know its this command prompt telnet session causing the issue because as soon as I close it my variables can be seen being entered.

Any ideas are much appreciated

[PhillipBrooks]

Your post is a bit confusing. Let me try to reword it to see if I understand.

1. You have a device that you communicate with via telnet.
2. You can communicate with it successfully using the LabVIEW telnet library.
3. You call a LabVIEW vi from TestStand that uses the LabVIEW telnet library.
4. IF you already have a telnet session open to the device (using windows telnet), the VI doesn't run/complete until you close the windows telnet session.

If this is the case, the problem may not be LabVIEW/TestStand; it may be the device.

Simple test: open up one windows telnet session and then a second windows telnet session. If the second session fails to connect, your device may not allow multiple connections. This is more common with small embedded telnet implementations (lower cost PIC devices with uIP  providing telnet)

[Mark_Yedinak]

Are you using a timeout on your read? Is your read in a separate loop (parallel process) or in your main processing loop? You can create a separate loop that does nothing more than read from the telnet session. Any data read can be passed to some other piece of your code for prcessing. Queues would be the preferred method for passing the data.

If you don't have a timeout on your read you may want to add one. This way you can still read data as necessary but filter out the timeout errors. By allowing the read to timeout you allow other tasks to occur within that same loop.

[PhillipBrooks]

---

@Mark Yedinak wrote:

Are you using a timeout on your read? Is your read in a separate loop (parallel process) or in your main processing loop? You can create a separate loop that does nothing more than read from the telnet session. Any data read can be passed to some other piece of your code for prcessing. Queues would be the preferred method for passing the data.

If you don't have a timeout on your read you may want to add one. This way you can still read data as necessary but filter out the timeout errors. By allowing the read to timeout you allow other tasks to occur within that same loop.

---

Ooo!

One of the LabVIEW telnet VIs (buffered read) is NOT reentrant, but all the upper levels are. This VI effectively blocks other sessions if you set the timeout too long.

We've had to change this manually each time we upgrade LabVIEW. Our TestStand threads performed MUCH better when we manually changed this VI to reentrant:

LabVIEW x.x\vi.lib\addons\internet\telnet\telnet.llb\Telnet Buffered Read.vi

[NIcurious]

No nothing is open until the teststand starts. I then create the telnet connection (via the executable) and the labview is used to make the connection (tell it what port and address).

Once this connection has been made I then have a text box which i want to be able to pass values from my teststand (as an input). I know this connection is made successfully and I can manually type my commands into this input box, but nothing is passed through from teststand.

The problem is once the connection has been made the labview then seems to ignore the input from teststand. As soon as I close the executable (closing the connection) my input values start to be put into the text box so I know it then starts working.

So qusetion: Why is this happening / how can I stop this happening?

(Hope this clears up what I meant)

[NIcurious]

To Phillip Brooks,

I don't think I have multiple connections open,

Number 1-3 is right. The connection is made and I know its talking to the device because manual input into the textbox works while the test is running (I can type my commands). The only problem is ignoring the input variable from teststand.

I am using an only slightly modified version of the telnet example that comes with labview (if this helps).

Labview is ignoring the teststand input to the VI whilst the VI is talking to the telnet

[NIcurious · Accepted solution]

Sorted my own problem I think.

The example provided by labview has a while loop in it. This means it just ends up locked in this while loop after the first time its called. Sorted by removing the while loop (and a tiny bit of editing) which gives teststand a chance to talk 😃