Community Nugget 2009/03/13: An Event based messageing framework for larger applications

[Jarimatti]

---

F. Schubert wrote:

 

Message Edited by F. Schubert on 03-13-2009 12:13 PM

---

I'm curious about the flushing of registered events from caller here. I think that it may be unnecessary: the Event Registration refnum starts to collect events only after the event has been registered. Or is there some other reason for it to be there?

Anyways, thanks for the great framework! I had a similar idea, but this is so much more elegant and beautiful.

[F._Schubert]

There are some issues in LV 7.1. when using user events that extensively. A certain issue is, that destroying the event before unregistering it - crashes LV. These issues seems all to be solved in LV 8. There are also issues with the registration as well, but I didn't dig into these issues and feel safer with the flushing.

You could write a test where you send several messages before/while calling this vi and take a look of how many events where actually flushed. If this is 0, you don't need the flushing.

One issue I found, that sending 2 events straight one after the other can lead to missed events when using the filter vi's (so they have a Generate Event inside the event structure). A 1ms wait did resolve it.

But due to time shortage, I stopped testing the limits of the framework until I get an upgrade to a newer LV version. On the daily basis it works reliable. 

Felix 

[Jarimatti]

Ah, that's the case then. I'm using LV8.6.1, so I suspect the event system has seen some work in that regard.

I'm actually implementing a UI with a plug-in system, which ideally allows the plug-ins to be (un)loaded during runtime.

So far the messaging framework seems to work as expected. I noticed that I did have to separate a DAQ loop (1000 ms timeout) from normal message handling loop, as the timeout was rarely fired. That was my own stupidity, as the average message interval was less than 1 second. 🙂

So far so good...

[ASTDan]

I finally get it!!

I found a good use case for this framework.

Thanks for sharing.

Dan 

[Tushar_Jambhekar]

Interstingly We are also using an architecture that has mostly the same features as you have described

>>Each message consists of a message ID (string) and some data (variant).

>>These messages are passed as User Events through delivered to the queues of listeners in the application.

>>"Talkers generate the Events and Listeners register for the ‘Message Event’-User Event. Listeners have a case structure VI has a state in state machine for the Message ID string to react on some of these subscribed Events, discarding all unknown Events in the default case.(the mechanism delivers msg to the listner only if he has subscribed for it)"

>>The most important Event is the Message ID ‘Exit’, which causes all Listeners to stop

However the way we have implemented it is bit different.

following video describes the implementation.

http://www.youtube.com/watch?v=wgoUdb441Ek

Also find attached framework source code

[F._Schubert]

Tushar,

I like the Monitor App window. Nice work you did!

Felix

[GollumGTH]

Correct me if I'm wrong but it looks like Tushar's code is constantly polling for updates, so wouldn't this be an inherent drawback compared to the event based system?  That being said the monitor vi is really cool.