LabVIEW
How to convert decimal number to binary number
"Simplify" is a loaded word and can mean many thing to different people. 😄
A cluster is not very scalable and requires a lot of work (change output size for array to cluster, create all the cluster elements and customize their colors, size, and boolean text, etc. The cluster should even be made into a strict typedef to avoid mixups).
A cluster is more cosmetic than functional and it really depends what you want to do with the bits downstream. Maybe just leave it as U8 scalar or boolean array.
(Note that reversing the array as I did is not needed, of course. It was just to easily compare the binary formatted number (where the LSB is on the right) with the array, which has the LSB on the left.
One possible alternative for display would be a listbox. Now it would be much easier to e.g. change the language.
On a curious side note (not recommended for new users):
You can use 4.x mode typecast to convert the string directly into a boolean array, but be aware that the MSB is now element zero.
I find that changing it to a cluster with explicitly named Booleans to be more convenient for me and very nearly as easy to manipulate. True, it's not scalable, but all the times I've ever used clusters of Booleans, they were already defined in a document, was usually part of a message, and if the message changed, that meant a lot more than just redefining a cluster of Booleans.
@billko wrote:
I find that changing it to a cluster with explicitly named Booleans to be more convenient for me and very nearly as easy to manipulate.
There's nothing wrong with a cluster if the meaning of the bits is well defined and fixed and downstream code is equipped to handle it.
Any specific bit can be queried using unbundle by name. Other queries are a bit more difficult with a cluster (Are all TRUE? Are all FALSE? How many are true? Which ones are true?, etc.) 😄
@altenbach wrote:
"Simplify" is a loaded word and can mean many thing to different people. 😄
A cluster is not very scalable and requires a lot of work (change output size for array to cluster, create all the cluster elements and customize their colors, size, and boolean text, etc. The cluster should even be made into a strict typedef to avoid mixups).
...
OK. How's this:
@altenbach wrote:
@billko wrote:
I find that changing it to a cluster with explicitly named Booleans to be more convenient for me and very nearly as easy to manipulate.
There's nothing wrong with a cluster if the meaning of the bits is well defined and fixed and downstream code is equipped to handle it.
Any specific bit can be queried using unbundle by name. Other queries are a bit more difficult with a cluster (Are all TRUE? Are all FALSE? How many are true? Which ones are true?, etc.) 😄
Well, yes, you need to change it into an array using this guy:
@paul_a_cardinale wrote:
OK. How's this:
Its probably insignificant here, but I historically have an aversion for overlapping front panel elements and typically avoid them at all costs. Back in the days, lots of overlapping controls were over-taxing the UI thread.
The exact same code could use a cluster of a checkbox and a string next to each other, but we are losing the color. 😮
This thread has somehow derailed from "how do I get the bits" to "how do I show the bits" and there are millions of ways to do that. Some are easier on the eye, and some are easier for downstream code. There is no real right or wrong until we see the full requirements document. 😄
We might even do a mockup of several alternatives shown here and let the customer decide.
Personally, I probably would just keep it as U8 internally and create a subVI that formats the entire information into a multiline string using Consolas font (i.e. fixed width) whenever the user needs to see it. 😮
@altenbach wrote:
@paul_a_cardinale wrote:
OK. How's this:
Its probably insignificant here, but I historically have an aversion for overlapping front panel elements and typically avoid them at all costs. Back in the days, lots of overlapping controls were over-taxing the UI thread.
The exact same code could use a cluster of a checkbox and a string next to each other, but we are losing the color. 😮
This thread has somehow derailed from "how do I get the bits" to "how do I show the bits" and there are millions of ways to do that. Some are easier on the eye, and some are easier for downstream code. There is no real right or wrong until we see the full requirements document. 😄
We might even do a mockup of several alternatives shown here and let the customer decide.
Personally, I probably would just keep it as U8 internally and create a subVI that formats the entire information into a multiline string using Consolas font (i.e. fixed width) whenever the user needs to see it. 😮
Even if the user needs to see it, if you don't need labels on your Booleans, you could just display the U8 in binary.
@billko wrote:
Even if the user needs to see it, if you don't need labels on your Booleans, you could just display the U8 in binary.
... forcing the user to find the manual and look up the meaning. 😄
Of course it could be put in the legend or some free text. Here's how the legend could look like 😮
