Generate User Event or Notifiers - which is best?

[Madri]

Hi! New to LabView (Using 7.1) and I'm using an example found here using "Generate User Events" to eliminate the need to poll the serial port. I'm using an event structure for transmit, stop etc and included some user events that fire after I've received data on the serial port (RS232). I'm using two while loops - one to see whether a event occured on the serial port and one for the event structure. This works fine, but now I've seen some examples on notifiers and I'm wondering if this is a better way of doing this - any examples?? I want my serial functionality (send/receive) to be interrupt driven. Thanks alot for any help and/or ideas, Madri

[Victrick]

Interesting question...

I've done some work with User Events and Notifiers and the following advice comes from my experiences with them. Corrections welcome.

Notifiers are much simpler objects than User Events. Notifiers hold EXACTLY ONE notification. The LAST notification to be sent will be stored in the notifier, and will overwrite the previous contents regardless. This means depending on how fast you need to handle events triggered by the serial port, you may miss events. To the best of my knowledge, User Events queue all events until they are handled but this can be a blessing or a curse. As long as you're not overloading the Event Structure, you don't need to worry about a missed event. However (as far as I know) there aren't built in ways t
o dump the queue whe it gets too large(I have encountered situations where there is SERIOUS lag because the Event Handler got bogged down and the events queued up like whoa. Mind you, that also might have been due to crappy design.)

I use notifiers wherever they can possibly do the job, since they are the simpler and thus I assume the faster of the two. I find notifiers to be ideal for state machines.

I can't make a recommendation because I don't know what the final goal is, but you might not need notifiers or user event structures - you often can come up with more creative solutions that might do the trick, like accessing a common VI with uninitialized shift registers.

I'm very interested to hear any other replies on this topic.

[Madri]

Something I was also wondering about - this is why I'm really looking at notifiers in the first place: in the event structure - does it wait for one event within the structure to complete before it will recognise and execute for example the 'stop' button etc, thus making the GUI sluggish?? Could this become a problem as the structure becomes HUGE, handling user events, menu, buttons and more? I don't want to loose data, but also want the 'feel' of the GUI to be nice. Thanks for your previous answer! Please reply - eager to learn, Madri

[Victrick]

This is what I'm talking about with events being queued - The event structure can only be executing one frame at a time - if you are handling a lengthy event and the user clicks on the quit button, the button will probably stay depressed until the current event terminates, at which point the quit event will then be handled. This is definitely *very* undesirable behaviour for a GUI.

I don't think the number of cases being handled by an event-structure has any bearing on how it executes (someone please correct me if I'm wrong), it's primarily the contents of the event structures that dictate how long the event case will take to execute.

If you want to have a nice responsive GUI, events are the only way I would go. To prevent user-events fr
om queuing while you are executing some complex case, try using the Cursor VIs found under the "Application Control->Cursor" menu of your block-diagram palette. These VIs allow the cursor icon to be changed to an hourglass, and ignore all user-interactions while you are doing some lengthy processing. This will prevent the user from interacting with the VI during long-processing stages, so that when they do indeed interact with the VI, the VI will be able to respond quickly. I hope that helps

[Madri]

Thank you so much for the reply - learning something new every day 🙂

[dwisti]

I use the event structure to enqueue elements for a queue based state engine. I try to minimize the code within the event structure and pass the work on to other loops. This keeps the GUI very responsive. Then, you can programmatically manage the queue-based state engine in those loops. If too many events fill up in the state engine you can flush the queue.

[Victrick]

Clever - I quite like that approach.

Originally when I was having problems, mainly programmatically generated user events were getting queued. I considered sending more information with each event - like the time it was fired and priority -but that wasn't a very pretty solution (and hence why I didn't implement).

I *really* like your idea though - in fact kudos on that one - and I'll keep it up my sleeve for rainy day.

[Madri]

That sounds exactly like what I wish to do - do you have an example you could post or even a screen shot so that I could get the idea? This could be the light in the tunnel, so to speak :-). Thanks alot, Madri

[Ben]

This is a Queued message handler architecture. Various design patterns are discussed here.

http://digital.ni.com/demo.nsf/websearch/2B074F767D74CE0786256D0100791858?OpenDocument&node=157200_US

or

http://zone.ni.com/devzone/learningcenter.nsf/03f7c60f17aad210862567a90054a26c/338ee44cb1c3450986256c2b007cf8c5?OpenDocument


Queued message handler with notification example can be found here.

http://sine.ni.com/apps/we/niepd_web_display.DISPLAY_EPD4?p_guid=B45EACE3D9CD56A4E034080020E74861&p_node=DZ52061&p_submitted=N&p_rank=&p_answer=&p_source=External

or

http://www.ni.com/devzone/lvzone/apd.htm


Jim Kring's contribution is a wondeful example of how to write re-usable code. Check it out!

Ben

[Victrick]

Here's a sample VI of what the above design suggests to me. As I've commented on the block diagram, if you are handling a LOT of events, you might like to have multiple queues, each with it's own priority rating, allowing you to clear old, no longer relevant events in a faster manner when there has been a slow down. I haven't looked at the above links though, I started working on this sample before I saw those links, so I imagine they would be quite helpful once you sit down and work through them.