I have generated a 4 element random array, numbered 1 through 4. I also have my 4 boolean buttons, which I'm trying to use as inputs. I'm trying to have the program generate the random order of the array, and then a user would press their four buttons in an order that they think is correct, without seeing the randomized array. If their order matches the one generated then an led will light up to show that they are correct. The user must get all four elements right for it to be correct.
I have used the riffle feature to create my randomized array. The array is simulating a set of 4 elements activating in a certain order, with the buttons just being what a user thought activated first. So if the order generated was 4,2,1,3 the user needs to press buttons 4,2,1,3 to be correct.
How do I connect my buttons so that the program takes the array and breaks it down element to element and matches them to a button?
You have 4 buttons, and you have an array of 4 "correct answers" that you have to match with the button pushes. To me, this suggests a loop (it should be easy for you to code this in LabVIEW:
For i = 1 to 4 do
Get a Button Press (from 1 to 4)
Compare Button to i-th "correct answer", save T/F in an array
You now have an array of 4 booleans that have whether or not the User pushed the correct button. It is a "Success" if all of the array elements are True.
I deliberately created an array of 4 answers as there is a function on the Boolean palette that will answer the question "Are all the elements True?".
Here is another suggestion -- instead of having 4 separate buttons, create a Cluster of 4 buttons.
Here's a Design Question -- is the user "guessing" the order? Is it assumed (or required) that the user push each button once, or could he/she push Button 1 twice (or 4 times, for that matter)? Do you want the buttons to act as "switches" (once pushed, it stays on) or as "push-buttons" (it pops back up when you take your finger off)? All of these are possible, governed (in part) by the Mechanical Action property of the button.
A particularly interesting way to organize the buttons is as a horizontal Cluster of 4 buttons, all set to "Latch when Released". If you put these in an Event structure, you can easily get both the binary value represented by the pushed button and the position (or number) of the pushed button. I leave this as "an exercise for the reader".
A final note -- if I believe NI's description of the Riffle operation, it is not the optimal method for producing a random ordering of N elements. It is, however, a "quick and dirty" approximately-OK algorithm ...
While you are thinking about the suggestiosn you have already been given, consider how you would write the program if an additional requirement was to allow the user to select the number of buttons (over some limited range). Some solutions which work for 4 buttons will not scale to 5 or 8 buttons without completely re-writing the program. However, I think there are solutions which will allow any number buttons from 2 to the maximum number which will fit on the screen.
The user is guessing the order. These buttons are supposed to be representing actual buttons that will be used later on. The user is supposed to try to feel something and then in the order that they felt movement they press the buttons. The user would only be able to press each button once, it should be a non-repeating random order. Which is why I used the riffle function since it was the simplest way I knew how to generate a random, non-repeating pattern.
Two weeks have gone by until you responded, so I guess this is a low priority concern of yours. It is not clear to me that you have considered the questions and suggestions made two weeks ago. However, you did give us a new requirement, so I'll throw it back to you. It seems to me that these are the "rules" of your game --
Note that in the absence of "clues" to the correct order, the chance of a correct guess is 1/(2^N), so with 4 buttons it is 1/16, about 6%. We've given you lots of suggestions -- now do some coding in LabVIEW (reread our earlier suggestions, particularly the ones about not having N individual Boolean controls ...).