-
Notifications
You must be signed in to change notification settings - Fork 5
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
one cause of frozen scans - using ct_dark_all() plan with fast acquition times - intermittent issue #38
Comments
related to #25 |
bluesky/bluesky#1159 other useful discussion. |
It's a bit hard to fully understand the issue without the source code from |
@mrakitin I don't understand. the issue I report is using but you are correct in that this GitHub goodness is missing form commissioning plans. I've allocated a path on the main workstation but haven't had time to creat the repo. Are there any guidelines form DSSI? We want the repo to be independent from the profile |
Got it. I was confused by the following lines after a quick look at the error: RunEngineInterrupted Traceback (most recent call last)
~/Beamline/Commissioning/2020_07/MonoStab.py in <module>
I think that can be a repo with the name of your preference. The current |
Following up. We discussed at the beamline and @mrakitin suggested we use the facility two-button shutter ophyd device because it is heavily tested and more robust. our two-button shutter is based off of the same ioc, but the strings associated with the state are "In" and "Out" and "Inserted" and "Not Inserted". @mrakitin liked other aspects of the ophyd device too but he was not sure that we should try to "fix" the facility two-button shutter since it could potentially break a lot for a lot of people. The Three options:
|
@ambarb, thanks for documenting more details about the issue! |
will update with a scan number and the full traceback as there is more information now. |
looks like we should check also exception handling when
Versions of DSSI software:
|
@johnsinsheimer I think this is pretty in control, right? We can test more by letting making the acquire period as small as possible when running the camera at 0.2s or faster. |
Versions of DAMA software:
- Bluesky : v1.6.3
- Ophyd : v1.5.1
- Databroker : v1.0.6
This problem is old and not consistently occurring. removed all .value in January and that did not help. seems to happen when exposure time is short and "network" robustness.
successful run has the setpoint never change (camonitor) but the readback value does change
waiting for it to fail again to capture camonitor
The text was updated successfully, but these errors were encountered: