Broken Scan Issues from Slack Chat

[ZLLentz]

Expected Behavior

• There should be a scan that accepts float as third arg for step size as well as int number of steps
• A daq.configure call that does not specify record should respects the GUI's setting
• daq.begin should not hang and then time out
• scan should connect to the scan variables when specified

Current Behavior

Slack messages from @silkenelson :

"""
I have managed to call: RE(scan([daq], x.test_motor, -5.9, -5.5, 0.1))

And it actually does something! My first attempt failed as I thought I could pass it a 0.1 and it would go "Oh, I'm supposed to use this number as a step size as it is a float" but it said "Oh, you want zero steps? I can do that" and did nothing. I remember that this was discussed.

Two things: daq.configure(120) will set record to False, even when I had set it to True in the GUI. In the old beamline python the default behavior was to do whatever the GUI had set. I don't know where this was set.

I can happily scan my test_motor when I do not record with the DAQ. So I set record to True my scan fails. I see the same failure (just with less error lines) when I use daq.begin(200) with having record set in the GUI.

In [10]: daq.begin(120)
---------------------------------------------------------------------------
TimeoutError                              Traceback (most recent call last)
<ipython-input-10-fa7d55843ad1> in <module>
----> 1 daq.begin(120)
/reg/g/pcds/pyps/conda/py36/envs/pcds-3.2.0/lib/python3.6/site-packages/pcdsdaq/daq.py in begin(self, events, duration, record, use_l3t, controls, wait, end_run)
    277             begin_status = self.kickoff(events=events, duration=duration,
    278                                         use_l3t=use_l3t, controls=controls)
--> 279             status_wait(begin_status, timeout=self._begin_timeout)
    280             # In some daq configurations the begin status returns very early,
    281             # so we allow the user to configure an emperically derived extra
/reg/g/pcds/pyps/conda/py36/envs/pcds-3.2.0/lib/python3.6/site-packages/ophyd/status.py in wait(status, timeout, poll_rate)
    598         elapsed = time.time() - t0
    599         raise TimeoutError('Operation failed to complete within {} seconds '
--> 600                            '(elapsed {:.2f} sec)'.format(timeout, elapsed))
TimeoutError: Operation failed to complete within 3 seconds (elapsed 3.01 sec)

Scan also does not connect to my scan variables, but that is a very different issue. It loads, but sets them to "disabled".
"""

Steps to Reproduce (for bugs)

I may need to run interactively with an open DAQ, since most of these involve interactions with record mode.

Context

Next run is soon and we want to scan in python 3

Your Environment

Probably xcs3 environment

[ZLLentz]

The daq.begin timeout happens for a combination of reasons:

1. We check the hutch name and get the run number using external scripts for logging purposes
2. These scripts are much slower than they used to be, at least from xcs-control
3. The timer for the begin timeout begins before calling these scripts.

The resolution will be to:

1. Cut down to the minimally needed checks
2. Consider these external script calls as having their own timeouts separate from the begin timeout, starting the begin timer right when we call pydaq.Control.begin. We still do want this timer so you don't sit there for a long time wondering why the scan won't start.

[silkenelson]

The record-related issues are solved now. The scan still takes steps. Not 100% decided about the nstep behavior to depend on the type of 'nsteps'

[klauer]

num accepting a non-integral floating point value is currently verified here in bluesky:
https://github.com/bluesky/bluesky/blob/a4a6f696ccd5fb7f48957a5b004aef2b8e6c71dc/bluesky/plans.py#L1060-L1063

This looks like (using your example):

In [1]: list(bluesky.plans.scan([daq], test_motor, 1, 2, 0.1))
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-15-37746bbb01f5> in <module>
----> 1 list(bluesky.plans.scan([daq], test_motor, 1, 2, 0.1))

~/Repos/bluesky/bluesky/plans.py in scan(detectors, num, per_step, md, *args)
   1059
   1060     if not (float(num).is_integer() and num > 0.0):
-> 1061         raise ValueError(f"The parameter `num` is expected to be a number of "
   1062                          f"steps (not step size!) It must therefore be a "
   1063                          f"whole number. The given value was {num}.")

ValueError: The parameter `num` is expected to be a number of steps (not step size!) It must therefore be a whole number. The given value was 0.1.

However, our latest env is on bluesky 1.6.1, which doesn't include this fix (released in v1.6.6). Despite the apparently minor/micro version bump of 0.0.5, there are apparently a lot of upstream changes, so we're probably holding back for good reasons.

[ZLLentz]

I've made an issue to update bluesky at next env release in pcdshub/pcds-envs#138