search

aps-8id-dys / ipython-8idiuser

8-ID-I ipython configuration for bluesky (and other)
1 stars 1 forks source link

Detector/DM_Workflow attributes overlapping with dm_pars definition #263

Closed qzhang234 closed 2 years ago

qzhang234 commented 3 years ago

@prjemian I noticed that certain variables are defined in two places, such as dm_pars.qmap_file (EpicsSignal, 8idi:StrReg13) vs. adrigaku.qmap_file (String) for q map file, and dm_pars.transfer (EpicsSignal, 8idi:StrReg15) vs. dm_workflow.transfer for DM transfer workflow.

My guess is, the values in StrReg is used for DM workflow and the analysis, and the other one is just dangling. This seems more likely since dm_workflow is defined in spec_support.

Should we consolidate the variable space and keep only the StrReg variables, like what we do in Spec (e.g. removing the attribute qmap_file in adrigaku since it's not used for analysis anyway)?

prjemian commented 3 years ago

The attributes in dm_pars provide the EPICS interface, connecting with the PVs. The attributes in adrigaku exist to satisfy the AD_Acquire interface. Two very different purposes.

Obviously, this is very confusing. Please propose a complete solution.

qzhang234 commented 3 years ago

@prjemian I see. but do we know which one is actually used for the analysis in DM? It can't be both, right?

qzhang234 commented 3 years ago

I just noticed that the qmap used for DM workflow is the one defined in adrigaku.qmap and not the one in StrReg. This could potentially be confusing so I'm proposing that we use the one in StrReg and remove the qmap attribute from adrigaku altogether, for consistencies with other detectors.

Please let me know @prjemian if you agree. Thanks!

qzhang234 commented 2 years ago

This issue will be fixed with #282