-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ENH: add a "busy" device #1028
base: master
Are you sure you want to change the base?
ENH: add a "busy" device #1028
Conversation
We had a request for a way to set a sleep in the RE that would give a progress bar. You can get an interuptable sleep via `bps.sleep`, but that provides no feedback. Rather than trying to invent another way to do progress bars, re-use the progress bar machinery for hardware motion.
Different than support for the EPICS busy record from synApps. https://github.com/BCDA-APS/apstools/blob/main/apstools/synApps/busy.py |
Correct, it was inspired by the busy record, but re-using the name is a probably a terrible idea. I think this is a very good idea and I can see it being used both as a way to provide a delay on its own and as a way to put a "time box" around some other activity (because it is a "settable" it can be set in parallel with either other sets or a trigger!). \ What should we call this instead?
|
The name is ok. Just leaving a trail to thee other one.
…On Tue, Feb 8, 2022, 10:14 PM Thomas A Caswell ***@***.***> wrote:
Correct, it was inspired *by* the busy record, but re-using the name is a
probably a terrible idea. I think this is a very good idea and I can see it
being used both as a way to provide a delay on its own and as a way to put
a "time box" around some other activity (because it is a "settable" it can
be set in parallel with either other sets or a trigger!). \
What should we call this instead?
- SleepWithProgressBar
- TimeMover
- TimeTraveler
- Delay
- SleepMachine
- ??
—
Reply to this email directly, view it on GitHub
<#1028 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AARMUMGQ5YITTYJLJBPAFTDU2HS3XANCNFSM5N4KQCXQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.Message ID:
***@***.***>
|
@tacaswell : The word |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea! Below are a few comments/suggestions to address what Bruce pointed to.
Total delay in seconds | ||
|
||
tick : float, default=0.1 | ||
Time between updating the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Incomplete description here
""" | ||
|
||
def set(self, delay): | ||
return BusyStatus(self, delay, tick=max(1, min(0.1, delay / 100))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this max(..., min(...))
condition even needed? With delay=100
, it'll pick the min=0.1, and the tick will be 1. With delay=0
, it'll pick min=0, but the tick will still be 1. Why not hard-code the tick=1
?
Did you have another corner case in mind?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I messed the logic up here. The goal was to never tick faster that 10hz (people can not see much faster and no need to stress the system) and never slower than 1hz (1s is about as long as I want to when I watch something to see if it is dead or not) and to get as close as possible to 100 updates as possible in between (because that felt like a "nice" number).
Co-authored-by: Maksim Rakitin <[email protected]>
I am not sure when I will have time to work on this again, I would be very 💯 👍🏻 if someone was motivated and wanted to take this PR over! |
We had a request for a way to set a sleep in the RE that would give a
progress bar.
You can get an interuptable sleep via
bps.sleep
, but that provides nofeedback. Rather than trying to invent another way to do progress bars, re-use
the progress bar machinery for hardware motion.
This still needs tests, but @bruceravel is using this at his beamline so I wanted to get a PR for ASAP.