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
>
- Replies:
- Re: Timestamping Confusion Ralph Lange via Tech-talk
- Re: Timestamping Confusion Michael Davidsaver via Tech-talk
- References:
- Timestamping Confusion Manoussakis, Adamandios via Tech-talk
- Re: Timestamping Confusion Michael Davidsaver via Tech-talk
- Navigate by Date:
- Prev:
Phoebus XY plot widget question Pietryla, Tony via Tech-talk
- Next:
Re: Timestamping Confusion Ralph Lange via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Timestamping Confusion Michael Davidsaver via Tech-talk
- Next:
Re: Timestamping Confusion Ralph Lange via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
|