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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: ADSpinnaker timestamp |
From: | Mark Rivers via Tech-talk <[email protected]> |
To: | 'Tamas Kerenyi' <[email protected]> |
Cc: | "'[email protected]'" <[email protected]> |
Date: | Mon, 16 Dec 2019 04:14:00 +0000 |
Hi Tamas, I changed makeDb.py on the int64 branch of ADGenICam so the GCFeatureTypeInteger records are now int64out and int64in rather than longout and longin.
I figured out the reason that the GC_ChunkTimestamp_RBV record was not updating was that the status polling was Passive. This is the screenshot now. Note that the ChunkTimestamp is now 15 digits long. Channel Access is converting the record from Int64 to Double, but it can still be exactly
represented with ns precision at this time. This is the output of camonitor on both the 13SP1:Stats1:TimeStamp_RBV and the 13SP1:cam1:GC_ChunkTimestamp_RBV records. Note that they are the same to the ns. corvette:ADGenICam/GenICamApp/Db>camonitor -f9 13SP1:Stats1:TimeStamp_RBV 13SP1:cam1:GC_ChunkTimestamp_RBV 13SP1:Stats1:TimeStamp_RBV 2019-12-15 21:57:35.670085 898408.639777728 13SP1:cam1:GC_ChunkTimestamp_RBV 2019-12-15 21:57:35.745156 898408639777728.000000000 13SP1:Stats1:TimeStamp_RBV 2019-12-15 21:57:35.769905 898408.739775280 13SP1:cam1:GC_ChunkTimestamp_RBV 2019-12-15 21:57:35.846300 898408739775280.000000000 13SP1:Stats1:TimeStamp_RBV 2019-12-15 21:57:35.869885 898408.839772760 13SP1:cam1:GC_ChunkTimestamp_RBV 2019-12-15 21:57:35.945934 898408839772760.000000000 13SP1:Stats1:TimeStamp_RBV 2019-12-15 21:57:35.969954 898408.939770320 13SP1:cam1:GC_ChunkTimestamp_RBV 2019-12-15 21:57:36.045683 898408939770320.000000000 13SP1:Stats1:TimeStamp_RBV 2019-12-15 21:57:36.069922 898409.039767712 13SP1:cam1:GC_ChunkTimestamp_RBV 2019-12-15 21:57:36.144324 898409039767712.000000000 Here is the pvmonitor output: corvette:ADGenICam/GenICamApp/Db>pvmonitor 13SP1:Stats1:TimeStamp_RBV 13SP1:cam1:GC_ChunkTimestamp_RBV 13SP1:Stats1:TimeStamp_RBV 2019-12-15 22:07:00.062 898973 13SP1:cam1:GC_ChunkTimestamp_RBV 2019-12-15 22:07:00.152 898973025622576 13SP1:Stats1:TimeStamp_RBV 2019-12-15 22:07:00.159 898973 13SP1:cam1:GC_ChunkTimestamp_RBV 2019-12-15 22:07:00.254 898973125620104 13SP1:Stats1:TimeStamp_RBV 2019-12-15 22:07:00.260 898973 13SP1:cam1:GC_ChunkTimestamp_RBV 2019-12-15 22:07:00.357 898973225617632 13SP1:Stats1:TimeStamp_RBV 2019-12-15 22:07:00.363 898973 13SP1:cam1:GC_ChunkTimestamp_RBV 2019-12-15 22:07:00.454 898973325615080 13SP1:Stats1:TimeStamp_RBV 2019-12-15 22:07:00.460 898973 I cannot figure out how to make 13SP1:Stats1:TimeStamp_RBV display with digits past the decimal point. The PREC field of the record is 9: corvette:ADGenICam/GenICamApp/Db>caget 13SP1:Stats1:TimeStamp_RBV.PREC 13SP1:Stats1:TimeStamp_RBV.PREC 9 But pvmonitor displays it as if PREC were 0, and there appears to be no equivalent of the –f flag I used on camonitor? Mark From: Mark Rivers Hi Tamas, I have made new "int64" branches of ADGenICam and ADSpinnaker. On these branches the GenICam integer feature type (GCFeatureTypeInteger) is changed from 32-bits to 64-bits, which is what is actually used in GenICam. This means that
internally those features are now 64-bits, and you should be able to save the ChunkTimestamp attribute to files (netCDF, TIFF, HDF5) as 64-bit integers. The EPICS database still uses longin and longout records for those records, so the records are still only 32 bits. However, makeDb.py can easily be changed to create int64in and int64out records for those attributes. That will require
using EPICS 3.16.1 or later, which includes any of the EPICS 7 base releases. I wanted to test the ChunkTimestamp feature on my BlackFlyS camera. However, it is not updating. How did you get that feature to update on your camera? This is the screenshot of the main ADSpinnaker screen and the features screen
that contains ChunkTimestamp on my system. Note that ChunkTimestamp_RBV is 0. Note that on my main ADSpinnaker screen I have set TimeStampMode=Camera. This means that the NDArray.timeStamp comes from the embedded camera information, and thus has the same ns precision as ChunkTimestamp. I can monitor that value
in any of the plugins. My camera is set to collect at about 50 Hz. The exact frame rate is corvette:ADGenICam/GenICamApp/src>caget -f9 13SP1:cam1:FrameRate_RBV 13SP1:cam1:FrameRate_RBV 50.013423603 The period is thus 0.01999463199995803 sec. This is what I get when I monitor the Stats1:TimeStamp_RBV PV: corvette:ADGenICam/GenICamApp/src>camonitor -f9 13SP1:Stats1:TimeStamp_RBV 13SP1:Stats1:TimeStamp_RBV 2019-12-15 17:25:14.414310 882067.481811312 13SP1:Stats1:TimeStamp_RBV 2019-12-15 17:25:14.434187 882067.501806048 13SP1:Stats1:TimeStamp_RBV 2019-12-15 17:25:14.454189 882067.521800800 13SP1:Stats1:TimeStamp_RBV 2019-12-15 17:25:14.474283 882067.541795424 13SP1:Stats1:TimeStamp_RBV 2019-12-15 17:25:14.494178 882067.561790248 Here is a calculation of the standard deviation of the time differences between these timestamp values. IDL> times = [882067.481811312D0, 882067.501806048D0, 882067.521800800D0, 882067.541795424D0, 882067.561790248D0] IDL> diffs = [times[1]-times[0], times[2]-times[1], times[3]-times[2], times[4]-times[3]] IDL> print, diffs 0.019994736 0.019994752 0.019994624 0.019994824 IDL> m = moment(diffs) IDL> print, m 0.019994734 6.8504174e-15 -0.26270241 -1.8675801 IDL> print, sqrt(m[1]) 8.2767248e-08 m[0] is the mean and sqrt(m[1]) is the standard deviation, which is 83 ns. When using the camera timestamp it is the time since the camera was last reset in ns units. TimeStamp_RBV is a double. It can exactly represent timestamps with ns precision for 52 days, so if your camera is reset at least once per
year the TimeStamp_RBV will be accurate to under 10 ns. This does not require using the new int64 bit support at all. Mark -----Original Message----- Hi Mark! Thank you for your emails! I'm using a BlackflyS BFS-PGE-50S5C camera. For now I used your second solution with the conversion of the timestamps and looks good. Tamas -----Original Message----- From: Mark Rivers <[email protected]>
Sent: Tuesday, December 10, 2019 11:10 PM To: Tamas Kerenyi <[email protected]> Subject: Re: ADSpinnaker timestamp Hi Tamas, These are the values of the ChunkTimeStamp you measured. They are coming every 2 seconds, plus or minus a few ms. labs-utg-test:cam1:GC_ChunkTimestamp_RBV 2019-12-10 16:01:34.642297 1557832136 labs-utg-test:cam1:GC_ChunkTimestamp_RBV 2019-12-10 16:01:36.640736 -737150176 labs-utg-test:cam1:GC_ChunkTimestamp_RBV 2019-12-10 16:01:38.641100 1262848184
labs-utg-test:cam1:GC_ChunkTimestamp_RBV 2019-12-10 16:01:40.643660 -1032134232 I just realized we can make sense of those as timestamps in ns, but we are missing the high-order bits which increment about every 4 seconds. Here I convert the 4 times above to unsigned 32-bit numbers. IDL> t1 = 1557832136 IDL> t2 = ulong(-737150176) IDL> t3 = 1262848184 IDL> t4 = ulong(-1032134232) IDL> print, t1, t2, t3, t4 1557832136 3557817120 1262848184 3262833064 Note that times 1 and 2 are separated by about 2000000000 counts, as are times 3 and 4. Clearly the 32-bit integer overflowed between times 2 and 3. So we add 2^32 to times 3 and 4 to compensate for this overflow and convert them to
64-bit integers. IDL> t3 = t3 + 2LL^32 IDL> t4 = t4 + 2LL^32 IDL> print, t1, t2, t3, t4 1557832136 3557817120 5557815480 7557800360 Now we look at the difference between the timestamps. IDL> print, t2-t1, t3-t2, t4-t3 1999984984 1999998360 1999984880 Note that they are all very close to 2000000000 = 2e9. Since your images were 2 seconds apart, this means these timestamps are indeed ns, and the jitter looks likes it is about 500 ns. Mark ________________________________ From: Mark Rivers Sent: Tuesday, December 10, 2019 1:30 PM To: Tamas Kerenyi Subject: Re: ADSpinnaker timestamp I think I understand why the ChunkTimestamp is jumping between positive and negative. GenICam integers are 64 bits. ADGenICam truncates them to 32 bits. EPICS base, asyn, and ADCore have all recently added support for 64 bit integers. I could thus change ADGenICam to use int64in and int64out records for GenICam integers. This would however require EPICS base 3.16.1 or later. Sent from my iPhone On Dec 10, 2019, at 10:32 AM, Mark Rivers <[email protected]<mailto:[email protected]>>
wrote: Hi Tamas, What camera are you using? In ADSpinnaker there is a PV to tell the driver to use the embedded time stamp from the camera for the timeStamp property of the NDArray. If you select this you may not need the ChunkTimestamp. The timeStamp is saved in the TIFF, HDF5, and netCDF file writing plugins. Mark Sent from my iPhone On Dec 10, 2019, at 8:28 AM, Tamas Kerenyi via Tech-talk <[email protected]<mailto:[email protected]>>
wrote: Hi! I'm using ADSpinnaker. How should I interpret the "ChunkTimestamp"? I'd like to know the timestamp of the pictures in nanoseconds. labs-utg-test:cam1:GC_ChunkTimestamp_RBV 2019-12-10 16:01:34.642297 1557832136 labs-utg-test:cam1:GC_ChunkTimestamp_RBV 2019-12-10 16:01:36.640736 -737150176 labs-utg-test:cam1:GC_ChunkTimestamp_RBV 2019-12-10 16:01:38.641100 1262848184
labs-utg-test:cam1:GC_ChunkTimestamp_RBV 2019-12-10 16:01:40.643660 -1032134232 Best Regards, Tamas Kerenyi ICS Division, HW and Integration Group |