Error63 Strange behavior

[TeaAndBiscuits]

Test Condition:
National Instruments’ TCP Communicator Active.VI
Windows XP computer +  a  controller.

Case 1:
I call ‘TCP Open connection’ with a remote controller (only in the beginning).
During the program I just use ‘TCP Write’ and ‘CTP Read’. I issue many commands. I get responses
I call ‘TCP Close Connection’ it only at the end of the program.
Connection is present all the time
This works fine.

Case 2:
I call ‘TCP Open connection’ with a remote controller (only in the beginning).
During the program I just use ‘TCP Write’ and ‘CTP Read’.
I issue many commands. I get responses
Controller side network connection is broken.
I DO NOT issue commands.
Controller side network connection reestablished..
I issue many commands. I get responses
I call ‘TCP Close Connection’ it only at the end of the program.
Connection is NOT present all the time
This works fine.

Case 3a :
I call ‘TCP Open connection’ with a remote controller (only in the beginning).
During the program I just use ‘TCP Write’ and ‘CTP Read’.
I issue many commands. I get responses
Controller side network connection is broken.
I DO NOT issue commands.
I call ‘TCP Close Connection’.
I stop the program after proper closing.

Case 3b
I do NOT quit LabVIEW. I do not reset the controller
Now
I call ‘TCP Open connection’ with a remote controller (only in the beginning).
It comes up with the following error:
“Error 63 occurred at TCP Open Connection
Possible reasons:
LabVIEW: serial port receive buffer overflow / the network connection was refused by server.”

Case 3c
Everything same as 3a. Instead of 3b I have following:
I quit LabVIEW . I reset the controller.
I open the LabVIEW program again.
I call ‘TCP Open connection’ with a remote controller (only in the beginning).
During the program I just use ‘TCP Write’ and ‘CTP Read’. I issue many commands. I get responses
I call ‘TCP Close Connection’ it only at the end of the program.
Connection is present all the time
This works fine.

My question:
Q1 Why does this error not come in “case 2” and come in “case 3a” ??
Q2 Why does this error come in “case 3a” and does not come in “case 3b” ??

Thanks
Sandeep

[Dynamik]

Hi Sandeep,

      About a year ago, I was heavily into integrating a TCP/IP device and the following DOS-window command helpped in debugging:

netstat -a 1

This will display your port-states on one-second intervals.  We found a relatively long period occurred after trying to open a port, before Windows would let us try to open it again.  In any case, being able to monitor what "state" the port is in may be helpful to you.

Cheers.

[tst]

I tried the example on one computer and I have no problem with it. I do get error 63 if the TCP open in the active VI times out. Now, if you used the example exactly as it is, the program should have stopped on both sides. If it isn't running on server, you get an error 63. Did you include any looping mechanism to maintain communication even when there is a problem (like this, for instance)?

Another option is that there is a real problem, maybe something like this, but I would suggest you try the first approach. TCP communication should be reliable, so if something goes wrong, it should usually be able to continue alone.

Also, you might want to check out this. 

[TeaAndBiscuits]

Hi Dynamik,

Thanks for this command.
This is useful for debugging. Even in the future.

Thanks.
Sandeep

[TeaAndBiscuits]

Hi.
This is a neat VI.

I am trying to deliberately replicate and find the cause the problem at another location.
Controller program is always running and not controller by me.

Your VI looks pretty robust. Also various VIs in the link are good work.
Encouraging !

Thanks much.
Sandeep