How to detect the correct sequence of boolean switches pushed

[Ned_Kelleher]

Hello

My program does everything I want it too. However, I need to have the boolean switches (digital inputs when wired to hardware) be detected in the right sequence. There are 16 switches on a hardware board. The test subject is shown 3 colours before hand and the sequence of buttons to be pushed when prompted on the screen with one of the colours, each colour pertains to a specific sequence of 4 switches being pushed  out of the 16 as quickly as possible. The sequence of buttons always stays the same according to the hree colours red, yellow, blue.

In the program that is 99% working correctly I tried using a flat sequence. It will give me a true if i hit the switches correctly - but will also give a true if I hit them backwards etc... I thought a flat sequence was read left to right?

Then I messed around using a structured event - index the array of switches pushed and compare to an array control of values. I understand how it works, but the correct code is elusive.

I attached an image from the program I have done but missing the correct sequence. (Flat Sequence)

I attached the code for the structured event that i messed with. Don't laugh - I was just experimenting - I never used a structured sequence setup before.

Hope someone can help me.

Ned

[Oligarlicky]

If you want your code to go through a number of states in a very orderly manner, you might want to use a state machine. Here's a state machine using an event structure. The state is stored on the shift register and keeps track of what's happend previously. When the "right thing" happens, you move forward in your state.

When you are done with all your states, you wire "true" to the stop of the loop.

[natasftw]

What you posted is NOT a state machine.  It's a while loop.  But, the original poster should definitely be using a state machine.

The init flat sequence used below should be scrapped.  Replace it with a single Invoke Node initializing all values to default.  That does everything in that box in a much cleaner way.

In terms of the states, that depends on how you put the architecture together.  I can think of two ways to put states together.

The first:

Init

Wait for Events

Process Input

Process Output

Shutdown

Init sets the values to their defaults.

Wait for events waits for either the stop button to be pressed or any switch.  If the stop is pressed, it goes to shutdown.  If a boolean is pressed, it goes to process input.  Process input reads a value from a shift register (0,1,2) and uses that to insert the boolean's value into an array.  Then, it increments the value and sends it to the shift register.  If it's greater than 2, the next state is process output.  Otherwise, the next state is Wait for Events.  Process output verifies the array of inputs matches the desired outcome.

The other way would use a shift register to verify the value at each input.  If the first input is right, set it to true.  With each additional output, ignore the value if false (once the sequence is wrong, it's wrong so there's no point to check).

There's plenty to be found regarding state machines with a quick google search.  But, it's a while loop with a shift register, an enum with the possible states, and a case structure.  The case structure selects which state you're in.  The while loop keeps the machine running.  The enum is used all over the place to select states.  I'd suggest making this a typedef so it's easier to edit.

[Kurtlen · Accepted solution]

Hi Ned,

  Your Producer-Consumer model is actually very close to working.  In the original screen-captured version it looks like you're trying to use the sequence structure to capture the order, but in reality you will only capture the logical AND of all 4 buttons with no information about the order in which they were pressed.  The sequence structure does not by itself wait for an event to occur inside the frame, which means all 4 frames will be read as fast as the processor gets around to reading them - which will be very fast.

  I made some changes to your VI and renamed it Rev 1.  See if that makes a little more sense with the notes I made on the front panel.  I also did a different version with a single loop and some added functionality (-kb), just in case your'e interested in another way to look at it.

Kurt

[smithd]

An interesting but potentially overcomplicated way of doing this would be with dynamic registration and unregistration of events.

LVHelp:

http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/dynamic_modifying_reg/

Forum Nugget:

http://forums.ni.com/t5/LabVIEW/Nugget-of-the-week-Dynamic-event-registration/td-p/508407

To give you a specific example I've attached an event state machine I was playing around with (since I just learned about the above features myself and thought it was kind of neat). Mine is a bit overcomplicated for your needs since I have button presses which generate user events (rather than the button presses being the events) but the concept is the same. The user can always press other buttons, but they don't do anything until the appropriate sequence of events has fired.

[Kurtlen]

This was my first though for a solution - assuming most don't want to open the VI attached in my previous post.  Lots of other good ideas posted here as well.

Kurt

[natasftw]

While your result works, I'm going to point you towards dataflow: http://www.ni.com/getting-started/labview-basics/dataflow

Get out of the habit of using the Flat Sequence Structure.  What you're doing with it is useless.  You're just adding things to your diagram.  There are very few uses for the structure.  This code isn't one of them.  As an example, the structure on the right requires inputs for each function.  Until it gets those inputs, it won't do anything.  Using the FSS isn't enforcing the sequence, dataflow is.

[Kurtlen]

  You're absolutely right the sequence frame on the right is not needed or useful here.  I thought the original poster might benefit from a generalized approach to handling a user interface panel.  Sometimes it can be useful to clearly identify different functional blocks, and there are times when functionality may be needed post-processing that is not data-dependent in other ways - although this was not the case here.

  In general I agree with you - I am not a fan of the sequence structure either.  I have found that at times using a single frame is helpful, as in the example I posted.  I fully understand why you disagree.

Kurt

[Ned_Kelleher]

Thank you for the help. I wanted to open the vi's this morning - but I use 2009 at work....2013 at home.

Thanks again!

[Oligarlicky]

Here's my code saved for 2009

[Kurtlen]

Here's a code snippet that you can drag and drop to a LV 2009 block diagram.

Kurt

[Ned_Kelleher]

Hey Kurt

I will try to incorporate your code into my vi.

I will go with the first vi you attached earlier.

Get rid of the while loop

Thanks for the help.

I will post the final product when done.

[Ned_Kelleher]

Hey

Here is the final VI

I attached version 9

version 13 and a pdf directions doc

Thanks for all your help!

[Eric1977]

Why are you resisting using the state machine for this? You could to all of that on a much simpler code structure.

If I had to modify your code, I'd scrap it and reprogram it. too complex and your block diagram is MASSIVE.

[Ned_Kelleher]

I have never used or programmed a state machine

I am not sure how to begin.

[crossrulz]

Start by reading this: Application Design Patterns: State Machines.  If you look in the project templates, there should be a simple state machine to give you a start.  State Machines can be really simple and are very powerful.

[Ned_Kelleher]

I get it.

So my states:

• Initialize transition black to....
• Red/Process button sequence
• Blue/Process button sequence
• Yellow/ Process button sequence
• Random/Process button sequence
• Interupt Process button sequence if error
• Display pop-up/write to file for successful trial
• Display pop-up/write to file for unseccussful trial
• Reset or Stop

All can be done using this architecture?

It would be easier now that i know what to do with the coding

Thanks!

[Eric1977]

Yes. You can use those states to do everything you need to. If you need more states, that's fine. You can have an infinate number of them. Think of a flowchart when you design it.

I would strongly suggest using a 'Wait on Event" state and place a Event Structure within that state so your not pooling and using up CPU resources. Look them up. Another powerful tool you can use with the State Machine.