Authors:Dan Kohler


This YEP defines the has-transformed-position trait.

Table of Contents


Certain motors have use for both an absolute, or "native", position (defined by hardware) and a relative position (defined by the implementation of the motor within a system). For example, a rotational stage may have an hardware position defined as steps from a home position, but an experimenter would care more about the angular position relative to a special angle of the system (e.g. normal incidence).

One of the most basic desires is to offset motor positions so that the position can be set in "relative coordinates":

Scheme 1:

              hw limit 1   |---------*------------|  hw limit 2

native coordinates         0 ... ... x ...   ... max
relative coordinates      -x ... ... 0 ...   ... max-x

A further abstraction is to transform relative positions into positions and units meaningful to the experimenter. Such could be achieved by some function f:

Scheme 2:

              hw limit 1   |---------*------------|  hw limit 2

relative coordinates      -x ... ... 0 ...   ... max-x
transformed coordinates  f(-x) .... f(0) ...... f(max-x)

The functional form of f, which relates relative coordinates to transformed coordinates, is daemon specific. The parameters of the function are implementation specific.


We propose a new trait, has-transformed-position.

This trait distinguishes two types of positions: a native_position, which is a position that relates to underlying hardware calls, and position, which is derived from the native position according to some functional form, to_transformed. The functional form is daemon specific; parameters for the functional form should be specified in state or config, whichever the developer sees as appropriate. The inverse of the function, to_native, is also specified.

The trait introduces one explicit functional parameter, the state variable reference_position, which establishes the null position (0 in the Schemes above) in the native coordinate system. As a default, the functional form of to_transformed uses only this reference position to transform coordinates:

to_transformed(x) = x - reference_position
to_native = x + reference_position

Other functional forms must be hard-coded into the daemon. Parameters controlling these functional forms should be implemented as yaq properties with "metadata" record kind (see below).

Transform parameters are subject to change, so native positions are more robust. As such, state is recorded through native units. In contrast, client calls to the position property will report transformed coordinates.

Implement transform parameters as properties

In contrast to position, which is a property with a "data" record kind, native_position has a "metadata" record kind. Consequently, acquisitions hardware are compelled to not track native position across scans, and a varying native_position can only be discerned from inverting the position.

For this reason, it is strongly recommended that all transform parameters are properties with "metadata" record kind. This is already done with the built-in reference_position parameter, but individual daemons will have to implement this for any other parameters. Recording parameters into metadata ensures that acquisitions will have the necessary parameters to invert position into native_position if the need arises.


This trait requires has-limits (YEP-303). This trait expands the has-limits trait by controlling motor positions using two coordinate systems. One frame (the "transformed" frame) is for common client control. The other frame (the "native" frame) reports position in terms of low-level motor control.


native_reference_position (float)

The reference position, expressed in native coordinates. Default is 0.0 (i.e. reference position is the same as hardware null).



request : float

response : float

Convert a native coordinate to transformed.


request : float

response : float

Convert a transformed coordinate to native. The inverse of to_transformed.


request : float

Set the reference position in native coordinates. Reference position need not be within hardware limits.


response : float

Get the reference position in native coordinates.


response : float

Get the current position in native coordinates.


request : float

Set the current position in native coordinates.


response : {"type": "array", "values" : ["float]}

Returns limits in the relative coordinate system.


response : "string"

Get the units of native coordinates.





Backwards Compatibility

This trait has no effect on has-limits when reference_position = 0.0 and to_transformed(x) == to_native(x) == x.

In state, all values relating to position (position, destination, native_reference_position and hw_limits) are stored in native coordinates. This is so that state values will remain valid even when transforms change.

Rejected Ideas


This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.

built 2022-08-09 20:27:49                                      CC0: no copyright