You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When testing v0.0.2 of the codebase a number of issues were found:
Initially no PV connections could be made, this was fixed by installing caproto. We need to look at which CA bindings we want to use in mx_bluesky and make sure we correctly have them installed
The beam centre in the OAV takes some time to initialise, even after the connection has been waited on. This was causing issues on startup of the move to click. To fix this on the beamline the OAV was initialised once earlier and the beam centre was only requested on click rather than all mouse events
There was an issue in moving to click using set and so no waiting for the pmac to finish processing the command to move x before we move y. This was fixed by using put with wait=True but it could be true in other places in the codebase
There are lots of instances in the log of move to click in the form of Cannot move to target thread - not fixed on beamline as it seemed to cause no issues
The sign of the y axis was incorrect in the EDM - not fixed on the beamline yet, we need to think about a better solution for this
The zoomcalibrator had to be updated to 13.5 to get the move on click to work correctly
Beam centre matched GDA but did not match the value on the OAV viewer
In general starting up the viewer and interacting with the system seemed very slow and unresponsive - this is probably due to us recreating ophyd devices every time we run anything
The paths to the parameter files were incorrect, rather than src/mx_bluesky/I24/serial/parameters they should be mx_bluesky/src/mx_bluesky/I24/serial/parameters - are these paths relative to where run_fixed_target was run from?
Nit: There were lots of points in the logs that said "Chip type is 0", it would be better to print the string of the chip type
Generally the behaviour of setting fiducial seems wrong, if I set the fiducial then try and return to it it does not go to the correct place.
The text was updated successfully, but these errors were encountered:
Need a better solution for paths to parameter files so that they always end up in the correct place wherever it is run from, right now they assume run_fixed_target is run from mx_bluesky
Workaround the value for the det_type PV which can be both a string (eiger/pilatus) or an int (0/1) depending on where it's set. Have it always as string to avoid confusion.
Check the whole code for places where set is used for the pmac string and replace with put
When testing v0.0.2 of the codebase a number of issues were found:
caproto
. We need to look at which CA bindings we want to use inmx_bluesky
and make sure we correctly have them installedOAV
was initialised once earlier and the beam centre was only requested on click rather than all mouse eventsset
and so no waiting for the pmac to finish processing the command to move x before we move y. This was fixed by usingput
withwait=True
but it could be true in other places in the codebaseCannot move to target thread
- not fixed on beamline as it seemed to cause no issueszoomcalibrator
had to be updated to 13.5 to get the move on click to work correctlysrc/mx_bluesky/I24/serial/parameters
they should bemx_bluesky/src/mx_bluesky/I24/serial/parameters
- are these paths relative to whererun_fixed_target
was run from?The text was updated successfully, but these errors were encountered: