[Kst] stripchart question

[Barth Netterfield]

The way we solved this in BLAST and BOOMERANG was to do as you suggested you 
didn't want to do: namely, write to a local file which kst reads from.  In 
the end, we went to this approch because:

-it is easy (TM)
-it gives you accesss to previous data which you have logged, but which has 
drifted past the end of the screen.
-it allows for more flexability in what fields you are monitoring
-disks are big, and deleting old files when the disk starts to get full is in 
practice not really a problem.  (We have ~400 100Hz channels for BLAST, only 
a subset of which we tend to look at at any given time... so the ability to 
pause, and pull up other channels, or look back in time is very important to 
us).

We use a very simple binary format (each field gets its own straight binary 
file, with a format file for the whole directory to desribe data types and 
calibrations) which kst can read.  If you are intersted I can send more 
information.

A second convenience item kst has is the concept of indirect (.cur) files: the 
program which is logging data writes a file (logger.cur) which just lists the 
directory of files we are logging to.  We refer to this indirect file in kst.  
Then if the logger restarts, or changes its directory, then kst automatically 
picks up the change.  This makes deleting old logger files easy.

cbn

On November 4, 2005 11:50 am, George Staikos wrote:
> On Friday 04 November 2005 10:45, Taco Walstra wrote:
> > On Friday 04 November 2005 15:53, Barth Netterfield wrote:
> > Hi,
> > sorry this is not what I meant. We've been using that for a few
> > experiments for slow datastreams to monitor 50+ sensors. However I want
> > to plot for example 10 streams with different frequencies (some are at 1
> > Hz, others at 50Hz for example) and sometimes lots of data. For this we
> > use a hacked c++ program which needs some refreshing, so I was wondering
> > if a small interface to kst would be a nice solution. Writing the data
> > from 3 different tcp sockets (each containing n streams) first to file
> > and let kst update this is not a real solution. I only want to send the
> > data directly to the plot from a small program and use kst as backend.
>
>    This is possible but it requires you to write a plugin.  You would need
> to write a new "datasource" plugin that emulates a file but reads data from
> a socket instead.  The only issue I can think of is that we probably don't
> gracefully handle a case where the datasource itself loses data at the
> start and picks it up at the end.  You would either need to cache all the
> data from start to finish, or we would need to make a small adjustment to
> Kst.  If caching is not possible, please file a feature request at
> http://bugs.kde.org/ for the ability to support such situations.