Check code for after beam dump recovery

[jilavsky]

During beam dump data collection paused correctly, but after beam dump I do not believ eit was waiting for 100 seconds fro feedback to optimize the beam. It did not matter (SAXS is fine), but we need to review the code here. It actually stated "waiting for 0 seconds" so I think our code does not have our usual 100 seconds in there.

[jilavsky]

Reading through suspenders.py, it is using general bluesky.suspenders. Time is set to 100sec, but this suspender is set to watch APS current above 10mA threshold. It routinely takes APS multiple minutes before they open A shuters after they reach 100mA current (or above threshold current).
Delay is here to enable feedback to optimize beam in beamline... This cannot be done without A shutter enabled and opened... Delay needs to start after A shutter permit is enabled. One could argue that it should be after A shutter is opened, but that could get on staff nerves as annoying, so we can assume A permit enable is useful indicator. @prjemian, can you verify logic of bluesky.suspenders on this, please?

[prjemian]

Good catch! We should refactor this suspender to use a calculation PV that watches the current AND the shutter. Needs to also describe the hysteresis (off below 2, on above 10). Then, the suspender logic will be clear.

On Sun, Jun 6, 2021, 9:33 AM Jan Ilavsky @.***> wrote:

Reading through suspenders.py, it is using general bluesky.suspenders. Time is set to 100sec, but this suspender is set to watch APS current above 10mA threshold. It routinely takes APS multiple minutes before they open A shuters after they reach 100mA current (or above threshold current). Delay is here to enable feedback to optimize beam in beamline... This cannot be done without A shutter enabled and opened... Delay needs to start after A shutter permit is enabled. One could argue that it should be after A shutter is opened, but that could get on staff nerves as annoying, so we can assume A permit enable is useful indicator. @prjemian https://github.com/prjemian, can you verify logic of bluesky.suspenders on this, please?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/APS-USAXS/ipython-usaxs/issues/506#issuecomment-855409060, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARMUMHIJ6PZAO2D4UI6XO3TROBNHANCNFSM46FH3THQ .

[prjemian]

[prjemian]

@kmpeters : 9idcLAX is out of free userCalc PVs now and could use another back of 10 for general purpose use. Or, some the routine use calculations could move from userCalc to their own assignment, freeing up userCalcs for use by users. (I like this better but it means that client code in SPEC and Bluesky may need to be edited.)

Today, I started using 9idcLAX:userCalc9 (the last available userCalc in LAX) for another routine beam line use (the new white_beam_ready calculation). Bluesky will use this as a suspender for when to pause/resume operations after a beam dump (instead of just watching the APS storage ring current).

[prjemian]

Documentation

    Compute if white beam is expected to be ready.

    Based on an swait record (such as a userCalc).

    USAGE:

    - signal: ``white_beam_ready.available.get()``
    - property: ``white_beam_ready.is_available``

    If the swait record fields must be reset to default settings
    as used here, call:

        white_beam_ready.initialize_swait_record()

    Watches:

    - white beam shutter
    - APS storage ring current
    - undulator energy

    available = True when (
        shutter is open and
        both current and energy are in range
    )

    - energy must be below undulator_energy_threshold
    - current is too low when < current_off_threshold
    - current becomes OK when > current_on_threshold
    - Hysteresis in current signal is implemented.