EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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  <20212022  2023  2024  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  <20212022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Altering timestamp of softIOC PV
From: "Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov>
To: "Reimer, Paul E." <reimer at anl.gov>
Cc: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Tue, 26 Jan 2021 03:02:27 +0000
On Jan 25, 2021, at 6:59 PM, Reimer, Paul E. <reimer at anl.gov> wrote:

I have several work a rounds.  Right now, we store a timestamp PV as the acquisition time and then the data in additional PVs.  The correct way is to have the DAQ system call the ca_put immediately (the data is coming in at a 5 Hz level). There are others which collaborators have suggested as well. It just seemed unnecessarily complicated and un-natural given that there exists a location in the record for the time already.


It is of course possible to write some C code for the IOC that will let you do that, but the fact that it isn’t easy is an indication to me that there may a better way to do what you’re looking for.
I think that this really answers my question--it is not a trivial task.  My hope was that I had missed something in the manual or mailing lists that would tell me how to do this; although, the more I think about possible implications of essentially "changing history" it is probably not a good idea to allow. 

Inside the IOC it is a trivial task since C code is not limited by the permissions that apply to the CA server. We provide mechanisms by which the device support for a record can set its timestamp along with the value, or a record can read its timestamp through the TSEL link pointing to the .TIME field of some other record.

Thus the simplest way to do what you want is probably to add an array subroutine (asub) record with a routine that copies the timestamp value (an array of 2 unsigned 32-bit integers holding nanoseconds and seconds since the EPICS epoch) from an input field into the asub record’s TIME field. The main complication is that you have to provide the compiled subroutine code to do that, but you could still use the softIoc binary and dlload that from a shared library if you don’t want to build it into your own IOC executable.

As you described above, your acquisition system would first write the timestamp to that asub, then write to the data PVs which would be configured with their TSEL links pointing to the asub.TIME field so they would automatically set their timestamps with the correct value when they processed the new data.

If you want to go this route make sure to check back with tech-talk first because there are a couple of other things to be aware of to get it working, but they don’t significantly affect the solution.

There are many other possible solutions as well, the lua record from synApps might be able to write to its TIME field, and there are python device support layers too so you might not have to write C code but you would have to add other modules instead.

HTH,

- Andrew


On 1/25/21 17:09, Johnson, Andrew N. wrote:
Hi Paul,

On Jan 25, 2021, at 4:41 PM, Reimer, Paul E. via Tech-talk <tech-talk at aps.anl.gov> wrote:

The "acquisition time" is a trigger generated elsewhere and served by equipment that, at this time, can't talk directly to EPICS.  The best solution is to have the acquisition system talk directly with EPICS--I argued for this--but that is not what I have. The data is essentially buffered (with and acquisition timestamp) and then handed off to a system that talks with EPICS.

Are there any other protocols or APIs that an IOC might be able to use to communicate with the system, and what kinds of data sizes and rates are involved in the data transfers?

EPICS systems don’t generally use Channel Access clients as agents for acquiring data, and as a result we don’t have an easy way to put an EPICS timestamp into a Channel Access PV. It is of course possible to write some C code for the IOC that will let you do that, but the fact that it isn’t easy is an indication to me that there may a better way to do what you’re looking for.

If you could describe the larger problem to the community (i.e. to this list) we might be able to recommend alternatives that could turn out to be faster and easier – no promises, but it’s worth a try. 

- Andrew


On 1/25/21 16:34, Arnold, Ned D. wrote:
> I would like the timestamp field for that PV to reflect the acquisition time rather 
than the time that the ca_put(DBR_LONG, stchid, &iParVal) routine is 
called. 

Is the "acquisition time" a user defined time, an event within the IOC, or an external trigger generated from somewhere else?  

  Ned


From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Reimer, Paul E. via Tech-talk<tech-talk at aps.anl.gov>
Sent: Monday, January 25, 2021 02:14 PM
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Altering timestamp of softIOC PV
 
Hello,

Is it possible to alter the timestamp field of a PV? Specifically, I 
have a situation in which data is recorded by a computer, but might not 
be put into EPICS immediately (few sec delay is possible). I would like 
the timestamp field for that PV to reflect the acquisition time rather 
than the time that the ca_put(DBR_LONG, stchid, &iParVal) routine is 
called.  I note that the time field is of type "NOACCESS" in the manual.

Thanks,

Paul

-- 
If you receive this e-mail after hours, during a weekend, or on a holiday,
please enjoy your time off and respond during your working hours.

Paul E Reimer               +1-630-252-4037 (Office)
Bldg 203, Physics Division  +1-630-252-3903 (fax)
Argonne National Laboratory +1-630-344-9207 (mobile)
9700 S Cass Ave             reimer at anl.gov
Lemont, IL  60439 USA.      he/his/him

-- 
If you receive this e-mail after hours, during a weekend, or on a holiday,
please enjoy your time off and respond during your working hours.

Paul E Reimer               +1-630-252-4037 (Office)
Bldg 203, Physics Division  +1-630-252-3903 (fax)
Argonne National Laboratory +1-630-344-9207 (mobile)
9700 S Cass Ave             reimer at anl.gov
Lemont, IL  60439 USA.      he/his/him

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

-- 
If you receive this e-mail after hours, during a weekend, or on a holiday,
please enjoy your time off and respond during your working hours.

Paul E Reimer               +1-630-252-4037 (Office)
Bldg 203, Physics Division  +1-630-252-3903 (fax)
Argonne National Laboratory +1-630-344-9207 (mobile)
9700 S Cass Ave             reimer at anl.gov
Lemont, IL  60439 USA.      he/his/him

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


References:
Altering timestamp of softIOC PV Reimer, Paul E. via Tech-talk
Re: Altering timestamp of softIOC PV Arnold, Ned D. via Tech-talk
Re: Altering timestamp of softIOC PV Reimer, Paul E. via Tech-talk
Re: Altering timestamp of softIOC PV Johnson, Andrew N. via Tech-talk
Re: Altering timestamp of softIOC PV Reimer, Paul E. via Tech-talk

Navigate by Date:
Prev: Re: Altering timestamp of softIOC PV Reimer, Paul E. via Tech-talk
Next: Python cothread errors Ha, Kiman 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  <20212022  2023  2024 
Navigate by Thread:
Prev: Re: Altering timestamp of softIOC PV Reimer, Paul E. via Tech-talk
Next: changing unit string to scale factor Randall Cayford 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  <20212022  2023  2024 
ANJ, 25 Jan 2021 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·