Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Fri, 30 Jan 2009 07:19:14 -0600

camonitor now has a flag to print the local time on the client when a monitor callback occurs.  This can be very useful for solving timing problems, since it shows when the monitor was actually sent (well actually received) rather than when the record last processed.

Mark

________________________________

From: [email protected] on behalf of Goetz Pfeiffer
Sent: Fri 1/30/2009 3:08 AM
To: EPICS tech-talk
Subject: Re: wrong timestamps in monitors

Andrew Johnson wrote:
> Thus I think the fundamental issue here is not really in the database at all;
> I'd argue instead that the Channel Archiver is misusing the timestamp it gets
> from CA.  It would *like* it to reflect the time when the data was recorded,
> but the IOC has never claimed that it provides that information.  One could
> make that assumption for some channels, but not for all.
>
> I believe it is well-recognized that the status and severity of a PV reflect
> the state of the record containing that PV rather than the state of PV value
> itself.  If I'm looking at the DESC field of a record, I can still rely on
> the string returned even when the state I get with it is UDF/INVALID.  It is
> unfortunate that the similar disconnect may have been forgotten for
> timestamps.
>
>  
>> Is this going to be addressed any time soon?
>>    
>
> I suggest that the place to fix that problem is in the Channel Archiver, not
> in the IOC.  The configuration file needs to be able to tell the Archiver for
> each PV whether to use the timestamp from CA or to record a local timestamp
> whenever it receives a monitor callback or polls for an update.
>
> - Andrew
>  
I see that the current implementation is that a monitor
provides the timestamp when the record was last processed.

But if you look, for example, with "camonitor" on a PV,
you would expect the timestamp the program shows in the same line
has something to do with the time the PV changed.

Here I have an example:

U125ID2R:BaseParGapsel.B       2009-01-29 09:07:10.455966 150
U125ID2R:BaseParGapsel.B       2009-01-29 09:07:10.455966 1000
U125ID2R:BaseParGapsel.B       2009-01-29 13:26:11.956084 185

at 13:26 I wrote "1000" to the PV. The record the processed and
changed it's field B to 185. If I look at the output
I would assume that the value changed at 09:07. This is wrong
by about 4 and a half hours. I do not know how long in the past I stared
at print-outs from camonitor or the archiver trying to debug my
database and wondering what happened just because the timestamps
do not always show the time the PV did change.

The conclusion is that timestamps for non-value fields only show
that the value changed some time after the given timestamp, it may
be seconds, months or years later. I would expect that this
non intuitive behavior is at least documented somewhere. It obviously
violates the principle of the least surprise.

-- Goetz

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH  
Glienicker Straße 100, 14109 Berlin  
Vorsitzende des Aufsichtsrates: Dr. Beatrix Vierkorn-Rudolph  
Stellvertretende Vorsitzende: Dr. Jutta Koch-Unterseher  
Geschäftsführer: Prof. Dr. Anke Rita Pyzalla, Prof. Dr. Dr. h.c. Wolfgang Eberhardt, Dr. Ulrich Breuer  
Sitz der Gesellschaft: Berlin Handelsregister: AG Charlottenburg, 89 HRB 5583  

Information:  
Durch die Fusion mit dem ehemaligen Hahn-Meitner-Institut (HMI) ist  
BESSY nun Teil des neuen Helmholtz-Zentrum Berlin für Materialien  
und Energie (HZB).   

By the merger with the former Hahn-Meitner-Institut (HMI), BESSY  
became part of the new Helmholtz-Zentrum Berlin für Materialien und  
Energie (HZB).  

Disclaimer automatically attached by the E-Mail Security Appliance  
mail0.bessy.de 01/30/09 at Helmholtz-Zentrum Berlin GmbH.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System