Reading Eiger images in databroker

[gfabbris]

I think I understand the at least part of the problem:

It looks like databroker looked for "t.h5" image in our last test, which is the pre-staging name of the image. I'm a little surprised by this, because I expected that the images name were read after the scan started, but looking into the staging process, it ultimately calls FileStoreBase._generate_resource that adds the "resource_path" into the database.

It turns out that we are adding the pre-staged name into the "resource_path" in our hdf1.stage(). filename is generated in line 110 before we apply the stage signals in line 127. Then this wrong filename is used in line 133. I think we can re-write the staging to be:

def stage(self):

    # Ensure we do not have an old file open.
    set_and_wait(self.capture, 0)

    # Stage signals, which include file name and path,
    # see staging_setup_DM below.
    FileStoreBase.stage(self)

    # Setup the staged file name and path in the database
    filename, read_path, _ = self.make_filename()
    self._fn = template % (read_path, filename)
    self._fp = read_path
    if not self.file_path_exists.get():
        raise IOError(f"Path {self.file_path.get()} does not exist on IOC.")

    self._point_counter = itertools.count()

    # from FileStoreHDF5.stage()
    res_kwargs = {"frame_per_point": self.get_frames_per_point()}
    self._generate_resource(res_kwargs)   

[prjemian]

Can we try this out? Over the weekend?

[gfabbris]

Just added this change to the 290-read_eiger_images branch.

[qzhang234]

@gfabbris Thanks for creating the branch! I checked out your branch (see the terminal output attached) and ran Eiger with AD_Acquire. The acquisition finished just fine, however the image load from databroker shows the same error. Did I miss any steps?

Any suggestions @prjemian ?

Terminal_Output.txt

[gfabbris]

As Pete mentioned in https://github.com/BCDA-APS/apstools/issues/651#issue-1251742146 the latest error message should be fixed by removing the "filename" datum_kwarg (line 138). I did that in the last commit, so should be ready to try it again.

[qzhang234]

@gfabbris That sounds great! Should I pull the branch #290 and try again?

Also out of curiosity, how did you modify code in apstools?

[gfabbris]

@qzhang234: yeah, you can just get the branch to the beamline and try it. Just remember to push any changes that you might have at the beamline to GitHub before changing branches.

[qzhang234]

@gfabbris Good point. I pulled your branch and tested it on 8-ID-I. It now returns a different error:

Terminal_Output.txt

[gfabbris]

I think this is an issue with the EigerHandler, just pushed a change to it (2f2c81d2be00ab111897a8b6c2673514d3862dcb), could you try again?

[qzhang234]

@gfabbris I think this worked! Please refer to the terminal output attached.

@prjemian Are there any more tests we need to do regarding this? Also how do we merge this into 150-Lambda2M and maybe then into master? A pull request?

Thanks,

Output_Terminal.txt

[gfabbris]

We should be able to avoid using a custom handler. I will try to change that tomorrow.

[gfabbris]

Just modified the branch to remove the custom eiger handler since I think it's not needed, and it'd be more convenient to use a standard handler. @qzhang234: could you test it?

[qzhang234]

@gfabbris I tested your new code and it worked! I have attached the terminal output.

Please let me know if there's any further diagnosis you would like me to run

Output_Terminal.txt

[gfabbris]

Great!

I cleaned up the code in the ad_eiger and load_eiger, and completely removed our custom image handler. But before I start a pull request, @qzhang234: could you go through the # TODO: that I added in ad_eiger and load_eiger? There are a few things we need to look into to finish the setup, and we may not even need to use the load_eiger function.