Getting Suspender messages eve when not running

[jilavsky]

Is this correct? BS is idle (Ivan is using spec) and during shut down day I am getting following messages:

In [98]: CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "s9-pilatus300k.xray.aps.anl.gov:5064"
    Source File: ../cac.cpp line 1236
    Current Time: Sun Dec 06 2020 21:02:19.218923290
..................................................................
Suspender SuspendFloor(EpicsSignalRO(read_pv='S:SRcurrentAI', name='aps_current', parent='aps', value=10.131815287091332, timestamp=1607367822.980586, auto_monitor=True, string=False), sleep=100, pre_plan=None, post_plan=None,tripped_message=) reports a return to nominal conditions. Will sleep for 100 seconds and then release suspension at 2020-12-07 13:05:22.
Suspender SuspendFloor(EpicsSignalRO(read_pv='S:SRcurrentAI', name='aps_current', parent='aps', value=10.034594919091331, timestamp=1607383377.980591, auto_monitor=True, string=False), sleep=100, pre_plan=None, post_plan=None,tripped_message=) reports a return to nominal conditions. Will sleep for 100 seconds and then release suspension at 2020-12-07 17:24:37.
Suspender SuspendFloor(EpicsSignalRO(read_pv='S:SRcurrentAI', name='aps_current', parent='aps', value=10.039415463091332, timestamp=1607387023.980594, auto_monitor=True, string=False), sleep=100, pre_plan=None, post_plan=None,tripped_message=) reports a return to nominal conditions. Will sleep for 100 seconds and then release suspension at 2020-12-07 18:25:23.
Suspender SuspendFloor(EpicsSignalRO(read_pv='S:SRcurrentAI', name='aps_current', parent='aps', value=10.070519395091333, timestamp=1607393736.980589, auto_monitor=True, string=False), sleep=100, pre_plan=None, post_plan=None,tripped_message=) reports a return to nominal conditions. Will sleep for 100 seconds and then release suspension at 2020-12-07 20:17:16.
Suspender SuspendFloor(EpicsSignalRO(read_pv='S:SRcurrentAI', name='aps_current', parent='aps', value=10.203707667091331, timestamp=1607403256.480623, auto_monitor=True, string=False), sleep=100, pre_plan=None, post_plan=None,tripped_message=) reports a return to nominal conditions. Will sleep for 100 seconds and then release suspension at 2020-12-07 22:55:56.
Suspender SuspendFloor(EpicsSignalRO(read_pv='S:SRcurrentAI', name='aps_current', parent='aps', value=10.061965487091333, timestamp=1607409612.480603, auto_monitor=True, string=False), sleep=100, pre_plan=None, post_plan=None,tripped_message=) reports a return to nominal conditions. Will sleep for 100 seconds and then release suspension at 2020-12-08 00:41:52.
Suspender SuspendFloor(EpicsSignalRO(read_pv='S:SRcurrentAI', name='aps_current', parent='aps', value=10.19591287109133, timestamp=1607414925.480602, auto_monitor=True, string=False), sleep=100, pre_plan=None, post_plan=None,tripped_message=) reports a return to nominal conditions. Will sleep for 100 seconds and then release suspension at 2020-12-08 02:10:25.
Suspender SuspendFloor(EpicsSignalRO(read_pv='S:SRcurrentAI', name='aps_current', parent='aps', value=10.132297931091331, timestamp=1607416459.980594, auto_monitor=True, string=False), sleep=100, pre_plan=None, post_plan=None,tripped_message=) reports a return to nominal conditions. Will sleep for 100 seconds and then release suspension at 2020-12-08 02:35:59.
Suspender SuspendFloor(EpicsSignalRO(read_pv='S:SRcurrentAI', name='aps_current', parent='aps', value=10.064735931091333, timestamp=1607432559.980594, auto_monitor=True, string=False), sleep=100, pre_plan=None, post_plan=None,tripped_message=) reports a return to nominal conditions. Will sleep for 100 seconds and then release suspension at 2020-12-08 07:04:19.
In [98]: 

I do not think this is major problem, but why is suspender reacting when instrument - and all users - have no permit? These current crosses are generated while APS is not in user mode. Do we need to include in suspender also more permits?

[prjemian]

This is planned behavior of the suspender each time the current drops below threshold for the suspender. Exit the Bluesky session to stop the chatter.

I'll look into a mechanism to make this more quiet (which involves adding more logic into the process).

[prjemian]

During the shutdown day yesterday, there was beam in the ring for testing purposes, even though the front-end shutters were closed. This suspender only looks at the storage ring current.

USAXS might switch to a suspender based on a computed ophyd.Signal that considers multiple terms:

• storage ring current
• instrument permitted to operate
• Bluesky in use (and not SPEC)

What else?

[jilavsky]

May be I do not understand fully what the suspender is. I can understand it suspends operations, but what is it suspending when BS is idle? I guess what I am saying is, that if this is background process which is running, it is probably fine, but it should not be annoying users when they are not trying to use BS. This will confuse users.

On the other hand, it needs to print message when it suspends real operations when user tries to collect data.

But yet again, what is it suspending? For example, even when current is below 5mA, I should be able to move between modes, I may want to change sample or do other instrument operations during beam dump to utilize the time. So suspender should suspend only operations when we try to use the X-rays, which would be counting on scalers or area detectors. Since all of our ADs are also counting scalers, suspending triggered by attempt to count scaler is all we need. Suspending more can get in users way of using the instrument...

And even then, it is only one of our three scalers which should trigger this, even though I think BS does not know about the other two.

Some of the logic used by spec and caQTDM is in our calculated beam in hutch calc record : 9idcLAX:blCalc:userCalc1 This one combines A and B shutter open + SR current, DCM and Undulator energy. This may be too aggressive and could prevent setup.