tcp/ip comms reliability help

[DavidT]

Hello everyone,
i have an application which uses TCP/IP to communicate from my PC to a FieldPoint controller. I created the communications vi's using the comms wizard.
Occasionally, I will receive an error 56 and I will click continue on the error message. The error message will not appear again but i will not receive any further data from the FP controller. Could someone please take a look at my comms vi's (attached) and suggest a possible way to make the more robust i.e. re-establish the connection so that data is not lost.

thanks
David

[DavidT]

Once again forgot to attach the vi's...

[Matt_F]

Hello David,

The best thing to do is to watch the error cluster for the error 56 code and when found, close the connection and then reopen it. You can find more information on this error at the following link.

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

Please let me know if you have any questions.

Regards,

Matt F

[DavidT]

Hi Matt,
The TCP Comms.vi attached in the previous message already closes the connection on the Host PC if any errors are encountered and then reopens the connection. Is there anything that I can do on the RT side, such as increasing the timeout period on the TCP Listen.vi to ensure I reconnect.
The only way to reconnect at the moment is if I reboot my FP controller which I see as a last resort fix.

thanks
David

[tst]

I ran into a similar problem with some code I recieved which ran an a FP. What was happening was that the connection would be opened, the listen would return no error, but the read and write would not work. Since the code was quite complex, I had a hard time in figuring out whether this was a problem of the code or of the FP. I tried several things, which helped somewhat. For example, I told the FP that if it tried to connect and recieved no data several times in a row, it should wait before trying to reestablish communication. That seemed to help for some of the cases, but not all of them. Eventually, since this was acceptable for that system, I just had the PC reset the FP whenever it tried to open a connection for too long.
Another thing I can suggest, which works nicely for me, is to not close the connection immediately, but to let the VIs error several times in a row before closing it. Also, I'm not sure if this is necessary, but I would place the close connection outside the case and let it close even when the opening failed.

[DavidT]

Thanks tst. Resetting the FP is one of the options i was looking at but resetting the FP means we lose our test data, which for us at the moment is not an option. I will try your other suggestions such as passing the error several times before opening and closing connections or resetting the system.