Rigaku: AD_Acquire can't start DM analysis

[qzhang234]

@prjemian I wrote a simple Bluesky plan to test the long-term stability. One main difference is that I'm setting the StrReg that controls the q map and the workflow names from Bluesky, as suggested by @prjemian from #218 and #258:

Bluesky Plan

``` from instrument.framework import bec, RE from instrument.devices import lakeshore, flyscan, adrigaku from instrument.plans import AD_Acquire, movesample, select_RIGAKU from bluesky import plans as bp from bluesky import plan_stubs as bps from instrument.collection import * from instrument.devices import aps import numpy as np dm_pars.transfer.put('xpcs8-01-stage') dm_pars.analysis.put('xpcs8-02-Rigaku-bin-DirGrouped') dm_pars.qmap_file.put('babnigg202107_2_qmap_Rq0_S180_D18_Linear.h5') def repeat_rigaku_acq(file_header='F', acq_rep=3, sample_name='Test', Temp_list=[25], att_value=0, samx_cen = 0, samz_cen = 0): bec.disable_plots() bec.disable_table() logger.setLevel(logging.INFO) yield from bps.mvr(dm_pars.ARun_number, 1) yield from bps.mv(att,att_value) acq_header = f'{file_header}{int(dm_pars.ARun_number.get()):03d}' samx_num = 20 samz_num = 40 samx_list = np.linspace(samx_cen-0.0, samx_cen+0.0, num=samx_num) samz_list = np.linspace(samz_cen-0.0, samz_cen+0.0, num=samz_num) for ii in range(acq_rep): pos_index = np.mod(ii,samx_num*samz_num) # yield from bps.mv( # samplestage.x, samx_list[np.mod(pos_index,samx_num)], # samplestage.z, samz_list[int(np.floor(pos_index/samx_num))] # ) acq_name = f'{acq_header}_{ii+1:05}_att{att_value:02}_{sample_name}' logger.info(acq_name) print(acq_name) yield from AD_Acquire( adrigaku, file_name=acq_name, acquire_time=20.00e-6, acquire_period=20.00e-6, num_images=100000, path='/home/8ididata/2021-2/rigaku202107/', submit_xpcs_job=True, atten=att_value, md={}) bec.enable_plots() bec.enable_table() ```

When I ran the plan, I can see Bluesky triggering Rigaku from the caqtdm screen and files saved on /home/8ididata/rigaku202107, however the DM analysis is stuck at Stage 3 meaning the files were never transferred (see screenshot attached).

I also noticed that during the operation, the file path and file name on the Rigaku caqtdm never updated. I did a quick search and it seems like although the file path and file name PVs ( 8idRigaku:cam1:FilePath and 8idRigaku:cam1:FileName) are defined in Bluesky (adrigaku.cam.file_path and adrigaku.cam.file_name), the values did not change during the acquisition, which could be problematic. The same problem occurred when I was running AD_Acquire by itself. Wonder that could be the problem?

Any suggestions would be very helpful.

[qzhang234]

@sureshnaps The files did not show up on /net/wolf/ (see screenshot attached). Wonder if this is a DM workflow problem from our end? By the way I set the StrReg to use the Rigaku workflow with sub directories.

[qzhang234]

Pete showed me how to us camonitor -S $PV_names during the Bluesky office hour on 08/04, and it was found that the PVs did change properly; the reason they change back is because of the staging/unstaging behavior of AD_Acquire which was part of the design feature.

Now we are facing the problem that the .bin and .hdf files are not transferred to /net/wolf. Also I'm using the workflow that uses sub directories (see image attached), which does not seem like it is working.

@sureshnaps This is now looking like a DM problem than Bluesky problem. Any pointers?

[qzhang234]

@prjemian The problem was traced to an HPC storage problem and was fixed by Roger. After that AD_Acquire worked for Rigaku. Closing the issue now.