long exposures from Dexela area detector

[prjemian]

Related to #471, @jilavsky emails @kmpeters & @prjemian :

My reading of Dexela manual is, that it has single exposure if 37.5 ms long (if I recall correctly reading the manual). I have verified by testing, that changing exposure time on AD main screen has no effect and saved files (for now tiffs on the usaxspc8 computer) have approximately same average counts at any exposure time.

Manual also mentions long exposures, but I am not sure if AD supports that and since Dexela output is 14 bits and we want more bits, it would be counterproductive to use longer frame time, we need to sum more frames together...

I think we talked about this, that what I need to do is enable plugin which will sum the necessary number of images to give me wanted exposure time and then write this one in file.

I am unable to figure out which plugin will let me sum number of images.

Can you describe how to do this, please?

My expectation is that I will calculate number of images (each with 37.5 ms exposure) and write in …:cam1:NumImages and also tell the plugin which will accumulate values for me same number. Then after this number of images is collected, I will write it out to file. This looks like pretty complex set of commands to write in AD PVs - I have to enable right set of plugins, tell probably number of PVs what I want to do, make sure summing plugin is emptied before start etc.

[prjemian]

Here is a setup using the ADSimDetector and the PROC1 processing plugin, set to sum 200 frames, then reset and sum another 200. With the sim detector generating 100 fr/s, this is a 2 s accumulation as shown in the image. The flow is:

cam1/SIM1 --> PROC1 --> Image1

[prjemian]

You asked for file writer in the plugin chain. Replace the Image1 plugin with the HDF1 plugin (for example) and set the acquire period to match the Dexela (37.5 ms):

cam plugin

PROC plugin

HDFplugin

HDF file structure (up to the image data)

/tmp/docker_ioc/iocadsky/tmp/simdet/%Y/%m/%d/sample_000.h5 : NeXus data file
  entry:NXentry
    @NX_class = NXentry
    data:NXdata
      @NX_class = NXdata
      data:NX_UINT8[1,1024,1024] = __array
        __array = [
            [
                [135, 133, 132, '...', 136]
                [133, 132, 130, '...', 135]
                [132, 130, 129, '...', 133]
                ...
                [136, 135, 133, '...', 138]
              ]
          ]
        @NDArrayDimBinning = 1
        @NDArrayDimOffset = 0
        @NDArrayDimReverse = 0
        @NDArrayNumDims = 2
        @signal = 1

image (as viewed in NeXPy)

[prjemian]

With a bit more fiddling, could probably change the bit depth and data type. Good enough for the demo. Agree?

[jilavsky]

Agree... This helps. I was working on my own (this goes to e-mail I check less often) and averaging seems to work now. There are few things I can improve based on here. As indicated via e-mail, when I try to correct for background, I get unreasnable count/pixel. Background correction is critical for Dexela detectors.

[prjemian]

you using it now? I am, too.

On 1/19/2021 9:21 PM, Jan Ilavsky wrote:

Agree... This helps. I was working on my own (this goes to e-mail I check less often) and averaging seems to work now. There are few things I can improve based on here. As indicated via e-mail, when I try to correct for background, I get unreasnable count/pixel. Background correction is critical for Dexela detectors.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/APS-USAXS/ipython-usaxs/issues/473#issuecomment-763302213, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARMUMBPSL54ZT5HXGLLUV3S2ZD4HANCNFSM4WIGJIUQ.

[jilavsky]

I was but realized, that you are using it, so I left. It is yours.

[prjemian]

Good. Been fussing over this situation.

[prjemian]

This is an equivalent ophyd function to acquire for approximately t seconds:

def acquire_Dexela_N(target_acquire_time_s):
    """
    Acquire for ~t seconds : accumulate N frames from the Dexela as one image in an HDF file.

    ophyd code: NOT a bluesky plan
    """
    det = dexela_det
    fixed_acq_time = det.cam.acquire_time.get()
    num_frames = round(target_acquire_time_s / fixed_acq_time)

    # remember the original staging
    original_sigs = dict(
        cam=dict(**det.cam.stage_sigs),
        hdf1=dict(**det.hdf1.stage_sigs),
        proc1=dict(**det.proc1.stage_sigs),
    )

    # configure for acquisition
    det.proc1.stage_sigs["enable"] = 1  # Enable
    det.proc1.stage_sigs["enable_filter"] = 1  # Enable
    det.proc1.stage_sigs["num_filter"] = num_frames
    det.proc1.stage_sigs["filter_type"] = "Average"
    det.proc1.stage_sigs["reset_filter"] = 1
    det.proc1.stage_sigs["auto_reset_filter"] = 1
    det.proc1.stage_sigs["filter_callbacks"] = "Array N only"

    # HDF plugin should get processed image
    det.hdf1.nd_array_port.put(det.proc1.port_name.get())
    # other staging on HDF plugin is OK

    # COUNT
    det.stage()
    det.unstage()

    # restore the staging back to original
    for k, v in original_sigs.items():
        getattr(det, k).stage_sigs = dict(**v)

[prjemian]

You can see the function is not complete. Between the stage() and unstage() should be a trigger() and read(). Waiting on stage() to be successful.

[jilavsky]

Yes, I see... Note, that we also need (important) similar function to acquire new background image. This is so poor camera, that more or less you have to acquire new background before each real exposure. I assume code will be similar, but we will be triggering different PV and we need to disable plugins. In some way I wonder, if it would be better to put this as integral part of each data collection. Before any data are acquired, collect new background. Adds time, but this camera drift is notorious.

[prjemian]

This will be used as an alternative to the WAXS detector but need its own plan since other actions might be involved. Start with the WAXS plan as a template but a separate plan, allow for later customizations.

Wants this in the next couple days.

[prjemian]

Write a plan that uses this detector for collection. Success of that plan will close this issue.

[jilavsky]

OK, we ended up not using this during our available test times, other stuff was not ready. But collected enough experience with detector to be able to sketch up plan. It is close to WAXS with Pilatus, but with minor changes.

Take WAXS plan and modify per these comments:

During moving to WAXS positions collect new dark field. --- while moving to WAXS position - no need to waste time separately. To do so:

1. Switch off callbacks to prevent saving of multiple dark field files. Did do so for unknown reason.
2. Collect number of images, 10-20 is fine.
3. Switch on callbacks This should take may be 2-4 seconds, so it should be done before move is done, btu may be we should check if it is done before continuing?

Collecting data :

1. Calculate number of images needed to get the exposure time user wants. Use 200ms exposures (seem to work well in testing with strong scatterer), which is 160ms exposure and 40ms readout. We need to have variable which will allow us to set and change the frame exposure time, since we could run out of counters if signal too strong. Therefore, for 1 seconds we need to have 1/0.160 ~ 6 exposures.
2. Set frame exposure time to 0.2 sec and set number of images to collect
3. Set same number of images in the PROC panel for summing, so we get the sum over all images we collect
4. Set hdf5 path and file name
5. Arm counters as usually - this is part regular WAXS plan item - just check that we have included the gated one, it is important here!
6. Open shutter as usually, start exposure

End of collection - nothing special.