Experimental Physics and
Industrial Control System

Hi Tamas,

 

I have made some more changes.

 

-          I added asynInt64 support for the ao, ai, longin, and longout records in asyn.  This allows use of these records with asyn drivers that implement the asynInt64 interface, even if one is using an older version of EPICS base that does not support the int64in and int64out records.

-          I modified ADGenICam makeDb.py to accept a –devInt64 flag.  If this flag is set the resulting database uses int64in and int64out records.  This requires base 3.16.1 or higher, including 7.0.x.

-          If the –devInt64 is not present then the database uses ai and ao records.  This allows exact representation of integers up to 52 bits, which is much better than the 32 bits of the previous longin and longout records.

-          The master branch of ADGenICam, ADAravis, ADSpinnaker, and ADVimba now use this asynInt64 support for GenICam integer features.

 

It is referenced in this Github issue:

 

https://github.com/areaDetector/ADGenICam/issues/7

 

Mark

 

 

 

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

 

 

 

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-----
From: Tamas Kerenyi <[email protected]>
Sent: Friday, December 13, 2019 6:13 AM
To: Mark Rivers <[email protected]>
Cc: [email protected]
Subject: RE: ADSpinnaker timestamp

 

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]>

Cc: [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

Cc: [email protected]

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