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

Version for API 1.6.0 or 1.8.0 and Eiger1 or Eiger2 #38

Merged
merged 61 commits into from
Dec 22, 2020
Merged

Conversation

MarkRivers
Copy link
Member

This PR is based on the work by Gary Yandel at DLS, with some improvements.

  • It does not assume that the Eiger1 runs the Simplon API 1.6.0 and the Eiger2 runs 1.8.0. There are now some Eiger1 detectors running 1.8.0. The driver thus knows both what version of the Simplon API the detector uses as well as what Eiger model it is.
  • The eigerDetectorConfig command does not take the eigerModel argument that the DLS branch used. The driver determines both the Simplon API in use and the Eiger model via the Simplon API.
  • It is been tested with an Eiger1 500K and an Eiger2 500K.

There is still additional work to be done:

  • Add support for additional Eiger2 features, such as 2 energy thresholds, number of exposures per image, etc.
  • Make medm screens that are model/API specific.
  • More testing

Since this version appears to work with both APIs and both models it can be merged into master while additional work is done on another branch.

GDYendell and others added 26 commits November 30, 2020 12:16
This is to make sure git tracks the rename before the file
  is split into to child templates
Fix units on detector distance
Add new parameters
  * Header Detail
  * Counting Mode
  * Auto Summation
  * Initialize Command
  * Image Bit Depth
In SIMPLON API version 1.8.0 as of EIGER2 software version 2020.1, some
(all?) API JSON responses that had previously returned a value_type of
"string" now return a value_type of "list".  To accommodate this, add
"list" as a synonym for "string".

Example:

  Before installing EIGER2 2020.1:

  ----
  $ curl http://10.42.41.10/detector/api/1.8.0/status/error
  {"value": [], "value_type": "string"}
  ----

  After installing EIGER2 2020.1:

  ----
  $ curl http://10.42.41.10/detector/api/1.8.0/status/error
  {"access_mode":"r","value":[],"value_type":"list"}
  ----
In SIMPLON API version 1.8.0 as of EIGER2 software version 2020.1, some
(all?) API JSON responses that had presumably previously returned an
empty response now return an empty JSON string (i.e., two double-quote
characters).  To accommodate this, treat an empty JSON string the same
as an empty response.

Example:

  After installing EIGER2 2020.1:

  ----
  $ curl -X PUT -H 'Content-Type: application/json' -d '{"value":"disabled"}' http://10.42.41.10/monitor/api/1.8.0/config/mode
  ""
  ----
The $(P)$(R)BitDepthImage_RBV PV is a longin record for the
bit_depth_image SIMPLON API parameter, with DTYP=asynInt32, but the INP
parameter is EIG_DCD_bit_depth_image which indicates an Asyn type of
asynFloat64.  This causes the EigerParam::fetch(double &, int) member
function to be called to read the SIMPLON API parameter.  The member
function expects a JSON value_type of "float", but the bit_depth_image
parameter JSON value_type is either "int" or "uint", so the member
function fails with an error indicating that the JSON type is
unexpected.  Change the Asyn type of the bit_depth_image parameter to
asynInt32 to allow it to be read without error.
The mDCUBufFree parameter is only created in the eigerDetector
constructor if mEigerModel is EIGER1, but the mDCUBufFree parameter is
fetched unconditionally later in the constructor which will result in
a crash if mEigerModel is not EIGER1.  Fix this by only fetching the
mDCUBufFree parameter if mEigerModel is EIGER1.
The SIMPLON API for the compression parameter has changed over time, in
particular the GET response "allowed_values" value.  In 1.6.0, it is
["lz4", "bslz4"].  In 1.8.0, it is ["bslz4", "lz4", "none"] (i.e., order
changed and "none" added).  In 1.8.0 after the EIGER2 2020.1 release it
is ["none","lz4","bslz4"] (i.e., order changed).  Accommodate all three
variations of the API.

