TCP/IP Connecting with Real Time Controller

[Guy04]

I have a host running Labview on a windows XP and a realtime embedded controller on a pxi chassis that acts as the server.  When the realtime is started it automatically goes into listen mode and listens for a connection from the host.  The host opens a connection.  After a valid connection is open the Real-Time side goes into a TCP_Read and the host can then send commands that the real time processes and sends to the FPGA on the pxi-chassis. 

Now the problem I'm having is how to handle the case when a TCP connection is lost.  I can have the TCP_Read on the real-time error on a time out and then go into a listen mode but this isn't very logical because then the host will have to reconnect each time a time out occurs.  So if I make the TCP_Read timeout be infinite and if the connection is lost (let's say I unplug the ethernet cable and re-plug it back in) then I cannot recover from this and the Real-time will need to be re-booted.

I've tried to send the Real-time into listen mode if the error code is other than a timeout error (code 56) and have it go back to TCP_read mode if it is a timeout error.  But if the connection is lost by means of a physical way (such as me pulling the ethernet wire and plugging it back in) then the Real-Time never sees that the connection is invalid.  The host on the other hand can detect it bc it will get an error when it's trying to write?

So my is:

Is there any way to prevent an infinite loop that needs a reboot and at the same time prevent the host from reconnecting every time there is a timeout?

[tbd]

Hi Guy,

     Would it work to have the RT server poll the Host/Client periodically?  The RT-Server could send anything to the client, say a U32, that the client would send back within a very short time.  If this loopback doesn't happen, it's probably safe to assume the client-connection is dead.

Is this a case where it's reasonable to expect client connections [to RT Server] will simply go dead and we need a way for the Server to test the connection?

Cheers!

[Guy04]

The problem is that the client only reads the TCP after is sends a command to the RT-Server.  If the connection drops the client side can detect it because when it tries to send a command (write) to the RT-Server it will get an error. But the RT-Server when it just sitting their waiting for a command it's basically reading and when you're reading you don't get an error if the connection drops.

If the RT does send a U32 and the connection isn't there anymore, it will get an error on write which works out good.  But, if the connection is still valid, the client side isn't waiting to read, so the next time the client writes to the RT-Server and expects data returned the U32's that the RT-Server kept periodically sending will be in the buffer and so those data will be invalid.

[tbd]

Hi Guy,

      Maybe a bit more info would help!  What do you mean by "a TCP connection is lost"?  Are the RT functions being Served to a network through the "Host", and it's the external-connections to the Host that are questionable?  Please describe a scenario where a connection is "lost".  Are you writing the "Host" software as well as the RT-Server software?

Cheers!

[SJeane]

Guy,

I am currently looking at the same problem as yourself.  I setup a crio as the server and am communicating over satellite (Hughsnet) to my computer here in the lab.  Both the crio and the satellite are both here in the lab so I can simulate problems that I am viewing with other installations I have running.  I too have not been able to get to the root cause of disconnecting and then reconnecting the cat 5 between the crio and satellite modem and then continue to transmit data.  I have worked with error control on the host side and can programatically clear errors and re-establish connection if I reboot the crio but not if I unplug it.  I can re-establish connection though if I reboot the crio after I have unplugged it.  I have been working with the RT Reboot Controller.vi on the real-time side but to no avail.  Any thoughts or hints as to a possible solution would be great.  If you like I can go into detail on what I have done and tried.

TNx,

/steve

[Pakman]

Hi SJeane,

When you tried using the RT Reboot Controller.vi, why did it not work?  Did the unit not reboot?

[SJeane]

Hay Packman;

 When I reboot the crio manually the 3rd led lights on the crio and the lan connection lights go off  and then back on.  Using the vi. I dont see any visual indication of a reboot and nothing changes on the host.  ie. I still maintain error 56 from the tcp reads. 

[Pakman]

Hi SJeane,

I apologize for taking so long to respond, but I wanted to test this on my end.  In doing so, I realized that using the RT Reboot Controller.vi after the connection is lost does not work because the message to reboot cannot be relayed to the target without communication!  Thus, to solve this problem, we have to approach it a different way.  You mentioned that you tried programmatically clearing errors, but did you try to reestablish connection after clearing the errors?  I tested this on my end with a FieldPoint controller, and the attached VIs resumed operation even after unplugging/replugging the Ethernet cable (no reboot).  Will this solution work for you?

[SJeane]

Pakman,

I will incorporate this into my RT vi. and test.  I have my listen on the cRIO RT side and not on the host.  Is it possible that I will need to have error handling code on the RT side?  I have used the no EOC vi.   I do not know what the error generated on the RT side and need to develope a way to log these errors to be identified.  Rebooting the cRIO is the only sure way that I can think of to reestablish connection but I know it is not the best fix.

TNx,

/steve 

[Pakman]

Hi Steve,

I've recoded the application so that the real-time target is the server.  Please let me know if it allows the connection to be re-established without reboot.  I've tested it here using Compact FieldPoints, and it worked beautifully.  Unless cRIOs have different error codes, it should work fine on them as well.  Also, I was able to determine what error codes to monitor by writing their values to internal flash memory.  You can do the same by simply making the file path something like "C:\myfile.txt."