LabVIEW
Case Structure
@BertMcMahan wrote:
wiebe@CARYA wrote:
@BertMcMahan wrote:
I'd suggest one more modification- put the "case processing" in a subVI. This will make it a million times easier to debug and is a million times more expandable if things change down the line for "what inputs match what case".
If you have a proper grasp of binary numbers, that's not a million times easier. Maybe just a bit. It is a good idea to consider though.
Ehh.... I'd still want to separate responsibility, and it's always easy to get your endian-ness switched. Plus if this was me, I'd end up with some other condition I need to hit down the line ("ok if it's 1001 AND analog voltage is above 2.5 V, then do this, otherwise do this").
IMHO, if you don't actually need 16 cases but need to filter based on inputs, it's easier to have your truth table in a subVI rather than having each case be "0001..0100, 1010" etc. In my example above you would have three cases, 0000, 1111, and Default, which I agree isn't bad at all. It just comes when you need to combine random cases that it just gets neater (and takes less diagram space, and gives more room for comments) to just process it in a subVI.
For me, I'd use binary, but I've been doing binary for 32 years (almost typed 42 there).
It depends a lot on what you want to do in those cases. If it's a value, a lookup in a table can be useful (combined with the number). Sometimes all it takes is 4 cases in parallel.
For now, all those cases where empty, making it completely redundant.
All suggestions are better then the nested structures. Which option is best, depends on details, taste, and the definition of "best".
Search LabVIEW like a graph! 
wiebe@CARYA wrote:
@Yamaeda wrote:None i've reacted to, but some threads causes facepalms 🙂
/Y
Why isn't there a facepalm emoticon?
For now I'm using 😀🌴 (face + palm)...
LOL! Awesome! I'll steal that!
/Y
