TCP communication with external software

[PaoloScoppola]

Hi,

we are developing a TCP client application to control Watchout vie ethernet. We are using SocketTest to control that everything is correct.

1. Our TCP client can send only the first message. After that, Watchout doesn't send back anything. 

2. SocketTest works perfectly, it sends as many message sa we want.

3. At the same time, if we turn ScoketTest to server, our TCP client sends to it as many message sa we want.  

We are investigating about message delimiter, it seems that Watchout uses CR in place of LF. We tried CR, LF and EOF, but we still have the same three situations.

 

is there any more advice about TCP protocol?

 

Thanks

Paolo

 

 

[jfk]

3 hours ago, PaoloScoppola said:

... 1. Our TCP client can send only the first message. After that, Watchout doesn't send back anything.  ...

 Unless you use command ID tagging, most valid commands do not send any response. Can you be more specific?

 

 

[PaoloScoppola]

Of course,

This is a snippet of the code - it's a c++ application based on openFrameworks

if (key.key == '1') {

	msgTx = "gotoControlCue \"test\"";

} else if (key.key == '2') {

	msgTx = "run";
} 

tcpClient.send(msgTx);

when I press the key 1 Watchout receive gotoControlCue "test" and it really goes to the Control Cue "test"

then I press 2 and Watchout doesn't print/do nothing

Port is 3040 Ip is 192.168.1.31 - I tried to specify these message delimiters "\n", "\r", "\r\n"

if you need I can send the application

Thanks

Paolo

 

 

Quote

 

Quote

 

 

[jfk]

21 minutes ago, PaoloScoppola said:

Of course,

This is a snippet of the code - it's a c++ application based on openFrameworks

if (key.key == '1') {

	msgTx = "gotoControlCue \"test\"";

} else if (key.key == '2') {

	msgTx = "run";
} 

tcpClient.send(msgTx);

when I press the key 1 Watchout receive gotoControlCue "test" and it really goes to the Control Cue "test"

then I press 2 and Watchout doesn't print/do nothing

Port is 3040 Ip is 192.168.1.31 - I tried to specify these message delimiters "\n", "\r", "\r\n"

if you need I can send the application

Thanks

Paolo

If those commands are not terminated with a carriage return, the command will fail as it is incomplete and you will get no response. Neither of those commands will respond over the TCP connection if successful. Have you considered adding command IDs to each command to force WATCHOUT to respond? (reference: WATCHOUT 6.1 User Guide, COMMAND ID TAGGING - page 170) 

BTW the correct command termination is carriage return (hex 0D). You do not show the carriage return in your samples above, so I am a bit surprised the first command worked.

[PaoloScoppola]

Thanks jfk for your reply

I'll add the command IDs to force WATCHOUT to respond, so I'll see what happen.

The carriage return is placed automatically by the class tcpClient.

tcpClient.setMessageDelimiter("\n");

 

[jfk]

2 minutes ago, PaoloScoppola said:

Thanks jfk for your reply

I'll add the command IDs to force WATCHOUT to respond, so I'll see what happen.

The carriage return is placed automatically by the class tcpClient.

tcpClient.setMessageDelimiter("\n");

 

Understood. I guess it is a matter of terminology, I always thought delimiter was added both before and after. For example, the double quotes in the command gotoControlCue "Cue 3"$0D delimit the text string in the command. The carriage return is a terminator. BTW the text string delimiters are only required if a string arguement contains a space. Technically gotoControlCue test$0D and gotoControlCue "test"$0D will both work the same.

[PaoloScoppola]

We have solved, 

the send method of the OF library add some char, before really sending the msg.  This doesn't create problem with other testing software, so maybe there is no just one way to communicate over TCP/IP. Anyway by using the sendRaw method and adding "\r" at the end of the message, everything works fine.

thanks

Paolo