Add support DM DAQ

[prjemian]

The APS Data Management has DAQ process that watch a file directory (and its subdirectories) for new files or modifications to existing ones. A DAQ will copy such changes from the watched directory to a destination directory. In addition to watching, a DAQ can launch a DM workflow.

Add support for DM's DAQs.

[prjemian]

Hannah Parraga suggests these steps:

1. check for existing daq
2. if daq, stop daq
3. start daq with workflow args from user
4. collect data
5. poll proc service until workflow has started for given file
6. poll proc service until workflow has finished
7. repeat from step 3 or continue steps 3-5 in parallel

[prjemian]

A DM DAQ should be configured for each data directory (which includes all of its subdirectories) that will store data files from the experiment. It may be necessary to create a new DAQ api object for each separate workstation+filesystem combination. For example, the HEDM group has a 4-panel detector called Hydra at station 1-ID-E. Each of the panels is a separate detector, each with its own workstation and filesystem. Four DAQs would be created, with an api object for each that includes the workstation and data directory.

Once the DAQ is created, must keep track of its id and api object. Thinking that a Python dict with detector name (str) as key and a new DaqManager class here to remember important information such as id, api, workstation, and dataDirectory. This is common setup for any use. Make a devices structure here.

[prjemian]

Code for today's demo created an api object with the details for the workstation on which bluesky runs. That info comes from the file that activates the dm conda environment.

[prjemian]

The library code in apstools should not know about any local instrument iconfig dictionary. It should have keyword arguments that default to the values supplied by the activation script (mentioned above).

[prjemian]

Need to learn how to get the api object needed for each of the Hydra's detector workstations. This was used for today's demo:

dm_source_environ()
api = DaqApiFactory.getExperimentDaqApi()

where dm_source_environ() sets the DM environment variables in this Python session.

[prjemian]

Q: How to get workstation into this request for an api object? DaqApiFactory.getExperimentDaqApi()

docs: https://git.aps.anl.gov/DM/dm-docs/-/wikis/DM/Beamline-Services/API-Reference/DAQ-Service

[prjemian]

Meanwhile, I'm asking the code for its docstrings. Starting from api? and working my way along. There's DM_DAQ_WEB_SERVICE_URL for example. Checking that its url parameter can be passed to DaqApiFactory.getExperimentDaqApi() somehow.

[prjemian]

One way is to bypass the classmethod and create it from a known URL, such as:

        from dm.daq_web_service.api.experimentDaqApi import ExperimentDaqApi
        # (username, password, url) = cls.getConfiguration()
        (username, password, url) = bluesky_gets_the_right_tuple_here()
        api = ExperimentDaqApi(username, password, url)
        return api

[prjemian]

Or

from dm.common.utility.configurationManager import ConfigurationManager
cm = ConfigurationManager.getInstance()
cm.getUser()
cm.getPassword()

[prjemian]

Comments starting from #912 (comment) represent an upgrade to the support demonstrated by the BDP demo this week. Hoist the support from the demo first, then upgrade in a new issue (for the next milestone).

[prjemian]

The content to be hoisted from the BDP demo this week is suitable as a usage example, for documentation.