Skip to content
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

Merged
merged 15 commits into from
May 13, 2022

Conversation

ZLLentz
Copy link
Member

@ZLLentz ZLLentz commented May 10, 2022

Part of the May 2022 EPICS codeathon effort
Relies on the InternalSignal from #1045, which would need to be merged first

  • Adds PVPositionerIsClose, a helpful PV positioner for when your IOC doesn't supply a done signal.
  • Adds PVPositionerDone, a dummy class for when the user wants their signal to "look like" a motor and cannot be dissuaded.
  • split out the "waiting" part of ophyd.utils.epics_pvs._set_and_wait into its own standalone utility, wait_for_value because I needed it to write a reasonable test

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)
Copy link
Contributor

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?

Copy link
Member Author

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.

@tacaswell
Copy link
Contributor

The test failure is from the new tests, but looks like CI related timing issues....

@ZLLentz
Copy link
Member Author

ZLLentz commented May 10, 2022

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.

@tacaswell
Copy link
Contributor

Would you mind rebasing this?

@ZLLentz
Copy link
Member Author

ZLLentz commented May 10, 2022

Rebased on current master

@ZLLentz
Copy link
Member Author

ZLLentz commented May 10, 2022

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.

@tacaswell
Copy link
Contributor

I manually cancled it and we got

coverage run --concurrency=thread --parallel-mode -m pytest -v -k "${TEST_CL}"
+ coverage run --concurrency=thread --parallel-mode -m pytest -v -k pyepics
============================= test session starts ==============================
platform linux -- Python 3.8.12, pytest-7.1.2, pluggy-1.0.0 -- /opt/hostedtoolcache/Python/3.8.12/x64/bin/python
cachedir: .pytest_cache
rootdir: /home/runner/work/ophyd/ophyd, configfile: pytest.ini
plugins: rerunfailures-10.2
collecting ... collected 3738 items / 1869 deselected / 1869 selected

ophyd/tests/test_areadetector.py::test_basic[pyepics] PASSED             [  0%]
ophyd/tests/test_areadetector.py::test_stubbing[pyepics] SKIPPED (co...) [  0%]
ophyd/tests/test_areadetector.py::test_detector[pyepics] PASSED          [  0%]
ophyd/tests/test_areadetector.py::test_tiff_plugin[pyepics] PASSED       [  0%]
ophyd/tests/test_areadetector.py::test_hdf5_plugin[pyepics] PASSED       [  0%]
ophyd/tests/test_areadetector.py::test_subclass[pyepics] PASSED          [  0%]
ophyd/tests/test_areadetector.py::test_getattr[pyepics] PASSED           [  0%]
ophyd/tests/test_areadetector.py::test_invalid_plugins[pyepics] PASSED   [  0%]
ophyd/tests/test_areadetector.py::test_validate_plugins_no_portname[pyepics] PASSED [  0%]
ophyd/tests/test_areadetector.py::test_get_plugin_by_asyn_port[pyepics] PASSED [  0%]
ophyd/tests/test_areadetector.py::test_visualize_asyn_digraph_smoke[pyepics] PASSED [  0%]
ophyd/tests/test_areadetector.py::test_read_configuration_smoke[pyepics] PASSED [  0%]
ophyd/tests/test_areadetector.py::test_str_smoke[pyepics] PASSED         [  0%]

which suggests the problem is the next test.

@tacaswell
Copy link
Contributor

Which looking at a different run (and assuming they are deterministically orderded) gives us

ophyd/tests/test_areadetector.py::test_default_configuration_smoke[pyepics] PASSED [  0%]

and then a block of area detector tests...which suggests we need better timeouts on those?

@ZLLentz
Copy link
Member Author

ZLLentz commented May 10, 2022

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.

@ZLLentz
Copy link
Member Author

ZLLentz commented May 10, 2022

This actually stalls even earlier in the logs PR:

coverage run --concurrency=thread --parallel-mode -m pytest -v -k "${TEST_CL}"
+ coverage run --concurrency=thread --parallel-mode -m pytest -v -k pyepics
============================= test session starts ==============================
platform linux -- Python 3.9.[12](https://github.com/bluesky/ophyd/runs/6375385206?check_suite_focus=true#step:7:12), pytest-7.1.2, pluggy-1.0.0 -- /opt/hostedtoolcache/Python/3.9.12/x64/bin/python
cachedir: .pytest_cache
rootdir: /home/runner/work/ophyd/ophyd, configfile: pytest.ini
plugins: rerunfailures-10.2
collecting ... collected 3734 items / [18](https://github.com/bluesky/ophyd/runs/6375385206?check_suite_focus=true#step:7:18)67 deselected / 1867 selected

ophyd/tests/test_areadetector.py::test_basic[pyepics] PASSED             [  0%]
ophyd/tests/test_areadetector.py::test_stubbing[pyepics] SKIPPED (co...) [  0%]
ophyd/tests/test_areadetector.py::test_detector[pyepics] PASSED          [  0%]
ophyd/tests/test_areadetector.py::test_tiff_plugin[pyepics] PASSED       [  0%]

Copy link
Member

@klauer klauer left a 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/pv_positioner.py Show resolved Hide resolved
ophyd/pv_positioner.py Show resolved Hide resolved
ophyd/pv_positioner.py Show resolved Hide resolved
ophyd/pv_positioner.py Outdated Show resolved Hide resolved
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,
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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.

ZLLentz and others added 2 commits May 12, 2022 10:56
@klauer klauer requested a review from tacaswell May 12, 2022 20:26
@ZLLentz ZLLentz merged commit 0895f9f into bluesky:master May 13, 2022
@ZLLentz ZLLentz deleted the pv-positioner-utils branch May 13, 2022 16:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants