Experimental Physics and
Industrial Control System

"Manoussakis, Adamandios via Tech-talk" <tech-talk at aps.anl.gov> · Fri, 11 Dec 2020 21:32:57 +0000

Thanks for the comments Michael, when you are dealing with hundreds of waveform records and the timestamps are being taken when each record is processed (I would assume these would all be off by some delay if multiple softIOCs are running) do you then just have a master time waveform to lineup all your other signals to t0?  It seems the digitizer would have a time stamp of t0 for all of its signals but the epics records would not all align at the same timestamp since each one isn't processed at t0 to be timestamped.

-----Original Message-----
From: Michael Davidsaver <mdavidsaver at gmail.com> 
Sent: Thursday, December 10, 2020 10:33 PM
To: Manoussakis, Adamandios <manoussakis1 at llnl.gov>; EPICS tech-talk <tech-talk at aps.anl.gov>
Subject: Re: Timestamping Confusion

On 12/10/20 2:18 PM, Manoussakis, Adamandios via Tech-talk wrote:
> Hey Everyone,
> 
>  
> 
> Looking for some clarification on how EPICs timestamps work in 
> general, with the archiver, and also what is the proper way to handle timestamps with hardware devices (eg digitizers).  My understanding of the timestamp is for example a waveform record will get a time associated with it (depending on if its from ioc boot or ntp) when it is processed.  But that may not be in sync with the digitizer itself own timestamp of when its capture a waveform.  If I then have the archiver monitoring that PV and the waveform is processed the timestamp shown in the archiver would be the timestamp that the record grabs at processing (which should be when say a value changed in the waveform triggering the processing of that record).
> 
>  
> 
> Is this correct way of thinking of the timestamping of the data for epics records?

What you describe, taking CPU time when processed, is the default.
However, it is not the only possibility.  When supported by a driver, the TSE field may be set to "-2" to allow the driver to provide a timestamp.  Further, as a special case, the TSEL field may be pointed at the TIME field of another record to copy timestamps between records.

eg.

> record(ai, "$(P)A") {
>     field(DTYP, "My Driver")
>     field(INP , "...")
>     field(TSE , "-2") # "My Driver" support must assign TIME
>     field(FLNK, "$(P)B")
> }
> field(ai, "$(P)B") {
>     field(INP , "$(P)A")      # copy value
>     field(TSEL, "$(P)A.TIME") # copy time }

> If so what is the best way to go about syncing multiple waveform records to make sure your data is synced, seems like your records might get processed not exactly at the same time?
> 
>  
> 
> Would it be best to create an X PV waveform record that stores the timestamps of the digitizer itself to line up with your Y PV waveform record?

Digitizers I've dealt with haven't needed a timebase (X axis) scale which changed between updates.  Usually I the only variables are sampling rate, and number of samples.

> Associated CS Studio question, if I pass my waveform record to a XY plot is the only way to plot against my time to create an X PV waveform and pass that as well to XY Plot, currently I only see a way to give it a min/max value for the x scale and have it plot the Y data per point.
> 
>  
> 
> Thanks
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System