Errors on Eiger 500K because link_2 and link_3 don't exist

[MarkRivers]

I have added ReadStatus.SCAN to the medm screen so the user can control how often the status values, including temperature and humidity are updated.

When ReadStatus.SCAN is set to a periodic scan rate on the Pilatus 500K it results in the following error messages each time eigerStatus() is called.

RestApi::get: [param=link_2] server returned error code 500
2018/08/29 08:35:43.164 Param[LINK_2]::baseFetch: [param=link_2] unable to parse json response
[]
2018/08/29 08:35:43.164 Param[LINK_2]::fetch<int>: [param=LINK_2] underlying baseFetch failed
RestApi::get: [param=link_3] server returned error code 500
2018/08/29 08:35:43.167 Param[LINK_3]::baseFetch: [param=link_3] unable to parse json response
[]
2018/08/29 08:35:43.167 Param[LINK_3]::fetch<int>: [param=LINK_3] underlying baseFetch failed
2018/08/29 08:35:43.175 eigerDetector::writeInt32: error status=3 function=86, value=1
2018/08/29 08:35:43.175 13EIG1:cam1:ReadStatus devAsynInt32::processCallbackOutput process error

The reason for the errors is that link_2 and link_3 don't exist on this model. What is the best way to handle this problem to avoid the constant stream of error messages?

[GDYendell]

There probably needs to be some logic for creating sensor-specific and firmware-specific parameters. DLS are getting an Eiger 2 X 4M in the next few months and the API provided with firmware version 1.8 is very different, so we are going to need to solve this problem too. I also believe that from 1.6 to 1.7, link_X becomes link/X.

As a side note: In the restClient library that I created from ADEiger, I have made it only print these messages once per parameter until they manage to fetch successfully again. I thought I might eventually refactor ADEiger to use this library, but it still needs work.

[brunoseivam]

I also believe that from 1.6 to 1.7, link_X becomes link/X

Dectris doesn't feel like keeping the API stable. It has bitten me way too many times in the past. I don't think there's a sane way of having ADEiger be generic enough to deal with differences between API versions. What I did was to require (but not enforce) a minimum API version for ADEiger (see README's notes).

At BNL I controlled all detectors so it was straightforward for me to keep them all updated.

Regarding the problem at hand, I think there could be some sort of feature detection by probing how many link_X exist or by having a lookup table based on the reported detector name.

[brunoseivam]

Maybe with more people complaining besides me they'll stop with this API breakage shenanigans....

[MarkRivers]

I have fixed this in 50e13b24226e6eb702bd88a8dab16ed280c99137. I also fixed a problem that if ReadStatus is periodically processing while acquisition is active there are error messages when ADEiger tries to read the status (error 400 I think). I changed eigerStatus() to return asynSuccess immediately if ADAcquire is true.