Interlinked Button Control

[shultz58]

---

@smercurio_fc wrote:

---

@shultz58 wrote:

Using  ABCPrograms response, I was able to contruct the following. It should do what I want. However, I am unsure how to update the cluster I am modifying. If someone can figure out how to apply these changes, we should have a solution to the problem. (Problem solved and kudos will be given!) I feel as if there should be another block after the Bundle by Name block.  

---

A simple local variable will solve that problem.

However, as pointed out, the Stop button cannot be outside the loop.Once read, the original value is passed through the tunnel, and from that point on, that's all that the while loop sees. Basic dataflow. You need an event case for the Stop button. Be sure to place the button inside the event case.

The same holds true with the way you're tunneling the cluster, although in this case it doesn't affect you. The value of the cluster gets read and passed into the even structure. The event structure sits there waiting for an event. If the cluster is changed in the meantime, the event structure will not see the new value, as it's seeing the value of the tunnel as it was originally set when the event structure received execution focus. But, in your case this little nuance won't affect the operation.

Also, your Boolean logic doesn't make much sense. (A ^ B) ^ A  is the same as A ^ B

---

Smercurio_fc,  indeed you are right. I have fixed it to reflect what I want. Also added an event so that when Run is clicked, the loop stops.

[shultz58]

---

@ABCPrograms wrote:

ok, so this is it.  you don't want to use the disable buttons any more, but just want to ise the LED's

See solution in attachement.  Normally we use VI snippet, but have no idea if you know what it is 😉

---

Its very close to what I want. The only thing that lacks is the button leds do not light, to indicate which ones are pressed in/active.

Please take a look at the most recent code i just uploaded. Im hoping a minor change can make it work. I under stand my boolean method a bit more.

[smercurio_fc]

You need to use a local variable of your cluster to write the new value to it. Please look at the example that was posted. You will see how a local variable is used there to update the cluster. Eliminate the code you have to unbundle those elements that's sitting outside the loop.

[shultz58 · Accepted solution]

---

@smercurio_fc wrote:

You need to use a local variable of your cluster to write the new value to it. Please look at the example that was posted. You will see how a local variable is used there to update the cluster. Eliminate the code you have to unbundle those elements that's sitting outside the loop.

---

I was wondering what the symbol was. Didn't know where to find it until you mentioned it by name. And as mentioned, it was the missing piece to the puzzle (along with a correction in one of my logic gates). Special thanks to smercurio_fc and ABCPrograms!

You mentioned the way I controlled my loop. Is the following way a proper way to stop it?

[Mark_Yedinak]

A shift register would be a much better solution.

With respect to your user interface having buttons that may or may not do something when pressed is a poor design. The user has no idea when something is available or not. At a minimum should should at least gray out the invalid buttons to provide the user with some useful information.

DOes your "Run" button change its text to reflect it has changed to now mean it will stop  the program? Again, the UI should be intuitive and let the user know how it functions. A better approach would be to have both a run and a stop button. You can place one on top of the other and change the visibility of the button that is not functioning. For instance when the program starts the run button is visible and the stop is invisible. When the run button is hit make it invisible and the stop button visible. This provides the user with a clearer picture of how to use your application.

[shultz58]

---

@Mark Yedinak wrote:

A shift register would be a much better solution.

With respect to your user interface having buttons that may or may not do something when pressed is a poor design. The user has no idea when something is available or not. At a minimum should should at least gray out the invalid buttons to provide the user with some useful information.

DOes your "Run" button change its text to reflect it has changed to now mean it will stop  the program? Again, the UI should be intuitive and let the user know how it functions. A better approach would be to have both a run and a stop button. You can place one on top of the other and change the visibility of the button that is not functioning. For instance when the program starts the run button is visible and the stop is invisible. When the run button is hit make it invisible and the stop button visible. This provides the user with a clearer picture of how to use your application.

---

I would agree if the buttons didn't have LED's in them. The LED implies that the button is "on". It is much more visually appealing than a grayed out button. I do agree that upon pressing run, graying them out would make sense. And in fact, it is what I'm searching for right now. I'm very new to Labview, and I'm learning as I go. If you have any tutorials that you recommend, please forward them my way.

The system I am coding for is a pneumatic system that relies on python code. So after run is pressed, It will run a script based on the selection made. Currently I am considering having the run button pressed in while is running, and once the source reaches its destination, the button becomes unpressed (popped out position). I'll take a look at the shift register you mentioned to see what it is, and how it would fit in.

Thanks for the input!

[shultz58]

---

@Mark Yedinak wrote:

A shift register would be a much better solution.

With respect to your user interface having buttons that may or may not do something when pressed is a poor design. The user has no idea when something is available or not. At a minimum should should at least gray out the invalid buttons to provide the user with some useful information.

DOes your "Run" button change its text to reflect it has changed to now mean it will stop  the program? Again, the UI should be intuitive and let the user know how it functions. A better approach would be to have both a run and a stop button. You can place one on top of the other and change the visibility of the button that is not functioning. For instance when the program starts the run button is visible and the stop is invisible. When the run button is hit make it invisible and the stop button visible. This provides the user with a clearer picture of how to use your application.

---

I've looked into shift registers. The concept is interesting, but unlike the event structure, I can't override the LED on the buttons. Maybe I'm not understanding something, but I don't see how to do it with shift registers, as there is only an input. Ultimately I wanted a button with an output ,as a regular button, and an input, so that it can be overwritten by the system if necessary. The user would know the system made a correction because the LED on the conflicted activated buttons would turn off.

[shultz58]

Any way to Give the modify cluster an intial value? I've been trying to do it with shift registers, but it does not want to link up. Upon pressing run, they disable the input interface.

[smercurio_fc]

You're still not getting it. You're not understanding data flow. The bottom part of the code below the event structure is completely meaningless. I don't know what you mean by you not being able to "link up" the shift registers. I tried to open your VI, but was unable to do so - it appears to be a corrupt upload.

[shultz58]

Re-uploaded. Opened it to double check it works. I'm running LV 2010.

As for the data flow, where do you see my error? I was thinking about incorperating the shift registers on the main loop, where it would be enabled my default, and one of the cases would cause it to switch to disabled.