Re: Problems of Channel Archiver

["Bob Dalesio" <ldalesio@lanl.gov>]

For a 20 second save rate, it is most likely that the 
archiver is using a channel access get (ca_get). The time 
stamp in the archiver in this case, will be whatever the 
time stamp is in the IOC. This is a function of your 
timing system. If you have no timing hardware, it is the 
vxWorks close, synchronized with other IOCs using a 
network time protocol. It would be rare for the time stamp 
to be an exact 20 second interval. 
Bob

On Tue, 16 Mar 2004 12:40:37 +0100
 Thomas Birke <Thomas.Birke@bessy.de> wrote:
> 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

Bob Dalesio
ldalesio@lanl.gov
410 557 0297 Maryland
505 667 5643 Los Alamos (New Number)
505 699 1632 Cell Phone
505 667 6087 Our Secretary (Lisa Marie)