11-14-2015 03:32 AM
Dear all,
I need some advice concerning a TCP/IP comunication using LabView - please point me in the right direction.
Basicaly, what i am trying to do is to send a command over TCP/IP and receive a feedback/response.
The problem that i am encountering is that i cannot see the feedback/response in the LabView vi but i can see it in the wireshark software.
The vi code is this :
The response from the Wireshark software looks like this :
- COMMAND SENT :
- FEEDBACK RECEIVED :
Where is the problem ??
Thank you very much for taking the time to read my post !
Best wishes,
Andrei
11-14-2015 03:50 AM
Oookkkkk...so it seems i have to specify how many bytes to read from the port.
Hmmm...this is a problem...i send a command but the answer may be of variable length.
11-14-2015 05:24 AM
Do you control both ends of the TCP connection?
If you do, then you can prepend the data size onto the packet (as a fixed number of bytes).
Then in labview you can read the fixed number of bytes, then pass that number into another READ to grab the actual packet.
Deceased
11-14-2015 06:26 AM
11-14-2015 07:57 AM
Since I am not at work and don't have LabVIEW installed on my home PC, the only advice I'd give it to get rid of the FOR LOOP & the 10 second wait. They do nothing.
11-14-2015 08:03 AM
Any documentation on the packet format for the other device?
It might embed a data size somewhere that you can access.
11-14-2015 09:21 AM
11-14-2015 09:26 AM
@nathand wrote:
Does the response end with a new-line character (many text-based protocols such as HTTP do this)? If so, you can read up to the end-of-line.
Its a dangerous game since the message may well contain a 0x0D / 0x0A that is part of the data rather than a CRLF. I have seen this happen many times where a device is transmitting measurements as hex values.
11-14-2015 11:01 AM
@deceased wrote:
@nathand wrote:
Does the response end with a new-line character (many text-based protocols such as HTTP do this)? If so, you can read up to the end-of-line.Its a dangerous game since the message may well contain a 0x0D / 0x0A that is part of the data rather than a CRLF. I have seen this happen many times where a device is transmitting measurements as hex values.
Not dangerous at all if that is the format of the response! (Unless the protocol was so poorly written that the data is binary, yet specifies EOL as the end of the message - but that's a whole 'nuther issue.)
11-14-2015 11:38 AM
Yes, I must admit, on all occasions where I have seen data transmitted as hex, the TCP packet contained a fixed length header which indicated datasize.