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
>
>
>
- Replies:
- Re: areaDetector acquirePeriod and acquireTime Zenon Szalata
- RE: areaDetector acquirePeriod and acquireTime Emma Shepherd
- References:
- areaDetector acquirePeriod and acquireTime Emma Shepherd
- Re: areaDetector acquirePeriod and acquireTime Pearson, Matthew R.
- Navigate by Date:
- Prev:
EPICS database Feature request Emmanuel Mayssat
- Next:
Re: EPICS database Feature request Shen, Guobao
- 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
- Navigate by Thread:
- Prev:
Re: areaDetector acquirePeriod and acquireTime Pearson, Matthew R.
- Next:
Re: areaDetector acquirePeriod and acquireTime Zenon Szalata
- 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
|