LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Read Data over TELNET link

In my application I send some command over a Telnet link and than wait for 'WaitStr' time for some response.

My telnet connection has a TCPClientCB that reads the data into a buffer.

Now, I can get this data in one of two ways:
a) by using ProcessSystemEvents () which will allow the TCPClientCB to gather the info
b) I can call TCPClientCB directly, within the loop ('WaitStr' time) where I'm checkingd the content of the buffer.

Questions:
1) which way is preferrable?
2) I was using so far the first way and experienced problems. I'm not sure I can specify exactly whay happend but it looks as if the CB continue to loop and not allowing to return to the wait loop and also the buffer is exceeding its limit (no matter how big I make it)
. ANy idea?

My procedure (TCPClientCB ) is based on what I found in the CVI samples. However, If anybody can suggest a good routing for any of the 2 different options, it would be most appriciated.

Thank you
0 Kudos
Message 1 of 6
(3,055 Views)
Hi,

The way you implement this will depend on how your data is arriving. If you have chunks of data coming every now and then, a callback fired by ProcessSystemEvents() should be enough to catch the data; however keep in mind that the execution of other callbacks will be executed too, causing you TCP callback to be on hold.

There is also another method that you can use; there is a function called ProcessTCPEvents(...) that checks for TCP events only; you can do some sort of faster polling for your TCP events and a slower polling of the UI.

If the speed is still notenough the you may need to set a different thread for you communication. It is very common to perform communication routines in a separate thread.

I hope this helps, let me know if you hav
e any further questions on this.

Regards,

Juan Carlos
N.I.
Message 2 of 6
(3,055 Views)
Hello Rafi

I suppose the preference between the two methods would depend on how long you have to check the buffer content. One reason I can think of for the problem with the first method you tried is that ProcessSystemEvents processes all events ( TCP, Drawing, button clicks etc..). In the case of TCP, this could mean that everytime you call ProcessSystemEvents, TCP_DATAREADY is called if there is any data in the tcp buffer ( even if you have already read the data). So you might be getting re-entrant calls into your callback.
You could try just a loop with ProcessDrawEVents, but if the waiting process takes a while, you might consider using some of the threadpool functions that CVI provides.

Hope this helps

Bilal Durrani
NI
Bilal Durrani
NI
Message 3 of 6
(3,055 Views)
Hi Bilal and thanks for the answere

1) I did, in fact, experienced a situation where I re-read data...

How could that be explained? When I read the data (upon getting the TCP_DATAREADY) I automatically remove it from the TCP buffer, isn't it so?

In my application the waiting time is around 5 sec, and I only expect a result from the TCP after I initiate a send string. I'm not interested in any random data that the system might send.

2) Meanwhile I implemented a solution by removing the PorcessSystemEvents and poll on the TCP CB function. In the CB function itself I read in a loop all the data into a buffer until I get a timeout. I will add the ProcessDrawEvents in my Wait Loop as you suggested.

Does it look OK to you?

3) I'm quite intereste
d to investigate the use of a different thread for that purpose. But I don't have a clue where to begin.... can you help please?

Thank
0 Kudos
Message 4 of 6
(3,055 Views)
Thank you Juan,

Please see my answer to Bilal. I'd like to get your response as well.

Thanks
0 Kudos
Message 5 of 6
(3,055 Views)
The TCP_READY is an indication that there is some data available to be read. TCP works as a byte stream, so dataready does not actually tell you how much data is being made available, it just tells you there is something there that should be read.
For example, if on the server side, you do 2 tcp write operations, the client will see the data and will fire tcp dataready. The dataready callback will not fire only 2 times though. It will keep on firing if there is any data available on the port.
So if the server writes 40 bytes in the first write operation and 10 in the other, there is no guarantee that the first time dataready fires on the client, all 40 bytes will be available to read. ( TCP optimizes data buffer sizes to make sure you don�t slo
w down networks with many small packets if one big packet can do the job). You will need to keep on reading the tcp port from the first callback until all the data you expected is returned. So if you are streaming data (sending arrays for example), you are responsible to re-creating the byte stream on the client side. If the case of arrays, you might send some header info that would tell you the size of the array coming so you can completely read it correctly.

Since this does take 5 seconds, you might check out some of the threading examples under ..CVI\samples\utility\Threading. You can do the grunt work in a worker thread so the UI doesn�t look like its unresponsive to the user.

I hope this explains things.

Bilal
Bilal Durrani
NI
0 Kudos
Message 6 of 6
(3,055 Views)