Experimental Physics and
Industrial Control System

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