Parameter declaration in controller to avoid boilerplate coding in plugins #1021
Replies: 2 comments 4 replies
-
|
So the approach I was actually following with the "Capabilities" and Observables/Variables share some features with it. When loading the plugin, it would go through a method called: infer_capabilities which would make the associated DAQ_move / DAQ_viewer. Then one has to give specific methods that match the name of the variables and the observables. In practice, I was thinking as having two methods (name is not important):
What I see though with your example is that the concept of channel/axis can be pretty relevant. In theory, no need to repeat X times an entry if they are just different by an index. This can still be fairly well handled with a list comprehension without too much boiler plate though but I am thinking that DAQ_move could maybe handle multiaxes (with similar settings) more directly. |
Beta Was this translation helpful? Give feedback.
-
|
I see various things we should clarify.
Details:
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
With @seb5g I recently discussed a possible new way to declare an instrument plugin which could avoid quite some boiler plate coding when values and parameters are to be handled in a common, generic fashion.
The idea: a class variable of type dict in the controller declares the facilities of the controlled physical device (actuators, detectors, global parameters, per channel (actuator or detector) parameters and, if necessary, the corresponding getter and setter methods. The corresponding plugins are then created on the fly from this dictionary. On the other hand, if any specialized operations are required which cannot be performed inside the controller by the setter/getter methods, the existing way of declaring a plugin can be taken.
advantages:
The declaration could be done in the following spirit (example of an Avantes line scan spectrograph with 10 digital outputs, two analog inputs and two analog outputs)
The controller would have to provide the methods
In case that for whatever reason other names have to be used, a corresponding entry named 'getter' / 'setter' / 'grab' has to be provided.
A different approach for the controller could be that it exposes an object per detector and per actuator axis on which the getter and setter methods are implemented as python properties.
Please comment ...
Beta Was this translation helpful? Give feedback.
All reactions