LabView TCP/IP advice

[AndreiN1983]

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

[AndreiN1983]

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.

[deceased]

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

[AndreiN1983]

Thank you 4 the answer.
Unfortunately i do not control both ends of the comunication. I just give a command and store the answer.

Is there another solution to this problem ?

[Eric1977]

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.

[deceased]

Any documentation on the packet format for the other device?

It might embed a data size somewhere that you can access.

[nathand]

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.

[deceased]

---

@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.

[billko]

---

@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.)

[deceased]

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.