03-23-2020 10:11 AM
Yup, my initial guess was correct.
What i described is what Frozen posts, do that instead.
/Y
03-23-2020 10:12 AM
03-23-2020 10:15 AM
@Frozen wrote:
Here is One way to avoid the nested case structures...
Just to add a bit to this method:
You can display the number in the case structure as binary so you can more easily visualize which case it is that you are editing.
03-23-2020 10:28 AM
@billko wrote:
Just to add a bit to this method:
You can display the number in the case structure as binary so you can more easily visualize which case it is that you are editing.
Interesting! I've never thought about that you can change the Radix! 😄
/Y
03-23-2020 11:00 AM
@Yamaeda wrote:
@billko wrote:
Just to add a bit to this method:
You can display the number in the case structure as binary so you can more easily visualize which case it is that you are editing.
Interesting! I've never thought about that you can change the Radix! 😄
/Y
I hope this makes up for the recent string of mini-faceplants that I've had lately. 😉
03-23-2020 11:09 AM
@billko wrote:
Interesting! I've never thought about that you can change the Radix! 😄
/Y
I hope this makes up for the recent string of mini-faceplants that I've had lately. 😉
None i've reacted to, but some threads causes facepalms 🙂
/Y
03-23-2020 11:23 AM
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". Use an enum to identify cases. In your "main program", use one case structure with that enum as its input. Have one enum for each case and combine cases in your subVI. If your logic requires 16 different responses, have 16 responses, but if it just has 3 responses, include them there. For example, if your logic is "If no inputs are True, write 'Idle' to the screen." "If at least one input, but not all, are true, write 'Processing' to screen." "If all indicators are true, write 'Finished' to screen". You can code that up very easily in your subVI.
03-23-2020 11:36 AM
@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)...
03-23-2020 11:40 AM
@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.
Sorry, this just has to be said...
03-23-2020 11:51 AM
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.
And...