06-20-2023 08:21 AM - edited 06-20-2023 08:23 AM
Maybe all you need is a single cluster of booleans. Here's a quick draft. Later you can iterate over the enabled/TRUE controls to do the experiments in sequences (not shown).
06-20-2023 09:06 AM - edited 06-20-2023 09:18 AM
@crossrulz wrote:
@RTSLVU wrote:BTW: If your program architecture was a State Machine instead of One Big Loop either solution would be quite simple to implement without a bunch of convoluted logic.
I'm not sure you actually need a State Machine. I think the OP can accomplish the desired effects with a simple Event Structure inside of a loop. Initialize "4" to be disabled until 1 and 2 have been ran. With the Event Structure, it is easy to react to each button individually and keep track of what measurements are complete in a shift register.
Sure, but I try to get people away from using OBL (One Big Loop) program architecture as soon as possible.
I know it seems like overkill for simple programs but, more than one of my quick and dirty programs have grown into larger more complex programs. Leading to some pretty ugly LabVIEW code and eventual complete rewrites using a proper architecture.
Even a simple State Machine scales far easier than OBL with convoluted logic when test steps are added, removed or reordered. Especially in the OP's case where certain test steps rely on results from previous steps.
BTW: Here is example of what OBL can become when left unchecked.
06-20-2023 09:14 AM
@RTSLVU wrote:
Sure, but I try to get people away from using OBL (One Big Loop) program architecture as soon as possible.
In this case, OLL (One Little Loop) might be sufficient, though. 😄
06-20-2023 09:24 AM
@altenbach wrote:
@RTSLVU wrote:
Sure, but I try to get people away from using OBL (One Big Loop) program architecture as soon as possible.In this case, OLL (One Little Loop) might be sufficient, though. 😄
Sure if all the OP needs to do is toggle Boolean indicators on and off, but I am guessing this theoretical exercise is laying the foundation for a larger test program. MIght as well point them in the right direction from the start.
06-20-2023 09:40 AM
Just playing with the acronyms...
Here, the OP started with a OGLFL (One Greedy Little Forever Loop). 😄
06-20-2023 09:49 AM
@altenbach wrote:
.... Later you can iterate over the enabled/TRUE controls to do the experiments in sequences (not shown).
Here's how it could do all scheduled experiments in "OLL" using the timeout event.
06-20-2023 11:10 AM
Some have suggested using Value property node but it basically hardcodes the value, so if Measurement 5 is not enabled, I cannot enable Measurement 1.
I will look into State Machine and Event Structures, haven't used either in LabVIEW yet.
My actual code is using One Big Loop architecture apparently, I'm using error in/error out inside one big while loop to establish sequence of execution. It works but navigating becomes very very difficult, program occupies multiple screens.
Perhaps for future work I'll try to do it right but for now I'll just use OR gates, my code is a mess already.
Thank you for explaining!
06-20-2023 11:30 AM
@John32d wrote:
Some have suggested using Value property node but it basically hardcodes the value, so if Measurement 5 is not enabled, I cannot enable Measurement 1.
In your original post, you have 100% correlation between value=true and state=enabled. You can easily modify my code to do something else, e.g. enable certain other switches based on the first selected switch. In that case you probably need a secondary "reset" button to set things to default. You have not defined the entire dependency table and how they are correlated. For example, if you turn on #7, which would enable 2&3 and then you turn on 2, would that enable other buttons if needed?