04-14-2015 02:14 PM - edited 04-14-2015 02:14 PM
04-15-2015 01:11 AM
GerdW,
Thanks for your code- will try out and revert. Looks compact.
However I have run into a problem with the VI I had earlier said works - refer the attched VI and in the BD, I have put notes explaing the issue. When I directly feed the String data ensuiing out of the TCP Read, my SubVI "Hex String to U16" does not work. However if I copy-paste the data into a String Constant and feed that constant, the SubVI works.
I must admit I am not very clear about the data structure that is involved....so not sure whats happening.
04-15-2015 01:13 AM
@crossrulz wrote:
The string is just an array of bytes. What is the format of the data in this byte array that shows up as a string? I recommend you get a normal message from your instrument and save that string data to a file and post the file. Also tell us what you expect the output to be.
Thanks. I have attached the actual VI which also contains the actual feed received from the TCP Read function. And it has a problem as explained in the BD therein... It also shows you the actual output that I need
04-15-2015 02:47 AM - edited 04-15-2015 02:50 AM
Because your sample hex string is in normal format while your real string is in hex format. Even if they look the same, their content is very different. The diagram constant is a formatted string, containing the characters 0..F (and space), while the real string contains mostly unprintable characters that only show if you use \-codes or hex display.
Here's how to process the raw string:

04-15-2015 02:59 AM
Hi Raghunathan,
I must admit I am not very clear about the data structure that is involved
And I thought we already discussed this some days ago…
04-15-2015 02:59 AM - edited 04-15-2015 03:00 AM
Of course if you want to have an extra decimal digit, you need a floating point format for the final display. Here's one possibility.

04-15-2015 05:27 AM
@altenbach wrote:
Because your sample hex string is in normal format while your real string is in hex format. Even if they look the same, their content is very different. The diagram constant is a formatted string, containing the characters 0..F (and space), while the real string contains mostly unprintable characters that only show if you use \-codes or hex display.
Thanks ... worked perfect. Going by your explanation, I can see why the constant worked.
>> Even if they look the same, their content is very different.
But then the output from a TCP Read function is shown as a String and that is where it tripped me.Its a string alright but each made up of U16 data as an array. Correct ??
04-15-2015 05:43 AM - edited 04-15-2015 05:43 AM
When dealing with data like this, it is very important to show the display style. If we took your recieved TCP data and put it into a "normal" formated sting, you will see something like this. This is exactly why we were asking you for the data since it looked like you did not know how the data was actually formatted.
Raghunathan wrote:But then the output from a TCP Read function is shown as a String and that is where it tripped me.Its a string alright but each made up of U16 data as an array. Correct ??
As I stated before, a string is just an array of bytes. How you interpret those bytes is up to you. In this case, the bytes needed to be interpreted as a bunch of U16 data points.
04-15-2015 05:53 AM
Thanks. It clear now.. the golden rule is to make aware what kind of data we are dealing with.
11-30-2015 04:48 AM
I am doing a hex to numeric conversion on the string that is 349000 bytes long. plus it is contains 24 byte packets along with header.
what i am stuck at is that I want to discard any packet that is not recieved fully that is most probably the last packet. but i dont know how to do it