event structure buffering?

[MikeW1973]

Hi all,

A quick question, if i have an event structure with lots of value change events for booleans, if 2 or 3 change at the same time or within a few milliseconds of each other does it buffer this event so that when it comes out of the event structure it knows another one has happened since it last went in? i.e. it could get a trigger for one, enter the event structure pass over a couple of ones that didnt trigger then get a trigger for them whilst its in it, but gone past them, then deal with the one that did trigger it and exit. Or perhaps i am not understanding how event structures process the value change triggers.

I hope i have explained myself well enough

Cheers

Mike

[falkpl]

Event structure is for processing user events (mostly)  which means that you should not have parallel events (can not click on 2 or 3 at same time or even several ms apart).  You should consider a queued event drivrn state machine if you dont want to miss any events.  Event cases will not have code but pass messages to a state machnie via a queue for processing, here you will have a very responsive system with event buffering.  What exactly are you trying to do?

Paul

[Pnt]

MikeW1973 said "so that when it comes out of the event structure it knows another one has happened since it last went in?"

Yes. As far as i know, events are buffering and it is NOT possible to miss one.

falkpl said "you should not have parallel events (can not click on 2 or 3 at same time or even several ms apart).  "

I agree that you should not have the same event in two different event cases (in parallel), but i disagree that there is possibility to miss an event. You don't need a queue. An event stucture is a kind of a queue. That's why NI implement it......

[MikeW1973]

Hi,

Thanks for the prompt replies, i basically have a multitude of digital in signals (about 40) and want to write event text away to a log on each input i.e. Doors Open/Closed, Vent Fan on/off etc etc. I thought the best way to do this and keep it all in one place might be to write the incoming signal to the value (sgnl) property of the LED therfore allowing  me to do a value change event for each one in a single event structure.

I was just wanting to make sure that if i did this and 3 or 4 signals changed within a few ms of each other that there was no possibility of an event change being missed, it would simply buffer one after the other and process them all.

Or perhaps this isnt the best way? in which case any thoughts?

Many thanks once again

Mike

[Pnt]

I don't know the details of your application, but it seems that you are in the right path.... keep walking...

[falkpl]

I was not refereing to placing an event in two seperate cases when refering to parallel events I was stating that a user can not change 2 button values at the same time.  User events will only happen 1 at a time since an event is generated 1 at a time.  Future OS might change this.  Does the event queue miss events closely spaced together when the event locks the front panel?  This idea of a queued event structure with a second loop alleviated any event which requires any time to perform an anction, this is why I use this architecture often.

Paul

[Pnt]

I agree...(5 stars)

But I don't think an event structure can miss an event.. Maybe someone can confirm that or not....

The queue makes the program more flexible and reliable, but for small pieces of code it is an "overkill"

[altenbach]

---

@Pnt wrote:

Yes. As far as i know, events are buffering and it is NOT possible to miss one.

---

I agree here. You cannot "lose" any events. Sometimes this is a problem as demonstrated (and solved) in this old discussion:

http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=207811#M207811

---

@Pnt wrote:
I agree that you should not have the same event in two different event cases (in parallel), but i disagree that there is possibility to miss an event.

---

LabVIEW will not allow you to place the same event in multiple event cases anyway, so there is no problem. However there is also no problem having two different event structures listening to the same event.