-
Notifications
You must be signed in to change notification settings - Fork 77
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: Upstream helpful PV Positioners, add wait_for_value util #1046
Conversation
ophyd/pv_positioner.py
Outdated
if None not in (self._last_readback, self._last_setpoint): | ||
is_done = self.done_comparator(self._last_readback, | ||
self._last_setpoint) | ||
self.done.put(int(is_done), internal=True) |
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 it worth only updating if it has changed? I am 95% sure that the down-stream callbacks are going to fire on over put, I'm not sure ("not done yet", "not done yet", ... ) or ("done", "done", ...) is interesting to most things that would subscribe to the done status?
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.
Yes, it's worth modifying this so that it only updates when changed. It's easy to do, makes the situation more clear, and removes burden on downstream callbacks. I'll make this change.
The test failure is from the new tests, but looks like CI related timing issues.... |
I'll modify the test a bit to make it less susceptible to timing errors. I will claim that these tests passed locally every time. |
Would you mind rebasing this? |
befd6ee
to
9298ab9
Compare
Rebased on current master |
We're having a strange issue here where the 3.8 build is getting permanently stuck without any apparent text output. Yesterday this happened to a 3.9 build and I only noticed once the runtime had crept up to 2 hours with no activity. I'm not sure how to investigate this. |
I manually cancled it and we got
which suggests the problem is the next test. |
Which looking at a different run (and assuming they are deterministically orderded) gives us
and then a block of area detector tests...which suggests we need better timeouts on those? |
I think I agree, it must be area detector tests getting stalled out. I'm surprised that GH actions doesn't give us partial text output from these stages and requires a cancellation to see where we are stuck. I don't think this is related to this PR- I see the same thing in the log statements PR. |
This actually stalls even earlier in the logs PR:
|
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.
This LGTM overall 👍
ophyd/utils/epics_pvs.py
Outdated
wait_for_value(signal, val, poll_time=poll_time, timeout=timeout, rtol=rtol, atol=atol) | ||
|
||
|
||
def wait_for_value(signal, val, poll_time=0.01, timeout=10, rtol=None, |
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.
set_and_wait
is now internal API. Should this be the same?
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.
Need to think on this for a moment. Unlike set_and_wait
, wait_for_value
should always have the desired behavior in any context: "wait for the value of this signal to be this value", whereas for set_and_wait
it had weird interaction specifically with signal set
methods, particularly when we need to customize _set_and_wait
. I could see an argument for wait_for_value
being an overridable method on Signal
objects, I'm not sure I'm ready to commit to a change like that in this PR? If that's desirable in the future, it could be wise to preemptively internalize this.
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 don't have a feel for how these might be used, if I'm being honest. The only thing I could say is that it's easier to go from private->public than it is public->private in a library.
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.
In the interest of finishing this up for the codeathon, I'm going to make it private and someone else can choose to make it public later if needed.
Co-authored-by: Ken Lauer <klauer@users.noreply.github.com>
Part of the May 2022 EPICS codeathon effort
Relies on the
InternalSignal
from #1045, which would need to be merged firstPVPositionerIsClose
, a helpful PV positioner for when your IOC doesn't supply adone
signal.PVPositionerDone
, a dummy class for when the user wants their signal to "look like" a motor and cannot be dissuaded.ophyd.utils.epics_pvs._set_and_wait
into its own standalone utility,wait_for_value
because I needed it to write a reasonable test