ambarb
commented
3 years ago Open ambarb opened 4 years ago
ambarb
commented
3 years ago ambarb
commented
3 years ago https://github.com/bluesky/bluesky/issues/1159 other useful discussion.
mrakitin
commented
3 years ago It's a bit hard to fully understand the issue without the source code from ~/Beamline/Commissioning/2020_07/MonoStab.py. I think we should develop an approach to keep these files in an accessible place. If there is some private information, there can be a private GitHub repo for these things. Here is a similar repo for the SIX beamline, which made it more convenient to provide support: https://github.com/NSLS-II-SIX/science_commissioning.
ambarb
commented
3 years ago @mrakitin I don't understand. the issue I report is using bpp.pchain. It doesn't come from a script or ,py file
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
mrakitin
commented
3 years ago @mrakitin I don't understand. the issue I report is using
bpp.pchain. It doesn't come from a script or ,py file
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>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
I think that can be a repo with the name of your preference. The current Commissioning directory can easily be made a repo with just git init and git add <...> commands. I can assist with that.
ambarb
commented
3 years ago 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 inout device is used to block the beam for dark image collection. ct_darks_all()
Three options:
mrakitin
commented
3 years ago @ambarb, thanks for documenting more details about the issue!
ambarb
commented
2 years ago will update with a scan number and the full traceback as there is more information now.
ambarb
commented
2 years ago looks like we should check also exception handling when inout fails. To be clear, inout is not failing; what happens is bluesky thinks it failed.
generator count_flatfield ['0bb2fe57'] (scan num: 156290)
Setting to 200 images.
** (2022-07-03 16:13:40) Had to reactuate shutter while Ining
** (2022-07-03 16:13:40) Had to reactuate shutter while Ining
Returning to intial conditions (pre-count).
An exception has occurred, use '%tb verbose' to see the full traceback.
FailedStatus: DeviceStatus(device=inout, done=True, success=False)
During handling of the above exception, another exception occurred:
RuntimeError: trying to set while a set is in progress
See /var/log/bluesky/bluesky.log for the full traceback.Versions of DSSI software:
- Bluesky : v1.8.3
- Ophyd : v1.6.4
- Databroker : v2.0.0b2@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:
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