[Kst] Real-time data display without files ?
Matthew D Truch
matt at truch.net
Sun Apr 23 16:05:22 CEST 2006
> Following on my earlier post, I have a more generic design question:
> Can I build a plugin that 'just listens' and gets data from
> some other callback mechanism -- without requiring a file?
> The answer is probably provided in a thread from September 2004
> and may simply be 'nope' but I thought I'd ask anyway.
Yes, you can build your own plugin to do that; however, none of the
*existing* plugins shipped with kst do that. Eventually (perhaps quite
quickly) your datasource would consume a large amount of memory to hold
the past values that you are reading (until a restart of kst of
what-have-you), but that's really your only obstacle.
> My data can come in at maybe 200 to 300 updates per second at peak. I also
> may want to view and relate several such streams. As a start, I should be
> able to plug into that data pretty easily via code that listens to our data
> streams and emits csv data (for which I may just have to reformat the time
> stamp to get suitable 'ctime' seconds for kst).
> However, for efficiency, could I just 'listen' to data that is not coming via
> files -- without re-architecting kst? It just doesn't seem right to divert
> all that data to file only to read it back later. (I should note that we
> already have existing logging and capturing mechanisms.)
As you state, you already log and capture your data. The 'standard' kst
(as in it's how kst was originally intended) way of doing things is to
have kst read the data from the logs. It is true that you are diverting
"all of that data to file only to read it back later," but 'later' may
be milliseconds, not seconds (or longer), provided the logger flushes
the file it's writing at regular (as fast as you want) intervals. As
long as kst can read the type of file that the 'logger' generates, kst
can plot the data 'real time' with new data appearing on the plot 'as
soon' as it is captured and written by the logger, where 'as soon' is
defined as with an on order 100 milliseconds delay.
Of course, if you don't want to log all data, then this forces you to
log some data you don't need, but you can easily delete it at a later
time. However, versus the method where the kst datasource reads the
captured data itself into memory, it gives you the added benefit that
you may look at data that occurred before that kst instance was started,
including just before.
Whichever route you choose, let us know how you're doing, and we'll help
out wherever we can. Good luck.
"Duct Tape is like the Force. It has a dark side, a light side, and holds the universe together."
Department of Physics
matt at truch.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kst/attachments/20060423/4df9965b/attachment.pgp
More information about the Kst