LabVIEW
Problem with hexadecimal string concatenation
I am trying to construct a hexadecimal string to be sent to a machine via serial port. The string consists of a constant command (+ a parameter that is calculated and converted into U16 and then to hexadecimal string, as shown in the following block diagram clip
1. As far is the constant is concerned, it appears exactly as shown in the final string that is to be send.
2. When displayed on its own, the hew integer string shows exactly the value I want to send (compare Word_1 and hex integer string in the following clip).
3. However, when concatenated into a final "String", the hex integer string is instead converted into the ascii equivalent of each hex character!!!
What am I doing wrong???
@fsahmed wrote:
The string consists of a constant command (+ a parameter that is calculated and converted into U16 and then to hexadecimal string, as shown in the following block diagram clip
Let's take a step back. What exactly do you mean by "hexadecimal string"? A raw data stream? A string with ASCII values that represent a hexadecimal number?
You're problem is that you are mixing these two concepts. Your string constant and indicator are showing the raw data stream (Hex Display). But the Number To Hexadecimal String creates the ASCII value. If you want all to be the raw data, use Flatten To String instead of the Number To Hexadecimal String.
@crossrulz wrote:
You're problem is that you are mixing these two concepts. Your string constant and indicator are showing the raw data stream (Hex Display). But the Number To Hexadecimal String creates the ASCII value. If you want all to be the raw data, use Flatten To String instead of the Number To Hexadecimal String.
Just for my own benefit, can someone comment on usage:
I usually use Type Cast. Crossrulz recommended to use Flatten to String. Other than the obvious difference (Prepend size, byte order, etc), is there any benefit to use one over the other? Both yield the same results.
Hi Jamiva,
FlattenToString becomes handy once you convert something different than byte arrays as you can determine the byte order easilyā¦
In your snippet I would even use ByteArrayToString instead. š (Didn't check but guess you're using an U8 array constant.)
@jamiva wrote:
I usually use Type Cast. Crossrulz recommended to use Flatten to String. Other than the obvious difference (Prepend size, byte order, etc), is there any benefit to use one over the other? Both yield the same results.
Once you deal with enough systems, you realize that the Endianness (byte order) matters A LOT. If you are talking to a Little Endian system, then Type Cast will give you bad results where the Flatten To String allows you to fix that. But this only really affects multi-byte values. An I8, U8, array of I8 or U8, or strings will not matter. But I32, DBL, etc do care.
And for the array of U8, use the Byte Array To String. That is literally a no-op since a string and array of U8 actually have the exact same structure.
The reason I asked, a long time ago I didn't know about the flatten & unflatten from string functions. So when I ran into byte order issues, I wrote my own conversion subVIs and stuck them in a library. Here is one of them and I STILL use all of them to date. It's hard to teach an old dog new tricks. On a scale of 1 to 10, how bad is the Rube Goldberg Code. 
@jamiva wrote:
On a scale of 1 to 10, how bad is the Rube Goldberg Code.
Is 0 or 10 the best RG? Is the worst RG perfect code,5 being borderline RG?
Anyway, it's not bad at all. It's clear at a glance and that's what most important. The unflatten has benifits (probably speed, error in\out, endianness) so it's preferred.
Search LabVIEW like a graph! 