Missing formalization of concepts in calc. motor controllers: constrains divergences and parameters
The current implementation of calc. motor controllers allows that NR and NV, the number real and virtual motors, respectively, be different. From a theoretical point of view, this means that the number of states (i.e., combinations of motor positions) in the real and virtual spaces are different. So a (virtually infinite) number of states in one space will not have a unique correspondence on the other space, opening the possibility of ambiguity. In other words, the transformation is not bijective.
It is important to be conscient of the side effects associated to non-bijective transformations. There should be a formalisation of these cases, so ambiguities are explicitly detectable, minimizing the confusions in real beamline experiments by means of a more deterministic behavior.
We can separate the problem in two different cases:
NR > NV
These configrations are based on implicit constrains that help in the conversion V -> P
. A typical example is a virtual energy E motor controlling multiple axes m0..mN, each of them setting the energy of individual components (multiple crystal analyzers, monochromator + undulator, etc). In the P -> V
only one motor m0 is used to calculate E: E = E0
. In the V -> P
transformation the implicit constrains are that the energies of all the other motors will follow the first: E1..EN = E0
. The risk here is that during a movement of E one of the axis mi hits a limit switch. At the end of the movement the system be will be misaligned because Ei != E0
. If the session is closed the trace of the error message warning about the limit switch is lost. Data acquired after that will be wrong without any mechanism from Bliss to warn the user.
The current implementation lacks the concept of constrains divergences
, virtual motors that quantify the divergences from the implicit constrains. In the default case these motors would be systematically forced to 0 on each V -> P
transformation. A warning mechanism could be implemented if they are not in the vicinity of 0 during a P -> V
transformation. In the previous example, the constrain divergence
virtual motors d1..dN could be calculated as di = Ei - E0
.
The real motor positions should be explicitly calculated taking into account their corresponding virtual divergences. In our example: mi = fi(Ei) = fi(E0 + di)
. As mentioned before, the default working mode should force di to 0. However, a tuning mode
can be foreseen where the indivitual di
can be adjusted to a non-null value, allowing the fine alignment of individual components.
NR < NV
These cases consider some of the virtual motors as auxiliary parameters in the V -> P
calculations that are not affected in the P -> V
step. It is handy to have virtual motors on those parameters in order to perform scans on them. Examples can be additional virtual reference frames that simplify sample or detector positioning.
Another missing feature is the concept of parameter, a virtual motor that cannot be updated in the 'P -> V` transformation. The current implementation lets the specific code of each controller the responsibility of keeping constant parameters when calculating from real motors. Ignoring this concept could lead to undesirable behavior, difficult to trace and debug.
General case
The calc. motor controller could distinguish between:
- NR real motors
- NV virtual motors
- ND constrain divergence motors (optional)
- NP parameter motors (optional)
so that the equality NR = NV + ND - NP
always holds.