disadvantages of an event structure?

[johanneshoer]

Hello,

Everybody knows, that an event structure compared to a case structure has the advantage, that e.g. the status of a button  is not polled all the time.

Let's say I want to save a huge cluster of data.

1st option: wire the data cluster to a case event and then save the data to a file if a button is pressed.

2nd option: place a event case somewhere and create a "save button: on mouse up" event. then overgive the huge data cluster via a queue or a local variable and save it

I prefer the first option, because on the one hand the event structure does not poll the button, but on the other hand I have to overgive the data, which makes it either slow or complicated. do you agree?

 Johannes

LabVIEW 7.1

Message Edited by johanneshoer on 10-01-2009 11:32 AM

[Mark_Yedinak]

If you use a producer consumer architecture you should be fine. Your producer loop will contain the event structure and can process the Save event when the user presses the save button. Your consumer would most likely be a state machine. You may actually have multiple consumers depending on the application. The state machine would use a queue which would receive a message from the producer. This message would indicate that you need to save your data. The specific state in your state machine would get invoked and your data would then be saved. If data needed to be passed it could be part of the Save message. For flexibility I generally define my queue data as a cluster containing the message type (could be a string or an ENUM) and a variant. The variant allows me to pass any data type. The message type will dictate the data type for the message.

[hecmar.arreola]

No.  I disagree because I prefer using Event Structures whenever possible :P.

I'm not sure if I have my notifications worked out correctly here.  But I'd do something like this.

I think once the notification is released, the wait on notification will have an error which will term. the loop.  But I may have overlooked something.

-Nic

[F._Schubert]

Nic, nice scetch. But I would suggest a queue instead of the notifier.

Felix 

[Broken_Arrow]

---

F. Schubert wrote:

Nic, nice scetch. But I would suggest a queue instead of the notifier.

Felix 

---

I've read this sentiment a lot, and I don't really understand what people have against Notifiers. They are Perfect if:

1) You don't care that it is lossy and

2) You want to wait until you get data before acting on it - like a built-in event response.

Message Edited by Broken Arrow on 10-01-2009 02:00 PM

[johanneshoer]

Nickerbocker,

thank you for your help. The scetch looks good.

Where do I place other Code? Let's say I have an Input subVI and some data processing and an Output subVI (In and Out via an I/O module). Should I place all that in the upper loop besides the event structure? If yes, than that would mean I have the data available in the upper loop and have to overgive it somehow to the bottom loop. Then I need a queue. Right?

Johannes

[Broken_Arrow]

The title of your post made me immediately think of this. Check it out if you haven't already.

[F._Schubert]

Broken Arrow: My point against the notifier is the lossy behaviour. It doesn't matter in this small scatch. But if you scale that architecture much bigger, there are several issues where you want the lossless behaviour of a queue.

Johannes:

A detailed discussion of this design pattern can be found on Expression Flow.

Felix

[hecmar.arreola]

Hi Johanneshoer -

Sorry it has taken me so long to get back to you.  I would throw your other data processing code into seperate threads if I were you.  The point of the while loop that is handling the data, is to sit there and wait and not consume any resources until the button clicking event signals it to move forward.  Most of the time you would throw this kind of a save routine in your event structure, but your concerns about the data cluster being exceptionally large are valid.  So this solution gives you the event feature, without "tieing up" your event structure.

You don't really need to use a Queue operator for the data that is populating the cluster.  An Action Engine or even a simple Local Variable would work in transporting the data around.  When you save the data you are only concerned with the latest state of the cluster array, correct?  In this case a Local Variable would be appropriate (IMHO).  Remember, Local Variables must be used with caution.  Its easy to setup a race condition with them.  Still, I think in this particular scenario using them is appropriate.  You will have to decide that for yourself.

[hecmar.arreola]

How funny.  Snippets converted my local variables to Value properties.  I mean, that is what they are...but it makes the diagram harder to read IMO.