Listen if the TCP connection between robot and LV GUI is lost

[Little_Helper]

Hi

I'm doing a simple client/server TCP connection between a Labview GUI and a robot controller.

My robot controller acts as the TCP server that waits for a connection from the Labview GUI, it gets a string as a ready signal and then writes a string back to the LV GUI to tell that the controller is ready, then the LV GUI should be ready to send commands to the robot.

So now first of all there are two things I want to do;

1) I want the user to push a button to connect to the robot and then make a red/green light turn on if the connection is established, then the LV GUI also starts a small loop that waits fro whatever is coming from the robotcontroller, this is only for debugging right now

2) Secondly I want the LV GUI to listen if the connection somehow is lost, like if the robot goes out of range or some other programming error in the script for the robot controller that might make the TCP connection terminate. So if the connection is lost from the serverside, then I want the LV GUI to keep runing but just turn the light red.

I have tried some of the examples in Labview but I sure could need some help on this.

LV 8.5

[tst]

You really should change your architecture. I assume that your other controls also control the robot, so you will need more complex messaging.

I suggest you look at some of the examples and templates for queued message handler. Essentially, this will allow you to send message between two loops, which is probably what you want.

As for what your comm loop should actually look like, you should separate the opening part from the communicating and closing part. That way, you can send the Ready string immediately after connecting. The example code you used already handles the timeout error, which is the indication you want that the connection was lost.

Here's one (very bad) example of how this could be done:

You should note that this does not really do any error handling. If you use a queued message handler and actually turn the comm loop into a state machine (with states like Open,Comm and Close), it should be cleaner.

To learn more about LabVIEW, I suggest you try looking at some of these tutorials.

Message Edited by tst on 01-19-2008 07:53 PM

[Little_Helper]

I managed to use the example from Labview "TCP Communicator" to get the communication running, but still it will not react to the server disconnecting because of some error with e.g. the robot stalling or a script error (it would be like if the LAN-cable got unplugged). The VI will not register/"sense" that it actually isn't connected anymore, until the server is started again..

I tried to reproduce your example, without any luck, because of the case structure, but my own example looks pretty much the same, and still I get the above result.

Is there no way Labview can register the disconnection without sending a test string to the server?

[F._Schubert]

The way to monitor the connection is to read data.
If the connection is ok & no data is send, you get a timeout error.
If the LAN cable is unplugged, you will get a 'Connection closed by peer' error (not really sure about this one).

Depending on your other requirements, I think a state-machine design is useful (connection closed -> try to reconnect).

Felix

[Little_Helper]

Ok I will try to do the error monitoring and see if I can come up with something. I am not sure if I understand what you mean by a State Machine, tst also talked about it. Is it that I do the monitoring and then react to the responses that I get?

[Little_Helper]

I have made a small test now, and when the read is done in a loop, I get the expected 56 Connection timed out and when I unplug the LAN cable I get 66 Connection closed. But this connection closed-error is first registered after about 10 sec. (my read loop has a 1000ms time-out), and if my server crashes then the read loop just keeps reading and giving me the 56 time-out instead of e.g. connection closed, refused or something like that.

[F._Schubert]

Here are some links to find information about state machine. For more, search around about state machine and design patterns on ni.com and lavag.org

http://zone.ni.com/devzone/cda/tut/p/id/3024
http://zone.ni.com/devzone/cda/tut/p/id/5237
http://zone.ni.com/devzone/cda/tut/p/id/5218

Felix

[tst]

---

SCMAJA wrote:

if my server crashes then the read loop just keeps reading and giving me the 56 time-out instead of e.g. connection closed, refused or something like that.

---

The usual way of getting around this is writing code so that one of the sides sends a periodic ping to other side and gets a response. Then, you count your timeout errors (e.g. in a shift register). If you get data, you reset the counter. If the counter goes over a certain value, you know that the connection is dead.