Toggle Multiple Checkboxes with a Button

[jct254]

I have a system that is controlled with several checkboxes. As the system grew, the number of checkboxes increased and now its hard to use.

To improve usability I want to add "Select All" and "Select None' buttons on a momentary switch, and then be able to toggle the check boxes normally. So if I just wanted Checkbox Number 2 but had others selected already, I could just hit "Select None", and then toggle #2 as normal. And if after that I wanted all but #4 I could hit "Select All" and then toggle #4 off. Basically, the 2 Super toggles can't be a state they're in that overrides the checkbox control - they have to change the values instaneously. It also has to correctly display on the checkbox. 

First thing I tried was using a while loop and shift register to control the Value Property node [both Value and Value (Signalling)], and while it works when the condition should be true, when it should be false it rapidly pulses. I'm unsure why it does this.
I also built a system around a logic gate latch to control it, with the Select super-toggles tripping the set/reset depending on the current state, but its clunky, resource intensive for what it does and not easily extensible in any way.

Surely theres an easier way to do this? I've attached an image of the loop-and-register method (showing just one boolean, for simplicity) and included a usage example below in case my explaination is lacking.

Thanks in advance

As a usage example, say you have three checkboxes some already toggled on:
[1]
[0]
[0]
After Clicking "Select All":
[1]
[1]
[1]
After which I want to be able to control them as normal, so I could toggle the second check box as normal:
[1]
[0]
[1]
And then click "Select All" again:
[1]
[1]
[1]

[crossrulz · Accepted solution]

Use an Event Structure.  When the button is pressed (value change event), use a local variable to set the values of the check boxes.

[altenbach · Accepted solution]

---

@jct254 wrote:

First thing I tried was using a while loop and shift register to control the Value Property node [both Value and Value (Signalling)], and while it works when the condition should be true, when it should be false it rapidly pulses. I'm unsure why it does this.

---

You already got a solution, now let's look at why it acts unpredicably

• first of all, a  val(sgnl) property node make no sense since you don't have an event structure.
• You have a typical race condition, because the switch terminal gets read either before of after the property is written. Since there is no data depdency, it is not possible to predict the outcome.
• The shift register seems useless. because you could just place both controls next to each other.
• Your loop cannot be stopped
• Your loop spins as fast as the computer allows, using 100% of a CPU core and draining the battery of your laptop.
• A picture is very ambiguous. For example we don't know the mechanical action of the booleans.
• ...

In order to make the code scalable, you should us an array of checkboxes and write the rest of the code with scalability in mind. To add more checkboxes, all you should need is resize the array and the code should continue to work. Use the caption to label the array elements.

I would use a mixed checkbox To select all or none or indicate some, (but disallow mixed input). Here's a quick draft. Try it!

[ATEngine]

Add the event case below to the Autotestware 'Cluster Toolkit - Cluster Button Detector.vi' example.  You are now able to add, remove, and mix the buttons (check boxes, radio buttons, booleans) without having to add or modify any block diagram code.

[jct254]

EDIT: This was in reply to altenbach, if that wasn't clear.

Thank you very much for the informative solution and more importantly explaination. I'm very new to using labview, and I think I'm still stuck thinking in terms of written programming. 

As for why I was using the val(sgnl) property node, is honestly I'm still hazy on the difference. My understanding is that when changed it triggers as if the user had manually made the change, so I wanted to remove any variable in my diagnosis. As I mentioned I did try both "value" and the "value (signalling)" options, just happened that the signalling version was the one implemented when I took the screenshot. 

The shift register was an artefact of the previous version, in the future I'll clean up my code prior to posting to remove anything that like that that could be confusing. I'll also label the actions of the buttons next time. Didn't even occur to me, sorry about that. 

One final (I hope) question I have about this exercise is the differences between the Property Node and the Local Variable. From what I can see, you've used the Local Variable and I used the Property Node. Which is better for this instance? 

My understanding is that LVs are "memory intensive" and don't update the front panel from a sub vi but are faster, while PN's are the opposite. Wouldn't PN's better fit this implementation>

[altenbach]

Here we are talking about three ways to change the value of a control: local variable, value property, signaling value property.

(These of course also work to change the value of an indicator, but here we can most often just use a wire, right?)

There are endless discussion about the virtues of the various ways, but here's a quick summary:

Changing values of controls should be a rare occurence and mostly deals with user interface programming.

(If you need to regularly change the values of controls in computational code, something is wrong in the code design!)

Writing to local variables is efficient and fast. Basically the code updates the transfer buffer of the variable and is done with it. Shorty after, the UI thread will grab the value and asynchronously update the control. If you write to the same local variable millions of times per second, the user interface will only update as fast as you can see, skipping most of the intermediary values while the code itself always knows the exact current value.

A value property node executes synchronously, meaning the code needs to drop whatever it is currently doing, switch to the UI thread, update the control, and switch back to what it was working on earlier. This is many orders of magnitude slower. (Computers are fast so you won't notice a difference between a nanosecond or a microsecond unless you do it excessively or benchmark things).

A signaling value property is the same as a plain value property, but it will also fire a value changed event if there is an event structure case listening for that. (Writing to a signaling porperty will fire the event even if the value does not actually change. Writing to a local variable or plain property node will NOT fire a value changed event for good reason!)

Local variables and implicit property nodes only work on the diagram of the VI that contains the control. Explicit property nodes can be used anywhere as long as the control reference is available, so you can e.g. change the value of a control from within another subVI. There are plenty of other mechanisms the share data from multiple locations (DVRs, global variables, shared variables, etc.) but that's a different discussion.

As long as you stay in the VI that contains the control, value property nodes are not needed and local variables should be substituted. Only use value properties if you need to also change other properties at the same time e.g. if you change the visibility AND value of a boolean you might as well use one because the price for the property node has already been paid. Just ensure that you only write to the property node when the value has actually changed and not hammer it with the same inputs over and over).

This is it in a nutshell and somewhat simplified. You are encouraged to do your own benchmarks

---

@jct254 wrote:

My understanding is that LVs are "memory intensive" and don't update the front panel from a sub vi but are faster, while PN's are the opposite.

---

What's the opposite of "memory intensive"? My understanding is that both ways make use of additional data copies in memory, but that is completely irrelevant when dealing with scalars. Once you are dealing with large data structures (e.g. huge arrays), you need to start worrying about memory.