The TCP/IP Write Function is transmitting Hex data as ASCII; E.g. 5 bytes of Hex (010518001E)and TCP/IP transmits 10 bytes in ASCII(30 31 30 35 31 38 30 30 31 45).

[ATC]

Our TCP/IP Server send 8 binary bytes (a float number), and from our Client we it back into a float number ... but we failed!

[mikeporter]

Ok, in the code you posted it looks like there are a couple problems. First, I am assuming that the code sends the command "trace:data 5" and in return gets a count of the number of bytes there are to read. If so, here is your first problem. You can't just typecast a string into a number. What you get is the ascii value(s) of the character string left justified in whatever size numeric you cast it to. For example, if the instrument sends back the string "15" and you cast it to an I32 (as in your code) the result in decimal is 825556992 or in Hex 31350000 (31 is the ascii value for "1" and 35 is the ascii value of "5".) To convert this number properly use the "Decimal String to Number" primitive.

The second problem is converting the result of the second r
ead to a floating point number. If the instrument is returning the value as a string representation of the floating-point value (which is likely) you have to use the "Fract/Exp String to Number" primative.

In terms of the problem in the title of your post, the TCPIP write always transmits strings. If you think you're sending 010518001E but what is really going out is 30 31 30 35 31 38 30 30 31 45, you haven't formatted something correctly. Check to make sure that hex display is turned on for the string constant or control defining the output string. Alternately, if you are generating this string programaticaly, make sure the string formatting doesn't do an ascii conversion. Attached is a short example showing how to properly convert data that is in an array of U8s.

A good clue is that hex display always shows the string in 4-character groups. Your input string should look like: "0105 1800 1E"

Hope this helps.

Mike...