Event Structures?

[Aalenox]

I'm having a problem with multiple event structures firing incorrectly. I have attached a simple VI illustrating the issue. Basically, I want the user to press space repeatedly, but the event only fires once. Every event after incorrectly fires as if space was pressed again.

[RavensFan]

Read Caveats and Recommendations when Using Events in LabVIEW

You have multiple event structures all handling the same event.  Even when an event structure is not in the path of execution, it is still queueing up the events that occur.  So a single key down is getting captured for each of your event structures.  (And all are set to lock the front panel until the event case executes.  That is typically a bad idea.)

The stacked sequence structure is also a sign of a bad architecture.

What are you trying to do?  You should be able to program this so one event structure in a single loop handles each key press and keeping track of how many times the key was pressed using shift registers.

[Aalenox]

Basically, I working on a 'flicker' program to display images in rapid succesion for psychological research. The user will press spacebar when they notice the change in the image, and then click where the change has occored. I read the caveats and recommendations, and it suggested using dynamic events, which didn't seem to help. I showed the stacked sequence simply to illustrate the problem. As for locking the front panel, I have a timeout set to 0ms... I'm not sure how else to deal with this.

In short, I need the VI to recognize multiple keydown events, with executing code in between. So... spacebar pressed, code, space pressed, code... etc, and no matter what architecture I try, it seems to fail.  Any suggestions?

[RavensFan]

The timeout value has nothing at all to do with the locking of the front panel.

You need one event structure inside of one while loop.

See attached.

[Aalenox]

That won't work for what I need. Is there no way to do this with multiple event structures? It will be ... problematic to have this all within one while loop. In short, the while loop needs to timeout, and that timeout can't be attached to the event structure.

[RavensFan]

Then put a timeout there that will stop the loop.  You could also use an Elapsed Time Express VI as a means to determine when to stop the while loop.

DO NOT USE MULTIPLE EVENT STRUCTURES.  If you don't know how to use them properly, they are only going to cause you problems.

If you think a little bit, then I'm sure you can figure out how to take what I posted and modify it to do what you need.

[Aalenox]

So... what you are saying is that LabVIEW won't deal with multiple event structures of the same event, and that I am going to have to completely revamp my archetecture to deal with this issue. Gotcha. Any other language, this wouldn't be a problem. As for modifying what you posted, it will involve multiple case structures, which combined with event structures seem to cause their own problems. Also: I dispise the Express VIs ... in my experience they only cause problems and complications. Thanks for your help - sorta.

[altenbach]

---

@Aalenox wrote:

So... what you are saying is that LabVIEW won't deal with multiple event structures of the same event, and that I am going to have to completely revamp my archetecture to deal with this issue. Gotcha. Any other language, this wouldn't be a problem. As for modifying what you posted, it will involve multiple case structures, which combined with event structures seem to cause their own problems. Also: I dispise the Express VIs ... in my experience they only cause problems and complications. Thanks for your help - sorta.

---

Well, you need to blame your misconception about event structures (and dataflow in general) on the need to start from scratch. This is a relatively trivial programming problem and you'll get the hang of it with a little more effort.

If the example provided above does not suite your needs, please tell us the exact specifications how it should respond from the operator perspective. As a first step, try to do it without an sequence structures.

There needs to be exactly one event structure in a simple while loop, nothing more. listen to all keys at all times and simply discard the keypress if the time is not right. Do it all in code and don't gum up the UI with forced sequentiality.

It will be much easier than in any other programming language. 😄

[MaxCrunch]

---

@Aalenox wrote:

... Thanks for your help - sorta.

---

Most of the people who post on here are not employees of NI and receive no reward for their efforts. They provide support for other LabVIEW users simply because they like to help people.

You might want to consider that before posting ill-mannered responses.

[JarleEkanger]

---

@Aalenox wrote:

So... what you are saying is that LabVIEW won't deal with multiple event structures of the same event, and that I am going to have to completely revamp my archetecture to deal with this issue. Gotcha. Any other language, this wouldn't be a problem. As for modifying what you posted, it will involve multiple case structures, which combined with event structures seem to cause their own problems. Also: I dispise the Express VIs ... in my experience they only cause problems and complications. Thanks for your help - sorta.

---

Actually, what Labview does IS deal with the same event in all the event structures... More or less any other language is line-by-line sequential, and doesn't deal with an event in several event structures because they are lined up and idle until the execution reach their line. You just have to take in the importance of this, and realize that you can line up several calls to the same event structure, instead of subsequently call on a new instance of your event structure. And you do that by placing a single event structure in a while loop. If you need to roll on to the next image after a set time, you can fire an elapsed time event. If you hate the express VI, initialise a shift register with a tick count and compare to another tick count inside the loop. See attached pic.