Closed qzhang234 closed 3 years ago
QMAP is defined in dm_pars.qmap_file
ophyd object
A check for correct value of dm_pars.qmap_file
might go best between lines 117 & 118: https://github.com/aps-8id-dys/ipython-8idiuser/blob/6441425b2fda10b4357ec7ddb58d32eca6c1bc43/profile_bluesky/startup/instrument/devices/data_management.py#L117-L122
You need to wait_for_connection()
immediately after defining dm_pars
to make sure that the entire device is connected with EPICS:
dm_pars.wait_for_connection()
No, that's not the right place. You want the check for QMAP value to be part of AD_Acquire()
. Is the QMAP an argument to AD_Acquire()
now? See: https://github.com/aps-8id-dys/ipython-8idiuser/blob/6441425b2fda10b4357ec7ddb58d32eca6c1bc43/profile_bluesky/startup/instrument/plans/xpcs_acquire.py#L25-L33
This is related to #218. As clearly stated in https://github.com/aps-8id-dys/ipython-8idiuser/issues/218#issuecomment-696848852, bluesky write the QMAP specification to EPICS.
I see. However back when we were still using LabView, we had an object defined for Rigaku as rigaku
that has attributes rigaku.qma_file
. Then we could change the q map in a BP simply by rigaku.qmap_file = qzhang234_some_map.hdf
.
However, we have switched from rigaku
to adrigaku
after the implementation of the Linux server. The new adrigaku
does not seem to have a qmap_file
attribute and now come to think about it, we never tested to see if changing qmap_file
will lead to a change of the PV in StrReg13. Maybe it's worth checking before closing the issue?
@prjemian Which qmap file name is used for analysis, adrigaku.qmap_file
(String) or dm_pars.qmap_file
(EpicsSignal, 8idi:StrReg13)?
The full path of qmap should be specified in
AD_Acquire
, and Bluesky should be able to change 8idi:StrReg13.AD_Acquire
should not assume any default q map and should return an error when no q map is specified.