LabVIEW
How to convert Hexadecimal String to comma separated Binary number
Solved!
Lots of ways to do this. Here're two.
Convert the hex to integer (Hexadecimal String To Number, or Scan From String with %x).
Make sure it's 16 bit (either provide a default, or convert)
Convert to Boolean array (Number To Boolean Array).
Convert the Boolean array to numbers.
Convert to comma separated string (Array To Spreadsheet String).
Remove the annoying enter.
Or
Convert the hex to integer (Hexadecimal String To Number, or Scan From String with %x).
Convert to binary string (Format Value or Format Into String, with %016b).
Insert commas (Search And Replace, set to reg.ex, using "([01])(?!$)" and "$1,")
Search LabVIEW like a graph! 
@avana2006 wrote:
I want to convert the Hex string to comma separated binary.
Example:If I give Input FFFF then I want the output 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
Very bad example, because we cannot tell if you want the LSB on the left or on the right. We also cannot tell what the max input string lenght is. Does the max length fit in a U64 or can the string be even longer? Do you want to see zero padding to a certain length?
- Is the input guaranteed to only contain characters 0..F, or can there be others (delimiters, space, tab, etc.)
- What is the max length of the formatted hex string? Is the number of characters always even?
- Do you want the output in the same order as in the string (number to boolean array will show the LSB to the left, i.e. reversed)
- How should the output look like in the general case? Fixed number of elements? How many?
wiebe@CARYA wrote:Make sure it's 16 bit (either provide a default, or convert)
16 bits is only sufficient if the number does not exceed FFFF, but we don't really know that. Providing a default datatype is definitely better than convert later. For reference, her's how that would look like:
(I also reverse the array as mentioned above)
Also, if speed matters, you could use a map based lookup table (LabVIEW 2019 only, but workarounds exist for lower versions), leaving you with just a tiny FOR loop. There are many other (even more efficient) ways to do this, of course. You might also want to adapt it so it also handles lowercase a..f.
@altenbach wrote:
You might also want to adapt it so it also handles lowercase a..f.
Just a tiny change when doing the map (now with 22 entries): 😄
@altenbach wrote:
Also, if speed matters, you could use a map based lookup table (LabVIEW 2019 only, but workarounds exist for lower versions), leaving you with just a tiny FOR loop. There are many other (even more efficient) ways to do this, of course. You might also want to adapt it so it also handles lowercase a..f.
Maps again? They are fast, but not that fast. An array look up will be faster!
If performance is at stake, and why would you otherwise even consider lookup solutions be it maps or in this case as you only have a static and small number of elements an array lookup, you should always try to avoid Numeric to Boolean Array and vice versa too. They are pretty slow due to the inherent array allocation every single time. Formatting the binary byte array directly in a loop with a rotate and boolean mask is many times faster than the numeric to boolean array “shortcut”.
I’m always amazed how often this function is used when trying to interprete flags in a numeric while a simple boolean AND or OR would do the same with less screen space, less CPU overhead and less memory consumption and execution time!
@rolfk wrote:
If performance is at stake, and why would you otherwise even consider lookup solutions be it maps or in this case as you only have a static and small number of elements an array lookup, you should always try to avoid Numeric to Boolean Array and vice versa too. They are pretty slow due to the inherent array allocation every single time. Formatting the binary byte array directly in a loop with a rotate and boolean mask is many times faster than the numeric to boolean array “shortcut”.
I’m always amazed how often this function is used when trying to interprete flags in a numeric while a simple boolean AND or OR would do the same with less screen space, less CPU overhead and less memory consumption and execution time!
But this is done in the creation of the lookup table, so it's only a one time penalty.
After the fist run, the Number To Boolean Array isn't used anymore.
