LabVIEW
hexadecimal versus octal via serial port
You now attached the same VI four times (twice here and twice here). What makes you think that posting the same question again will give you new insight, especially since you marked the old thread as solved? Is it solved or is it not solved? To keep the forum organized, you could have simply added new (if any) information to the end of your old thread.
Everything is bytes one way or another, so the correct function depends on the structure of the received string. Apparently the bytes form a hexadecimally formatted integer value, consisting of two letters between 00 and FF. After conversion to a numeric integer, it is divided by 255, because that's how the scale is defined: 0 (00) is zero volts while a number of 255 (FF) will give you a DBL value corresponding to the configured "MaxVoltage". There is no magic or hidden meaning. You simply need to read the documentation that comes with the instrument and code accordingly.
@Bildavid wrote:
you said, and i agree with you that bytes form a hexadecimal representation .but if you take a look at the front panel of the VI you will see that data bits are configured to be 8 bits so i am dealing with a byte (8 bits) .
This is your serial port configuration, that descibes how the data is encoded. This simply needs to match the configuration at the other end or you get garbage. It does not tell you how many bytes arrive at the serial port or anything about the transported data.
@Bildavid wrote:
are you saying that this VI takes every 2 bytes together as a hexadecimal value and translate them into numbers by splitting them into byte(8bit) again by dividing them into 255 ?
The VI takes whatever "data" is received and treats it as a spreadsheet string with hexadecimal fields and spaces as delimiter, then forms an array of strings containing one element per hexadecimally formatted field. Each element is scanned into a U32 numeric, forming a numeric array, then divided by 255 and multiplied by the max voltage. There is no "splitting" into bytes per se. Without seeing the raw string, we don't know how may butes there are per value. Since he scans it into a U32, it could be up to 8 hexadecimal characters per field. We cannot tell.
(btw: the inner FOR loop can be removed without change in functionality because all contained operations can work on arrays directly)
Why are you asking all these questions. All you need to do is look at the "received string". I cannot see it because I don't have your hardware! This program has probably not been written by an expert programmer, otherwise it would have some diagram comments describing the format of the received string.
For further analysis, we need to see the received string. Can you run the VI, then copy whaever you get in the "read string" indicator?
OK, you you get 10 bytes of binary data. The code makes no sense in this respect, because it is not hexadecimally formatted, space delimited text.
Do you have documentation on the instrument that is sending the data? Are you sure the program actually works correctly?
