Reading from Radio Buttons

[Igorina]

Hi All,

I am writing a large program in LabVIEW and one aspect of it is a quiz-type structure. There are 4 possible answers to each question (a, b, c or d) which correspond to a cluster of 4 radio buttons. The quiz questions and answers are stored in an array. The array contains 5 columns; the first (0) contains the questions and columns 1-4 contain the four possible answers. The fifth column is a number corresponding to the correct answer i.e. 1=a, 2=b etc. In order to check if an answer is correct, when the user clicks the"NEXT" button, the radio buttons are read. If the answer is 'a', a '1' is output, if it is 'b' a '2' is output etc etc.This output is compared with the fifth column of the array and if the two match, TRUE is output, turning on an LED. However when I run my program it will not let me select an answer i.e. one of the radio buttons, even though I have them in a while loop.

As the programme is much bigger than just this quiz aspect it is a bit large to post. I have included a screen shot below which may help (but also may confuse more!).

Thanks!

[Gak · Accepted solution]

From your diagram, I can see "Radio Buttons" is Indicator and not Control.

To select an option you will have to make it Control. 🙂

[Igorina]

What a silly mistake - thanks so much!

[paul_a_cardinale]

Change your radio buttons from an indicator to a control.

[altenbach]

You already got a bandaid fix for the problem, but your issues are much deeper.

You are apporaching LabVIEW from a text programmers perspective, using controls/indicators as variables that you "declare on the left side" and access via local variables. This blurs the inherent distinction between controls and indicators. and disables all built-in safety mechanisms.

• Interactive loops don't belong inside event frames and it does not make any sense here. That loop is not doing anything useful. What is "stop 2" for?
• Why do you need to read "question number" in all these different places. Eliminate the locals and keep/increment the value in a shift regsiter. No local variables needed. Same for "array".
• The sequence structure is useless once you eliminate the locals, because the execution order will be determined by dataflow.

Can you attach your code so we can have a better look?

[Igorina]

Thanks for getting back to me. Yes I am originally a Java programmer so I am just getting used to LabVIEW. I started writing this program, then kept adding to it and adding to it, hence all the local variables. I was planning on heavily refactoring the code when it works. For someone who is very new to LabVIEW I find it easier to start off like this then refactor - maybe it's a bad method.

I am afraid I can't attach my code as the project I am working on is confidential

Thanks again for your help.

[Igorina]

I have decided to go backwards a bit...I have attached a simple bit of code which I am hoping you will be able to help me with. I am hoping my comments on the code will explain what I am trying to do. My problem is that when I update the array, the next time I press the button it wipes it.

[altenbach]

Try something like this ....

[Igorina]

Thanks, I managed to come up with a similar solution myself however I feel yours is perhaps more efficient.

[altenbach]

Yes, an event structure is better, but I did not want to go there since you did not have it.

• Your timeout event is not used, delete it.
• There is no event for the stop button, so the code cannot be stopped until the next answer is checked once more.
• You can keep the solutions in a numeric shift regsiter or the correctness in a boolean SR, same difference.
• However, if you do it your way, you can just wire the boolean array to the comparison output. No "initialize" or "replace" needed for the boolean array.
• "Check answer" should be latch action
• Make sure the diagram constant are the correct datatype. For example the orange [5] should be an integer.
• The comparison should be before the event structure, else the displays will be incorrect until the first answer is checked.
• You don't need these complications with the inner case, you can compare the enum with a numeric directly.
• ....

Here's mine with events.