error code 1 on tcp read

[mcdonals]

Hello,

I've been trying for quite some time to get a computer that acquires data and stores it to an array to send the data to another computer via TCP/IP using a crossover cable. The two computers send commands and information back and forth to each other using UDP, but to simplify things I wanted to use TCP/IP since the files are too large to be sent in one packet, and I don't want to worry about ensuring they're arriving in the proper order. Anyway, the connection opens fine, but I can't get any data through. At first I had no size specified on the read operation, so I thought that must be the problem, though neither of the computers experienced any errors despite the fact that the receiving computer received nothing. So when I realized I had forgotten to specify a size for the packet, I just created a constant for the purpose of testing the transfer. I created the constant by right clicking he size terminal and choosing create constant. Now when the code reaches this point in the code I get an error 1, and I'm not really sure why. Any ideas?

 Thanks,

-Steve

[RavensFan]

I would suggest posting the VI's that you have created so we can look into them.

[mcdonals]

It's all object oriented, so here's the TCP/IP object for the machine receiving the data (Which is where the error occurs, in the read state of the state machine). Let me know if that's not enough.

[Ipshita_C]

Hi,

Please give detailed steps on reproducing your error through the code you have uploaded. That will give us some insight into what part of the code is producing it.

Ipshita C.

[tst]

Error 1 means invalid input. I'm pretty sure the only way this can happen with TCP Read is if you wire in an invalid connection refnum. I can think of two ways this would happen:

1. The likely way is that you're closing the connection or not opening it before calling the read case. This can happen, for instance, if you wire an error into the VI when you call the init case, as this will cause the create listener primitive not to work.
2. The unlikely option is that LabVIEW is releasing the reference on its own. This will happen if the top level VI in the hierarchy which calls this VI goes idle or is removed from memory. This would only really happen if you start and stop VIs or if you're running the VI dynamically.

P.S. I personally prefer collecting the SR variables into a shift register and bundling and unbundling by name. It helps keep the code much cleaner and more readable.

[mcdonals]

In the time I've spent debugging, I've been checking very carefully to ensure the connection isn't being closed (and that it's being opened), but I'll double check next time I get the chance. I highly doubt that Labview is releasing the connection on its own, because there are various connections to devices on the other computer that are kept the same way, and the code of the two machines is very similar.

As far as the details leading up to the error, basically there is an initialization state in the main code, which opens all the necessary connections. The code does not leave this state until the TCP connection has been established with the other computer. The code then sends commands to the other computer via UDP to either tell it to take data or to see if the data has been already taken. Once it has been detected that the data has been taken, the code tries to read the data over the TCP connection after sending the command to the other computer to send it. The other computer is receiving the send command, and seems to think that the data is being sent with no problems. The TCP connection is never closed until an exit button is clicked in the program.  So unless Labview is dropping the connection of its own accord while the other actions are being taken, connecting with the program and trying to use it to read data should be all that is necessary to generate the error.

I should get a chance to do more testing tomorrow, so I'll post what I come up with then. 

Thanks for the suggestions!

-Steve

[tst]

The code you posted itself is not enough for seeing the source of the error. My programs use TCP communication all the time (over Ethernet and Wi-Fi) without errors, so I know that the functions work. My best guess would be that the connection is dropped from somewhere (your code, LabVIEW, OS, cable being disconnected, other side, etc.), but it's not really possible to tell from where. When you say that the other side thinks the data gets through, is that the same data that the read doesn't manage to get? That would seem to indicate that the TCP packets sent were at least acknowledged. Sounds weird.

One thing that I suggest you do is move the communication code to a separate loop and use error checking to close and reopen the connection if there are errors. This is recommended for many systems in any case, because you can't be sure that the network connection will always be available. You can see a simplistic example here.