From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Timing of TCP read/write?

Hi,

 

I have seen many discussions with similar problems that already solved my problem to some degree. So first thanks for this good forum.

What I am experiencing is a strange timing problem with a TCP conncention between a RT target (CRIO, TCP listener) and a Windows

Laptop with the user interface for the instrument on the CRIO. The Laptop program opens a TCP connection to the CRIO RT system.

 

Normally, only data from the CRIO is sent to the Laptop (data is updated every second, the TCP loop runs twice as fast to get better

response times). Data is stored in Queues and RT-FIFO's on the RT system before they are sent.

Occasionally, data is sent from the Laptop back to the RT system (user interactions, commands).

The system runs fine, when I first writre to the TCP conncetion on the RT system and only then read for possible commands (both interactions

are within two seperate sub-VI's). Before I had it the other way round, first checking for incoming commands from the Laptop and then send the data.

And this did not work, it always gave me error 56 or 66. I do not understand this, can someone explain to me this behaviour? The timeout on the RT

system is set to 1500 (should be 1.5 seconds), maybe too short? Or does it depend on the order of the commands on the Laptop, too? There I first

read data and then send within the loop. The timeout here is set to 5000. Suggestions on how to improve this?

 

Thanks,

 

Olaf

0 Kudos
Message 1 of 3
(3,224 Views)

Hi Olaf,

you got this error because of this fact:

Error 66 occurs if the TCP/IP connection is closed by the peer. In this case, Windows notices that no data is returned within a reasonable time, and it closes the TCP/IP connection. When LabVIEW attempts to communicate after Windows closes the connection, error 66 is the result.

Here are some interessting links you can have a look at:

Error 66 or 1032 on Real-Time with VI Server:

http://digital.ni.com/public.nsf/allkb/E94F4699B7FB82E086256B6E007B0AB3?OpenDocument

Error Messages Received from the Real-Time System Manager:

http://digital.ni.com/public.nsf/allkb/258B701A0F95FDFC86256EA100492F37?OpenDocument

TCP/IP Error Codes and Related Time-out Issues in LabVIEW:

http://digital.ni.com/public.nsf/allkb/D90C4F99C1EF3F6A86256E4A0080A120?OpenDocument

I hope this helps you.

Best regards

Suse

______________________________
Certified LabVIEW Developer (CLD)
0 Kudos
Message 2 of 3
(3,203 Views)

additional:

 

you said

"Normally, only data from the CRIO is sent to the Laptop" and

"The system runs fine, when I first writre to the TCP conncetion on the RT system and only then read for possible commands (both interactions

are within two seperate sub-VI's). Before I had it the other way round, first checking for incoming commands from the Laptop and then send the data. And this did not work.

 

So if you first check whats coming in, the result is that Windows notices that no data is returned within a reasonable time, and it closes the TCP/IP connection (did you open the TCP/IP connection already?).

When LabVIEW attempts to communicate after Windows closes the connection, error 66 is the result.

 

Best regards

______________________________
Certified LabVIEW Developer (CLD)
0 Kudos
Message 3 of 3
(3,185 Views)