RE: Timestamping Confusion

["Manoussakis, Adamandios via Tech-talk" <tech-talk at aps.anl.gov>]

Thanks for all the responses, the community is great here.  It seems to be a lot more complex of an issue then first thought but did learn a lot about the timestamp system either way.  Andrew thanks for the information, I will attempt to go down that rabbit hole some and see if I can figure out how to convert between the two timestamp formats.  I thought labview stored there timestamp in useconds but would need to double check.  From what you stated

 

It seems like I should be able to take the labview timestamp get it into useconds/nanoseconds, then store it in the asub record to eventually get the time field filled or am I oversimplying the part about taking labview -> epicstime?

 

From: Johnson, Andrew N. <anj at anl.gov>
Sent: Monday, December 14, 2020 4:12 PM
To: Manoussakis, Adamandios <manoussakis1 at llnl.gov>
Cc: EPICS tech-talk <tech-talk at aps.anl.gov>
Subject: Re: Timestamping Confusion

 

On Dec 14, 2020, at 4:57 PM, Manoussakis, Adamandios via Tech-talk <tech-talk at aps.anl.gov> wrote:

 

Ah sorry, I misread about the TIME field I thought it was only not readable but would still be writeable.  Currently we are using a labview driver to talk with some of the NI hardware and I don’t have direct access over how they implemented it to use the device support to set it.  It seems the driver has the ability to caput and is what we have been doing to add data to the waveform records we need.  Is the best route then to

 

keep TSE=-2 ( I assume this still needs to be set so that the time field doesn’t get set by another means?)

create a PV to hold the timestamp from the digitizer

have a FLNK push the timestamp to the TIME field of the record A (is this possible?)

have TSEL copy that timestamp to all other records

 

 

The easiest way I can think of your being able to push a timestamp into an IOC would be to create an aSub (array subroutine) record with an input that will accept the timestamp (see below), set TSE=-2 for that record, and have the subroutine itself copy that input value to the record’s TIME field when it processes. Then you point your other .TSEL links to this .TIME field. You don’t have to set their TSE fields as well, the code checks whether TSEL points to a .TIME field first and reads that instead of the wall-clock time if it does.

 

There are some minor complications to be aware of though.

 

1. What format does your LabView system have the time available in? If you’re at all concerned about performance you probably don’t want to be converting to a string inside LabView and back to a timestamp inside the IOC. We don’t even have a routine which can do that inside EPICS, although Linux does (strptime()).

 

2. The TIME field is an epicsTimeStamp which is made from 2 unsigned 32-bit integers holding nanoseconds and seconds since Jan 1st 1990 00:00:00 UTC. The Posix epoch is 1970/1/1 00:00:00 UTC so there’s a constant offset (POSIX_TIME_AT_EPICS_EPOCH in epicsTime.h) which you’d need to subtract from the seconds value if you’re working in Posix time_t values.

 

3. If you make the input field a 2-element ULONG array the CA protocol will tell your CA client that it actually holds an array of 2 double values though (CA doesn’t support unsigned integer types and at the time there was no larger signed integer type, so the IOC’s workaround is to tell the world outside that any ULONG fields are really DOUBLEs, since a double can hold all the values that a uint32_t can hold without any loss). You can still have your client write a DBF_LONG array though, as long as it doesn’t try to use the data type the IOC reports for the channel.

 

There are probably things I’ve forgotten, come back to tech-talk if you get stuck.

 

- Andrew

 

 

From: Johnson, Andrew N. <anj at anl.gov> 
Sent: Monday, December 14, 2020 2:53 PM
To: Manoussakis, Adamandios <manoussakis1 at llnl.gov>
Cc: EPICS tech-talk <tech-talk at aps.anl.gov>
Subject: Re: Timestamping Confusion

 

Hi, 

 

On Dec 14, 2020, at 4:43 PM, Manoussakis, Adamandios via Tech-talk <tech-talk at aps.anl.gov> wrote:

 

Partial success so far, I was able to get the TSEL to grab the timestamp from another record that was set by TSE default 0 (sys clock I think this is?).  When I set TSE to -2 can you not write to the TIME field of a record like this

 

Caput mydevice:abc.TIME 2020-12-14 14:38:49.021827

 

I was hoping to simulate my digitizer setting the timestamp in my waveform record TIME field.

 

Sorry, the TIME field is not directly accessible through Channel Access at all, other than being readable as metadata (i.e. part of a DBR_TIME_xxx or similar data type). You can’t read or write a .TIME field directly, generally only a device support or a link type can set the TIME field of a record. The point of setting TSE to -2 is to tell the record that the device support has already set the TIME field and the record should not overwrite it with the current wall-clock time.

 

- Andrew

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Manoussakis, Adamandios via Tech-talk
Sent: Monday, December 14, 2020 1:32 PM
To: EPICS tech-talk <tech-talk at aps.anl.gov>
Subject: RE: Timestamping Confusion

 

Thank you both for the insight, it seems best for us to go a similar path of using TSEL to copy the timestamp from the digitizer to each of our waveform records and using TSE set to -2 to stop the IOC from overwriting the time field (please correct me if I am wrong on this). I think I just need to understand the best way to get the first timestamp and then use TSEL to pass it along to the other records.

 

Ralph when you stated to have the digitizer send the timestamp with the data, would I just have my digitizer set the TIME field in the waveform record then?

 

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Ralph Lange via Tech-talk
Sent: Saturday, December 12, 2020 5:25 AM
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: Re: Timestamping Confusion

 

On Fri, 11 Dec 2020 at 22:33, Manoussakis, Adamandios via Tech-talk <tech-talk at aps.anl.gov> wrote:

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.

 

The EPICS Device Support needs to know the timestamp t0 (preferably sent with the data by the digitizer) and write it to each record's timestamp when it updates the record.

In that case, by configuring their TSE to -2, all waveform records can use the digitizer timestamp. That timestamp can even be forwarded (using TSEL) through post-processing chains, so that processed data may still use the timestamp that the digitizer sent with the raw data at the beginning of the chain.

 

Cheers,
~Ralph

 

-- 

Complexity comes for free, simplicity you have to work for.

 

-- 

Complexity comes for free, simplicity you have to work for.