Example:

  1.6.0:

  ----
  $ curl http://10.42.41.10/detector/api/1.6.0/config/compression
  : Due to lack of access to a 1.6.0 SIMPLON API for testing, the full
  : response for the query is unconfirmed, but it is believed to include
  : the following:
  {"allowed_values": ["lz4", "bslz4"]}
  ----

  1.8.0:

  ----
  $ curl http://10.42.41.10/detector/api/1.8.0/config/compression
  {"value": "bslz4", "value_type": "string", "allowed_values": ["bslz4", "lz4", "none"], "access_mode": "rw"}
  ----

  1.8.0 after installing EIGER2 2020.1:

  ----
  $ curl http://10.42.41.10/detector/api/1.8.0/config/compression
{"access_mode":"rw","allowed_values":["none","lz4","bslz4"],"value":"bslz4","value_type":"string"}
  ----
Added code to determine the API version using the Simplon API.
Added a public method to return the API version.
…command.

Added new eigerModel_t enum.
Added new private member variable holding the Eiger REst API version.
The eigerModel is now determined by parsing the "description" parameter from the Simplon API.
Improved the logic so the API version and the detector model (Eiger1 or Eiger2) are decoupled.
Some things depend on the API version and some depend on the model.
Changed so ADFirmwareVersion is the firmware version, not the API version.
Change so ADSDKVersion is the API version.  Previously it was unused.
@cmkewish
Copy link

Hi @MarkRivers

An issue I ran into was the EIGER2 X 1M detector failing to correctly disarm when trying to interrupt a running series of exposures.

We run a mode that we call "freerun" scans where we set (in the API language) the trigger mode to manually-triggered internal series, with ntriggers = 1 and, e.g., nimages = 2 * [number of expected pixels needed in a scan], and then let the detector time it's own acquisitions, and send a disarm at the end to close the series. The master file ends up containing a ton of empty data links at the end but this is fine.

This was working prior to 2020.1 (I think) but when I asked Dectris about it they suggested to add a cancel or an abort command before disarm? The first one will stop the data acquisition after the current image is completed, while the second command would stop any acquisition immediately.

Is it included (or possible to include) into this ADEiger version to send CANCEL then DISARM when issuing a Acquire=0?

Thanks,
Cameron

  Theshold2Energy, Threshold2Energy_RBV
  Threshold2Enable, Threshold2Enable_RBV
  ThresholdDiffEnable, ThresholdDiffEnable_RBV
  CountrateCorrEnable, CountrateCorrEnable_RBV
  ExtGateMode, ExtGateMode_RBV
  HVReset
  HVState_RBV
Added "External Gate" choice for TriggerMode and TriggerMode_RBV
Threshold2  (threshold 2 energy)
Threshold2Enable (threshold 2 enable)
ThresholdDiffEnable (enable computing difference image of threshold1 - threshold2)
Add External Gate option to ADTriggerMode (extg option; in next firmware release)
ExtGateMode (external gate mode; in next firmware release)
HVResetTime (high voltage reset time)
HVReset (reset high voltage for the specified time)
HVState (current state of high voltage)
NumExposures (nexpi parmaeter; in next firmware release)
@MarkRivers
Copy link
Member Author

@cmkewish I have created a new issue #39 for your problem, separating it from this PR.

@MarkRivers
Copy link
Member Author

@MarkRivers said:

There is still additional work to be done:
Add support for additional Eiger2 features, such as 2 energy thresholds, number of exposures per image, etc.
Make medm screens that are model/API specific.
More testing

I have now added support for 2 energy thresholds, and I have model-specific medm screens and auto-converted OPI screens.

I have also added support for ExternalGate feature that will be in the next firmware release in early 2021 but is already available for testing.

I just tagged R2-7 which had all changes prior to adding Eiger2 support.

I think this branch is now working well enough to be merged into master, so I am doing that now.

@MarkRivers MarkRivers merged commit 5900c51 into master Dec 22, 2020
@MarkRivers MarkRivers deleted the 1.6_or_1.8 branch December 22, 2020 22:24
@MarkRivers
Copy link
Member Author

I am close to being ready to tag a new release. I would appreciate if people can test the master branch on both Eiger1 and Eiger2 detectors. Remaining things to be done:

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.

4 participants