Splitting a U16 and reading the lo and high bytes in one by one

[fr00tcrunch]

Hey guys,

In the attached VI, I have a U16 (typecasted from Double) that I split up into its hi(x) and lo(x) componenents. I want to read these components in, byte by byte, lo(x) byte first, to keep the U16 precision.

The problem is, I can't find a way to put the byte values from the two 1D U8 arrays together into one array. What I want to output is an array like this:

lo(0)
hi(0)
lo(1)
hi(1)

....
lo(n)
hi(n)

Any help is appreciated!

fr00tcrunch

[altenbach]

So you have an array of DBL values in the range of +-127 (which would fit into a I8). What is the logic of typecasting it to U16?

For each DBL element, you get 4 U16 elements. Why do you label the "typecast" operation as "conversion to...".

Can you give a little bit more background information. What does the subVI expect?

What is the actual output you expect from your current default data?

[fr00tcrunch]

Hi Altenbach,

The multiplication of the doubles with 127 and typecasting it into U16 values were part of instructions I recieved from HAMEG support. I was trying to follow their instructions to get my desired output.    

The labelling of a typecast as conversion would be due to ignorance on my part 😐    

The SubVI that I want to read in to expects U8 values which it then writes to the arbitrary generator in order to output a signal.    

Normally, I could create a waveform using, for example, a sine wave VI. I could then take these values and create a CSV file to feed in through a USB on the generators front panel to generate this sine wave.    

I want to be able to take this same data and have it be written to the generator directly through labview.    

What I expect to be displayed on my generator is a sine curve (just made a simple example), but as the waveform is made up of DBLs I need a way to convert these into U8s to be fed into the driver VI without losing my precision.

[Bob_Schor]

I might be wrong about this, but if you typecast to an array of U8 (instead of U16), I believe you get the reverse of the array you want (i.e. you get the highest byte first).  If you want the order starting with the lowest byte first, simply use Reverse 1D Array.  Much simpler ...

Bob Schor

[SteveE]

This may be what you are looking for. Start with Array DBL, convert to Array U16, pass array into For Loop

For each U16, swap bytes, Split Number into two U16 bytes, build array from the bytes.

Front Panel with test numbers shown with some test values.

Note on previous post, beware of Type casting DBL to U16, it does not give the results you expect, the Convert function does.

[Bob_Schor]

It sounds like I may have given the solution to "a different problem".  What I thought the original poster wanted was the byte representation of a Dbl, in low-to-high byte order.  If, instead, he wants to represent the integer part of a Dbl as a pair of bytes, that is a different algorithm.  I apologize for my confusion (and I'm still not 100% certain what is being asked ...).

BS

[altenbach]

It seems silly to scale to +-127 and then convert to 16 bit integers. Wouldn't it be more meaninfull to scale to the I16 range?

Now we can simply swap the bytes and cast to an U8 array.

Here's a quick draft (note that you don't need any of the FOR loop stuff).

[fr00tcrunch]

---

@Bob_Schor wrote:

It sounds like I may have given the solution to "a different problem".  What I thought the original poster wanted was the byte representation of a Dbl, in low-to-high byte order.  If, instead, he wants to represent the integer part of a Dbl as a pair of bytes, that is a different algorithm.  I apologize for my confusion (and I'm still not 100% certain what is being asked ...).

BS

---

@Bob_Schor: I think you understood correctly the first time. I want the entire double, with the same precision, in U8 format. This is the only type of format that the driver for the function generator reads in. Thanks for your reponse, I will try it out.

---

@SteveE wrote:

This may be what you are looking for. Start with Array DBL, convert to Array U16, pass array into For Loop

For each U16, swap bytes, Split Number into two U16 bytes, build array from the bytes.

Front Panel with test numbers shown with some test values.

Note on previous post, beware of Type casting DBL to U16, it does not give the results you expect, the Convert function does.

---

@SteveE: Thanks for the reponse! One thing I noticed is that it coerces my lo and hi values when implementing this. Is the empty array initialising the shift register supposed to be an empty U8 array?

---

@altenbach wrote:

It seems silly to scale to +-127 and then convert to 16 bit integers. Wouldn't it be more meaninfull to scale to the I16 range?

Now we can simply swap the bytes and cast to an U8 array.

Here's a quick draft (note that you don't need any of the FOR loop stuff).

---

@altenbach: I think you're right. As long as the output array of U8s has the same precision as the doubles fed in, then it'd be best to take the simplest route. I'll try out the example on monday when I have access to the uni lab again.

Thank you so much for all your reponses, Ive still got so much to learn about LabVIEW but I'm really enjoying it and hope I can continue to work with it 🙂

[altenbach]

---

@fr00tcrunch wrote:
@altenbach: I think you're right. As long as the output array of U8s has the same precision as the doubles fed in, then it'd be best to take the simplest route. I'll try out the example on monday when I have access to the uni lab again.

---

The data represented in the array of U8 is qualrized to the range of I16, i.e. 16bits (split into two consecutive 8bit values: LO and HI). A DBL has a significantly higher precision than that (~16 decimal digits), so the precision is not the same. Of course we need to know where the DBLs are coming from. For example if they are the scaled result of an A/D converter with a dozen or so bits, scaling it to 16bits will not lose much. 😉

You originally scaled it to integers in the range of +-127 (only 256 possible values!), meaning that the high byte was always zero.. Seems pointless.

Scaling it to the I16 range as I did guarantees that every single bit is utilized for the highest possible resolution if we are restricted to 16 bits per value.

[fr00tcrunch]

---

@altenbach wrote:

The data represented in the array of U8 is qualrized to the range of I16, i.e. 16bits (split into two consecutive 8bit values: LO and HI). A DBL has a significantly higher precision than that (~16 decimal digits), so the precision is not the same. Of course we need to know where the DBLs are coming from. For example if they are the scaled result of an A/D converter with a dozen or so bits, scaling it to 16bits will not lose much. 😉

You originally scaled it to integers in the range of +-127 (only 256 possible values!), meaning that the high byte was always zero.. Seems pointless.

Scaling it to the I16 range as I did guarantees that every single bit is utilized for the highest possible resolution if we are restricted to 16 bits per value.

---

Ah, you're right, of course. I'm not used to dealing with all these different number representations, up until now my course of study has been much more focused on renewable energies and distribution. 

The generator cant actually display double precison, so I16 will be sufficient. It's simply been very frustrating to try feeding in U8s to the function generator while keeping the waveform looking the same as it does on my LV front panel.