LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (https://www.linuxquestions.org/questions/programming-9/)
-   -   TCP/IP Input Reflection Problem (https://www.linuxquestions.org/questions/programming-9/tcp-ip-input-reflection-problem-557559/)

OliveOil 05-29-2007 04:01 PM

TCP/IP Input Reflection Problem
 
Hi,

I was not sure whether this would fit best in the programming forum or the networking forum, so I tried both. I am trying to write user interface software to communicate with a robot via TCP/IP. It is a prototype, so the documentation for it is extremely limited. The robot appears to receive and respond to everything I send it, but I am having trouble processing its replies. This is important because it tends to overheat, so I need to be able to send frequent requests for motor temperature readings and process the responses, in order to cut the power if it is getting too hot.

I'm using:
Red Hat Linux 9
Kernel version 2.4.24 (I think)
C/C++
socket type: streaming

Here's my problem.

When I send it a string, for example:
"12HI\r"
it sends back
"=>"
(not sure about the delineator stuff in the response).

I know what the robot is sending back because I've been using a Windows terminal program to test it. Using the Windows terminal program I received from the manufacturer, everything seems to be fine - it prints out only the responses that I am expecting to get from it.

After sending the same command from my Linux code, I do a read(), and I get:
"12HI
=>".
Or I might get "12H", then "I =>" or something. I pretty much always read() or recv() what I sent to it, along with its response.

Say I send several commands, for instance:
"12HI\r"
"34HI\r"
"123 SET TIE 0\r"
"1234567 GET MV\r"
"1234567 SET MODE 0\r"
and do a read() after each one.

Here's what I printf()ed from my last read():
"1234567 SET MODE 0
=> 00 1000 500 1000 1000 1000
=>"

(FYI, the response it sent back for the SET MODE command was "=>", and as for the GET MV, it sent me "1000 1000 1000 500 1000 1000 1000".)

I also checked the length of the stuff in the last read(), and I got a length of 55. I'm not sure exactly where the 55 chars are coming from. The length of the last thing it sent me, "=>", should have been no more than 3-4.

Sometimes it's more jumbled junk than that. I'd be totally fine with that if it would put my expected response at the front end of the string. But it doesn't. I get the response I'm looking for somewhere in that garbled junk. The problem is that I don't know where to find it, and I cannot process it if I can't find it in the string.

When I send it a command, why would that command be sent to the robot and reflected back into my system buffer - i.e. why am I reading what I sent it?

Also, is there any way to clear out the system buffer after each read and write? How are the system buffers for reading and writing connected?

Also, a real newbie question: I am saving what I read into an array; how do I clear the contents of an array? Should I use free()? Or set it equal to {0}? I tried both, and it doesn't seem to help. Based on what I've seen, it appears that it's the system buffer that needs to be cleared somehow.

Thanks,

OliveOil

:scratch:

theNbomr 05-29-2007 07:39 PM

It would be more helpful to post the relevant code fragment(s) (in [C O D E] tags please). Without them, one can only guess or speculate.
--- rod.

Mara 05-30-2007 05:06 PM

1. The robot finishes lines with \r\n (it's clear from 55 chars in the response you have shown):
Code:

"1234567 SET MODE 0
=> 00 1000 500 1000 1000 1000
=>"

2. Check what happens when you send your commands with \r\n at the end of a line.
3. The robot is echoing back what it gets. Probably there's an option to turn that off, try ECHO OFF and different combination or try to find it in the documentation. If you can't turn it off, you'd need to live with that feature.
4. Note that the Windows terminal may not be showing you all the characters it gets. That's why it would be useful to see how the transmission looks like. Use a sniffer for this, like Wireshark. In the data fields of the packets you'll see the exact data sent and received.
5. My guess is that you should remove => and the commands you get back.
6. Clearing an array: if it was allocated in one piece, you free the whole array or clear the positions you want (set them to 0 or so) when you want to use the same array later. If it's an array of pointers to dynamic data you need to free the dynamic part first.


All times are GMT -5. The time now is 04:40 PM.