LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Continuously Read data via TCP

I am implementing a TCP connection between MyRio(client) and Python(server). The goal is to send data from the server to the client, perform some calculations, and send the result to the server. I need to keep changing the data being sent to the client. I noticed the first data works fine and the result returned to the server, but the client could not read subsequent data. I debugged and was able to detect that the error is coming from the first read function is the "Reading values subvi"  but I don't know how to correct it. How do I go about it?

I have attached the files below.

Download All
0 Kudos
Message 1 of 4
(2,989 Views)
Spoiler
 

Hi Davidkor, 

To begin, why are you opening the client's connection at each iteration? I think it would be better to initialize as your TCP client outside the loop and then store the connection ID in the shift register. You can always check if the connection is still maintained when trying to send ( or receive) any command from the client's side. It is also important to implement such a robust data exchange protocol on the server's side.  Attached Read/Write TCP methods that perform the actions that I have described. To use these methods, you will have to wire the TCP connection ID as an input and use a FGV that stores the connection's parameters. This FGV shall be called in theses methods that I attached to handle the case in which the TCP connection has to be reconfigured in case of error.

Second, unless you attach your SubVI that is generating the error, it will be complicated to figure out what kind of error is happening in your code. To have a precise help, you can also mention which error occurred in your code (text and code). 

Best regards, 

Mourad FAKHFAKH, Certified LabVIEW Developer

0 Kudos
Message 2 of 4
(2,954 Views)

Hi Mourad,

 

Thanks for your input. I have attached the subVI causing the error. The error caused is error 56 on the second iteration and error 63 subsequently.

Between, the Read and Write VIs that you attached both have unwired terminals.

0 Kudos
Message 3 of 4
(2,933 Views)

As I said in the previous message, the unwired part of my code is meant to be completed with a FGV that stores the TCP parameters ( IP address and port). This is ment to centralize the TCP configuration so you don't have to type these parameters more than once in your code. This is way simpler to handle a configuration change. Since you use different modes of TCP reception ( Immediate and standard ), you will have to make the mode choice as an input in the Receive TCP Vi that I have attached (After adding the FGV that completes the code) to make it fit the design in its actual implementation.

 

To make it simple, I think that a possible explanation to your problem is an error that is not handled on the TCP read node output in the Reading Unknown Bytes from TCP SubVI. You may start by precisely checking in which part of your code the error is occurring (try the conditional probes on the TCP nodes error outputs)

 

I may suggest a modification in the client/server protocol that your design implements. If the message length from the server is unknown, you may implement a finish character or a CRLF mode reception. This may help you simplify your code and avoid calling the TCP read node multiple times for a same message.

 

I am not sure that I understood what kind of protocol you are trying to implement between client and server, just make sure to handle any timeout and eventually to log the received/sent messages on the client side. 

 

I hope this helps a little.

 

Best regards, 

Mourad FAKHFAKH, Certified LabVIEW Developer

0 Kudos
Message 4 of 4
(2,889 Views)