Open prjemian opened 2 years ago
@qzhang234 which branch should I use?
@prjemian I just pushed today's change to 150-Lambda2M
Also I'm very confused about det.hdf1.read_path_template
, det.hdf1.write_path_template
, LAMBDA2M_FILES_ROOT
and BLUESKY_FILES_ROOT
. What are these for and why do we need all four of them?
Currently LAMBDA2M_FILES_ROOT
and BLUESKY_FILES_ROOT
are hard-coded, which is fine for testing but will for sure cause problems if we start to operate like this
The read_path_template
and write_path_template
are from ophyd's area detector support and describe configurations for databroker and the area detector IOC, respectively, to coordinate the directory containing image files. Particularly:
``write_path_template`` must always be provided, only provide
``read_path_template`` if the writer and reader will not have the
same mount point.
We satisfy this requirement: https://github.com/aps-8id-dys/ipython-8idiuser/blob/62b18cebf8a27efe25934bd65493c0ca9b4c2612/profile_bluesky/startup/instrument/devices/ad_lambda2M.py#L239-L240
Since that use is located in the middle of the very long python file, and that use is very important to the instrument team to understand, these definitions are made near the top of the file: https://github.com/aps-8id-dys/ipython-8idiuser/blob/62b18cebf8a27efe25934bd65493c0ca9b4c2612/profile_bluesky/startup/instrument/devices/ad_lambda2M.py#L27-L30
In https://github.com/aps-8id-dys/ipython-8idiuser/issues/292#issuecomment-1164978334,
I think we want
path
inAD_Acquire
to be consistent with Bluesky sense (/home/8ididata/2022-2/****
)
This use: https://github.com/aps-8id-dys/ipython-8idiuser/blob/62b18cebf8a27efe25934bd65493c0ca9b4c2612/profile_bluesky/startup/instrument/devices/ad_lambda2M.py#L239-L240 is an initial configuration of the detector.
Later (in the AD_Acquire
plan) https://github.com/aps-8id-dys/ipython-8idiuser/blob/73d28f5ae6dcf3066e8d9bc79ea7d5ac91b7c041/profile_bluesky/startup/instrument/plans/xpcs_acquire.py#L26
we use the same file_path
term (derived from the path
kwarg) to define the detector's write path
https://github.com/aps-8id-dys/ipython-8idiuser/blob/73d28f5ae6dcf3066e8d9bc79ea7d5ac91b7c041/profile_bluesky/startup/instrument/plans/xpcs_acquire.py#L90-L91
and the DM workflow path: https://github.com/aps-8id-dys/ipython-8idiuser/blob/73d28f5ae6dcf3066e8d9bc79ea7d5ac91b7c041/profile_bluesky/startup/instrument/plans/xpcs_acquire.py#L123-L130
Note the code that adjusts the path for the DM workflow: https://github.com/aps-8id-dys/ipython-8idiuser/blob/73d28f5ae6dcf3066e8d9bc79ea7d5ac91b7c041/profile_bluesky/startup/instrument/plans/xpcs_acquire.py#L125-L126
But we have not anticipated the area detector write path would begin with /extdisk/
. That's the root cause of the problem we saw yesterday.
My analysis: this code could will be easier to manage if the file paths were made more obvious to their functions.
In
AD_Acquire
there is apath
kwarg that is used to set the path the detector uses to write image files and also the path that bluesky will write the DM workflow file. Can't do that since the Lambda2M does not have the same filesystems as the bluesky workstation. Execution fails here: https://github.com/aps-8id-dys/ipython-8idiuser/blob/73d28f5ae6dcf3066e8d9bc79ea7d5ac91b7c041/profile_bluesky/startup/instrument/plans/xpcs_acquire.py#L295-L297 with a permissions error. Suggest refactoring with pathlib and considerdet.hdf1.read_path_template
anddet.hdf1.write_path_template
. Also, clarify the meaning of thepath
kwarg (IOC or Bluesky sense).Originally posted by @prjemian in https://github.com/aps-8id-dys/ipython-8idiuser/issues/292#issuecomment-1164977581