Experimental Physics and
Industrial Control System

Emma Shepherd <[email protected]> · Tue, 10 Jun 2014 02:11:24 +0000

Hi Mark,

Thanks for that - I think generalizing the TriggerMode in the base class is a good idea.  I quite like Prosilica's concept of 'Fixed Rate' and having the AcquireTime only used in that mode - it makes it very clear what's going on.  It should also be applicable to almost all detectors since the delay time between frames can always be handled in the driver if the camera doesn't support it directly.

Cheers,
Emma

> -----Original Message-----
> From: Mark Rivers [mailto:[email protected]]
> Sent: Saturday, 7 June 2014 1:35 AM
> To: Pearson, Matthew R.; Emma Shepherd
> Cc: [email protected]
> Subject: RE: areaDetector acquirePeriod and acquireTime
> 
> 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