how would you do this (animated bargraph) (Neal Becker)

David Hoese wrote:


I do something similar to this where data that I'm plotting in a 2D line
plot comes from a UDP socket and some memory mapped files. To
accomplish the live updating I have a mix of your #2 and #3. I have a
main GUI thread that displays the plots, then I have a second thread
that gets data from a python generator and signals the GUI thread when
that new data has arrived. Inside the generator is where I have socket
communications and select calls. Hope this helps.

Haven't tried it, but I did notice QSocketNotifier, which sounds like it may be
what I need if I want to hook into qt event loop to implement as single-thread,



On 9/30/11 9:10 AM, > > wrote:

Message: 4
Date: Fri, 30 Sep 2011 07:37:49 -0400
From: Neal Becker<ndbecker2@...287...>
Subject: [Matplotlib-users] how would you do this (animated bargraph)
Content-Type: text/plain; charset="ISO-8859-1"

I just put together an animated bargraph to show results from a realtime

I used this as an example:

The tricky part for me was that in the original design, there was a realtime
process running. I have to write some information to my hardware (at a rate
about 1/360ms). To do this, I have a kernel driver that uses 'read' to tell
the user space when an interrupt has occurred, which is when the user space
should write new information to the hardware.

So I don't know how or if this could be hooked into qt event processing.
Just for a quick-and-dirty demo, I just removed the realtime processing from
the user-space and put it in the kernel driver, so now my bargraph display
can simply update on a periodic timer, and the userspace code has no realtime
requirement. But this is just a kludge.

So I wonder how other's would solve this? I'm thinking it would be either:

1) multi-process
2) multi-thread
3) 1 process, but somehow hook my realtime events into qt's event loop.

For #3, my device driver has a filedescriptor, that could use select to
detect the interrupt (rather than blocking read call).

#1 and #2 seem complicated.