Re: Problems of Channel Archiver

[Thomas Birke <Thomas.Birke@bessy.de>]

Wang Yanke wrote:

> Hi,
>  When I tried to archive the vacuum data with
> ChannelArchiver, I got some data like:
>
> 03/09/2004 15:58:23.254187014   0.000
> 03/09/2004 15:58:43.254186214   0.000
> 03/09/2004 15:59:00.000000000   0.000
> 03/09/2004 15:59:03.254185414   0.000
> 03/09/2004 15:59:20.000000000   0.000
> 03/09/2004 15:59:40.000000000   0.000
> 03/09/2004 16:00:00.000000000   0.000
> 03/09/2004 16:00:20.000000000   0.000
> 03/09/2004 16:00:40.000000000   0.000
> 03/09/2004 16:00:43.254181414   0.000
> ....
>
>  I have retrievaled it with CGIExport or ArchiveExport many times, but
> the results were disappointing.
>  So, Why can't I get the same proper value(e.g. 1.324e-07) as using
> "caget" instead of zero?
>  Furthermore, why the time interval is not the value i set in the .cfg
> file(20 seconds)?
>  Is there something wrong with the configuration of the ArchiveEngine
> or the retrieval tools?
>  How can I get the data I want? 
>  
The reason for that behaviour is, that the Export-functions of the 
ChannellArchiver
(every function, that formats floats/doubles into strings) honours the 
PREC-field of
the connected PV. It's like
           sprintf( "%*f", prec, value )

In some cases, it would be better to use engineering- or 
scientific-notation instead of decimal notation - or even ignore the 
PREC at all. As an exception, a PREC of 0 is indeed ignored...

We had the same problems with our vacuum values here at BESSY and 
started to store the logarithmic values instead.

The good thing is: The archive has all the values with full accuracy, so 
once you change the formatting of the output, you'll get your values 
just like you expect them to be.
But none of the bundled export tools ignores the PREC-field if it is set 
to something other than 0.

The "20 seconds" problem actually isn't a problem.
If a new value arrives via ChannelAccess, it is stored with the accurate 
timestamp. The other values are not even stored in the archive (Kay, 
correct me if I'm wrong). It's the output-functions again, that produce 
these repeated values.

I know this is not really helpful, but it's an attempt to explain what 
happens...
Is ther any guideline on whether and how to handle/honour the PREC field 
at all?

Thomas