Experimental Physics and
Industrial Control System

Zenon Szalata <[email protected]> · Fri, 6 Jun 2014 10:07:05 -0700

Hi Mark,

We are using the "Fixed Rate" and AcquirePeriod in many situations to

control the image frame rate. So, yes, we would like to retain this

feature.

Thanks,
Zen

On 06/06/14 08:34, Mark Rivers wrote:

The standard definition of the TriggerMode record is:

record(mbbo, "$(P)$(R)TriggerMode")
{
    field(PINI, "YES")
    field(DTYP, "asynInt32")
    field(OUT,  "@asyn($(PORT),$(ADDR),$(TIMEOUT))TRIGGER_MODE")
    field(ZRST, "Internal")
    field(ZRVL, "0")
    field(ONST, "External")
    field(ONVL, "1")
    field(VAL,  "0")
}

For the Prosilica cameras it changes the TriggerMode choices to:

record(mbbo, "$(P)$(R)TriggerMode")
{
    field(ZRST, "Free Run")
    field(ZRVL, "0")
    field(ONST, "Sync In 1")
    field(ONVL, "1")
    field(TWST, "Sync In 2")
    field(TWVL, "2")
    field(THST, "Sync In 3")
    field(THVL, "3")
    field(FRST, "Sync In 4")
    field(FRVL, "4")
    field(FVST, "Fixed Rate")
    field(FVVL, "5")
    field(SXST, "Software")
    field(SXVL, "6")
}

For these cameras AcquirePeriod is ignored if TriggerMode is "Free Run".  AcquirePeriod is only used when TriggerMode is "Fixed Rate".

We could generalize this and make the base class define 3 choices for TriggerMode:
Internal
External
Free Run

If it is Free Run then AcquirePeriod would be ignored.  Do we also want a "Fixed Rate" and AcquirePeriod is only used in that mode?

Mark

________________________________________
From: Pearson, Matthew R. [[email protected]]
Sent: Friday, June 06, 2014 8:55 AM
To: Emma Shepherd
Cc: Mark Rivers; [email protected]
Subject: Re: areaDetector acquirePeriod and acquireTime

Hi Emma,

How about having an additional frame rate parameter, or a maximum frame rate defined by a minimum acquire period? The Andor 3 drivers have a nice feature (provided by the manufacture API), which gives us the maximum frame rate when we change the image size and/or acquire times.

In most cases the scientists want to keep dead time to a minimum anyway, so having the option to fix acquire period to the minimum possible would be useful. I've only seen acquire period set higher than it needs to be when there's issue with detector saturation. There may be complications with image size. If you read out a reduced image size the readout time might change, depending on the detector. Some detectors might have other options that change the readout time (eg. ADC sampling frequency).

Cheers,
Matt

On Jun 6, 2014, at 1:58 AM, Emma Shepherd <[email protected]> wrote:

Hi Mark, all,

I've been thinking a bit about the relationship between the acquireTime and acquirePeriod parameters in areaDetector.

In some circumstances, scientists don't want any delay between frames, i.e. they want the acquirePeriod to be equal (or as close as possible) to the acquireTime.  They set this up for a given desired acquireTime, but are then sometimes caught out when they decrease the acquireTime but forget to decrease the acquirePeriod as well, so the overall frame rate is not what they expect.

I was wondering if people have a general way of dealing with this?  One possible solution would be to have an additional parameter to effectively disable the acquirePeriod, by forcing it to always be the minimum allowable value depending on the requirements of the particular detector and the current acquisition settings.  It would be nice to have a common solution across drivers/detectors if possible.

Cheers,
Emma

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System