Support for other SIMPLON detectors -- PILATUS4 and SELUN

[tguruswamy]

DECTRIS are now releasing other detectors based on the SIMPLON 1.8.0 api, currently we have access to the PILATUS4 and SELUN.

A quick addition of extra PVs for PILATUS4 four energy-thresholds (control, but not image readback) has been done in https://github.com/APSDetectors/ADEiger/tree/pilatus4

However we may be better off revisiting the architecture of this driver to handle different detector models. Perhaps we can create settings dynamically based on querying the api rather than from conditionals on the model string.

Note the API can be enumerated by requesting http://<api_url>/keys e.g. (with a SELUN detector):

$ curl http://10.42.41.10/detector/api/1.8.0/keys
["command","config","status"]

$ curl http://10.42.41.10/detector/api/1.8.0/config/keys
["auto_sum_strict","auto_summation","beam_center_x","beam_center_y","binning_mode","bit_depth_image","bit_depth_readout","chi_axis","chi_increment","chi_start","compression","count_time","counting_mode","countrate_correction_applied","countrate_correction_count_cutoff","countrate_correction_table","data_collection_date","description","detector_distance","detector_number","detector_orientation","detector_orientation_angle","detector_orientation_axis","detector_readout_time","detector_translation","eiger_fw_version","element","fast_arm","flatfield","flatfield_correction_applied","flux_type","flux_value","frame_count_time","frame_time","incident_energy","incident_particle_type","instrument_name","kappa_axis","kappa_increment","kappa_start","mask_to_zero","nexpi","nimages","ntrigger","number_of_excluded_pixels","omega_axis","omega_increment","omega_start","phi_axis","phi_increment","phi_start","photon_energy","pixel_format","pixel_mask","pixel_mask_applied","roi_mode","sample_name","sensor_material","sensor_thickness","software_version","source_name","test_image_mode","test_image_value","threshold/1/energy","threshold/1/flatfield","threshold/1/number_of_excluded_pixels","threshold/1/pixel_mask","threshold_energy","transformation_order","trigger_mode","trigger_start_delay","two_theta_axis","two_theta_increment","two_theta_start","virtual_pixel_correction_applied","x_pixel_size","x_pixels_in_detector","y_pixel_size","y_pixels_in_detector"]

[MarkRivers]

@tguruswamy I'd like to merge your changes for the Pilatus4 into master. But first I think you should merge the latest master into APSDetectors. There are no conflicts, but there are files I changed that you did too. I created a pull request.

[gustavosr8]

Hi!
Since #74 has been merged, are we already given full support to Pilatus4?
Do you have a plan for when you will tag the R3-6 release with this support?

[MarkRivers]

I would like to resolve #77 and #69 before tagging R3-6.

#77 has the logic for using Stream2 timestamps incorrectly inside a conditional for compression.

#69 Dectris claims that the Stream2 LZ4 compression, while chunked differently than the Stream LZ4 compression, is still compatible with the standard lz4 library. They sent a Python program that writes the uncompressed data to an HDF5 file which can be read with no problem. They say that our code is adding an extra header to the LZ4, which is the problem. I have not had time to resolve this yet.