Can Event Structures Handle Big-Data Display Updates?

[AlexA]

Hi All,

I've been hunting for an explicit answer to this question but can't find anything. The question in a nut shell is:

 

Is it good practise to place potentially "big" (footprint wise) indicators such as graphs and charts in an event structure and update them via dynamic event?

 

Here's the context for my question:

 

Shown below is the block diagram of a UI component responsible for offering the interface to a particular hardware component.

 

The Event structure handles controls, the message handling loop performs value updates (updates the image display). I just assumed this was the right way round to do things but now I'm second guessing that assumption.

 

The following is the BD for the associated process (forgive the poor formatting, I'm still hacking things around consistently).

 

 

This design was originally motivated by having the process running on an RT machine and the UI on a windows machine. I've since moved everything to a Windows machine and am now wondering whether I'm doing needless message passing.

 

Does it make sense to cut out the messaging loops from both VI's, and mash the event loop which handles UI together with the task loop that monitors the FPGA? In this case, instead of sending a message with the DVR from the Task loop, it would trigger a Dynamic event (at a lower frequency, limited to 30 Hz display updates). The Dynamic event would update the image control.

Apart from my "known unknown" in terms of the event structure's ability to handle "big" data, are there any other gotchas with handling the UI purely in the event loop? One I can think of is that now important hardware state (such as an FPGA reference) has to be explicitly maintained in the event loop, this makes keeping track of everything easier but means that the hardware is tightly coupled to the UI.

 

Hope you guys can point the way,

 

Cheers,

Alex

[crossrulz]

I don't see why your UI loop would need to know the hardware state.  If it doesn't get a message, it doesn't care.

 

I find it is a lot better to keep things separated.  Use the event to update your UI.  Otherwise you will have to have your reading from the FPGA in the same VI as your UI to update your indicator.  GUI VIs get large enough.  I find it best to try to keep that as separate as you can.  Even the large amount of data that I have passed around has yet to cause any issues.

[JackDunaway]

I've been hunting for an explicit answer to this question but can't find anything. The question in a nut shell is:

 

Is it good practise to place potentially "big" (footprint wise) indicators such as graphs and charts in an event structure and update them via dynamic event?

 

 

Briefly, the LabVIEW Event API is incredibly performant, and even provides optimizations for sharing references to published events for multiple subscribers. This Github repo shows 13 separate demonstrations and benchmarks of the Events API. Performance is relative, but my instinct is that your throughput described above is well-within the LabVIEW Events capabilities as a transport mechanism.

 

If your application never needs to scale beyond a single LabVIEW application instance/context, the Events API will work well for all but the most extreme performance requirements; else, consider ØMQ or nanomsg or similar for more features and interoperability.

[viSci]

0MG, nanomsg... Now that would make an interesting VIShots episode.

[AlexA]

Briefly, the LabVIEW Event API is incredibly performant, and even provides optimizations for sharing references to published events for multiple subscribers. This Github repo shows 13 separate demonstrations and benchmarks of the Events API. Performance is relative, but my instinct is that your throughput described above is well-within the LabVIEW Events capabilities as a transport mechanism.

 

If your application never needs to scale beyond a single LabVIEW application instance/context, the Events API will work well for all but the most extreme performance requirements; else, consider ØMQ or nanomsg or similar for more features and interoperability.

 

Thanks for the info Jack, I'll check out the repo.

[drjdpowell]

I routinely use User Events to receive messages in anything that is a UI component, and often in things that aren’t a UI component (so I can give them a ‘debug’ UI if needed).  To me, the topmost loop you have is redundant; it does nothing other than stream the Event Queue into the Message Queue, with no ability to do any actual work (since it doesn’t have access to any state information) and it requires you to write lots of extra build-and-parse message code.  Pointless.

[Neil Pate]

I routinely use User Events to receive messages in anything that is a UI component, and often in things that aren’t a UI component (so I can give them a ‘debug’ UI if needed).  To me, the topmost loop you have is redundant; it does nothing other than stream the Event Queue into the Message Queue, with no ability to do any actual work (since it doesn’t have access to any state information) and it requires you to write lots of extra build-and-parse message code.  Pointless.

 

Pretty much all of my existing code used this two loop structure per module as well, but I have recently seen the light (drunk the kool-aid?) and swapped over to a single loop with the Event Structure just as one "step" of the module (now I like to call them Actors ;-)  .. Takes a bit of thinking about as any long running processes (i.e. stuff happening in another diagram) can really scupper things, so now you need to do things like spawn off workers etc.

[drjdpowell]

Takes a bit of thinking about as any long running processes (i.e. stuff happening in another diagram) can really scupper things, so now you need to do things like spawn off workers etc.

Didn’t you already have that problem?  If your “Do Action A” event sends a “UI—>CTRL:Do Action A” message to your second loop, nothing will actually happen till it finishes with “Somebody->CTRL:Do Long Running Action B”.

[Neil Pate]

Didn’t you already have that problem?  If your “Do Action A” event sends a “UI—>CTRL:Do Action A” message to your second loop, nothing will actually happen till it finishes with “Somebody->CTRL:Do Long Running Action B”.

 

Bingo! It just took me a bit of time to realise it :-)    

 

For a long time I resisted putting everything in a single loop as having the Event Structure in a separate loop kinda fools you into thinking you can respond quickly to events, but you cannot really as you say because the lower loop is tied up doing something else. 

[AlexA]

Hmmm, interesting. So do your low level processes trigger events which your UI is registered for? I'm trying to think how the one loop arrangement differs in anything other than an aesthetic sense?Also, if you need to save data, how does that work? Is the File IO actor event structure based as well?

[drjdpowell]

Hmmm, interesting. So do your low level processes trigger events which your UI is registered for? I'm trying to think how the one loop arrangement differs in anything other than an aesthetic sense? Also, if you need to save data, how does that work? Is the File IO actor event structure based as well?

Just to be clear, I’m talking about using a Message User Event created by the receiving module, instead of a Message Queue, and passed to other modules so they can send messages.  This is different that the archetypal User Event, which is created in the sending process and passed to other modules so they may choose to register.  The later is usually a separate User Event for each strictly-type message, while the former uses a weakly-typed message like the Lapdog message objects you are using.

 

Using a Message User Event is interchangeable with using a Message Queue, and avoids the extra work of sending messages from a separate event-structure loop.  I don’t really understand why your “File IO” actor is displaying “Microscope Images”, but if it needs to do UI work like that, then why not use an event structure?

[AlexA]

Ahh, there's a slight misunderstanding, the File IO is not displaying the images, that's happening in a separate UI actor.