prjemian
commented
4 years ago Understandable that it is confusing for anyone. It's possible. Read...
There exists the possibility of configuring the AreaDetector's HDF5 layout file to write a PV onFileClose. (I believe the default is onFileOpen). See the example layout file: https://github.com/areaDetector/ADSimDetector/blob/master/iocs/simDetectorIOC/iocBoot/iocSimDetector/hdf5_layout_demo.xml#L20-L27
Direct access to a record's .TIME field is not possible from a client directly. This is most obvious from the EPICS Record Reference Manual, section on Fields Common to All Records: https://wiki-ext.aps.anl.gov/epics/index.php/RRM_3-14_dbCommon#Miscellaneous_Fields
Now comes the tricky business. And this took a bit more research for sure. You must get this information to areadetector before it closes the data file. If you put start time, collect WAXS AD, put stop time, you have missed that opportunity.
You need this PV: WAXS:cam1.Acquire.TIME
The .TIME field is accessible within the IOC database, just not by Channel Access clients. Clients usually can access that information as metadata but the HDF File Writer in AD cannot use that method since it is configured by PVs. Here's the gold nugget: https://epics.anl.gov/tech-talk/2006/msg00017.php
We create a stringin (not stringout) record that will contain the formatted time of the WAXS:cam1:Acquire PV. Whenever that PV updates, the time will be posted to our new stringin record in the format we specify.
record(stringin, "$(P)$(R)Acquire_TimeStamp") {
field(DESC, "Acquire timestamp, ISO8601")
field(DTYP, "Soft Timestamp")
field(INP, "@%Y-%m-%dT%H:%M:%S.%09f")
# TODO: connect with "$(P)$(R)Acquire.TIME"
}but this only updates when the record is processed. We need to make it process (set its .PROC field to 1) when "$(P)$(R)Acquire" is processed. Here's a PV that will do that work:
record(calcout, "$(P)$(R)Acquire_TimeStampTrigger") {
field(DESC, "when AD camera Acquire processes")
field(CALC, "1")
field(SCAN, ".1 Second")
field(INPA, "$(P)$(R)Acquire")
field(OOPT, "On Change")
field(OUT, "$(P)$(R)Acquire_TimeStamp.PROC")
}We could create more infrastructure to make separate PVs for AcquireStartTime and AcquireStopTime. This is just one way to do this.
These two records can be run in (EPICS base) softIoc. But the Trigger record will only capture transitions SLOWER than its .SCAN rate. If we set .SCAN to "I/O Intr" so it only processes when Acquire processes, the IOC will reset that to Passive on startup if it is not in the same IOC with the area detector (and it fails to connect with the INPA). An alternative is to use a record that supports re-targetable connections, such as the swait record.
jilavsky
MarkRivers
by email, @jilavsky writes:
... trying to verify some data collection - basically, user argues ... that somehow we measured the same sample twice under different names. Now, I can more or less conclusively prove, that it is not true - NeXus files with all the metadata are simply amazing. Spec file is useful also.
Now, as I am working on this, I extract times when data were collected. That reminded me of problem here, which I have been ignoring for long time.
We have two PVs for waxs:
9idcLAX:WAXS:StartExposureTimeandEndExposureTime.These are set in spec (and I assume Bluesky also) :
These PVs are in the NeXus attributes Template and included in the Nexus file through layout.xml file.
Logically, before spec puts in the PV end time, AD has already updated its value and uses therefore only the stale value, end time of prior image. End time is BEFORE the start time… Ouch. Basically, only the Start time has any meaning here.
How do we get the correct end time in the metadata? It is confusing the hell out of me to remember this and if user sees this, they will be wild.
Alternatively, I can remove the end time if there is no simple way of getting that. It should be startTime+exposure time anyway…
Any suggestion which will not require major revision of AD and our templates? Is there default internal AD metadata which one can use for this? Seems obvious timestamp…