You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 3, 2021. It is now read-only.
There exist different types of hardware capable of processing encoder signals and generating synchronization signals:
Motion controllers e.g. IcePAP, Pmac, etc.
Versatile controllers e.g. Pandabox, PiLC, etc.
These devices consist of set of inputs (encoders signals) and outputs (synchronization signals) and usually can work in two modes, where:
One input is coupled to one output, let's call it coupled mode
Many inputs may produce synchronization signals on many outputs, let's call it multiplexor mode.
Currently, the Sardana TriggerGateController plugin interface allows only the coupled mode. It works as following, one trigger/gate element is defined (assigned to an axis in the TriggerGateController) and configured as synchronizer of an experimental channel controller in the measurement group. During the continuous scan process, it is then loaded with a synchronization description using the SynchOne(axis, synch_description) method and started.
In order to enhance the TriggerGateController plugin interface with the multiplexor mode we need to consider:
Output signal (axis) identification
TriggerGateController uses axis number to identify which output should be used during the measurement (scan). If hardware can work in both modes, then the axis number is used to choose between the outputs e.g. IcePAPTriggerGateController could reserve axis 1, 2, 3, etc. for the coupled mode outputs and axis 0 for the multiplexor mode output.
Input signal (encoder) to motor assignment
Each trigger/gate element (only core and Tango levels, not plugin level) has a new attribute, let's call it, moveable_on_input (MoveableOnInput). Its value differs depending on the supported mode of a given trigger/gate element:
for the coupled mode it is a full name (str) of the moveable which encoder is connected to the input
for the multiplexor mode it is a dictionary mapping full names (str) of motors which encoders are connected to the inputs to the inputs' IDs (str)
Setting of this configuration does not reach the plugin level and reaches only the core level.
Input selection
TriggerGateController has an axis parameter, let's call it active_input (settable with SetAxisPar(axis, name, value)). The core is responsible for finding which input should be used during the measurement based on the moveable_on_input configuration and the measurement group's moveable attribute. The active_input parameter is set during the measurement preparation phase prior to setting the synchronization description.
Synchronization description value
Synchronization description value in position domain should reach the TriggerGateController as moveables dial position. This is a change with respect to the current behavior. It is not strictly necessary to add the multiplexor mode, but it would be nice to have.
Synchronization description factor
Motor's step per unit is not always the correct conversion factor to be applied on the synchronization description (in motor's dial position). A conversion factor of encoder counts per unit may be necessary hence a trigger/gate element (core and Tango levels) has a new attribute, let's call it conversion_factor (ConversionFactor). It's value reaches the TriggerGateController level in for of the conversion_factor axis parameter (settable with SetAxisPar(axis, name, value)).
The above names and implementation details are just proposals and are fully open for changes/comments. What I wanted to share with you are the concepts that IMO we will need to consider when adding the trigger/gate multiplexor mode. Thanks for reading!
The text was updated successfully, but these errors were encountered:
There exist different types of hardware capable of processing encoder signals and generating synchronization signals:
These devices consist of set of inputs (encoders signals) and outputs (synchronization signals) and usually can work in two modes, where:
Currently, the Sardana
TriggerGateController
plugin interface allows only the coupled mode. It works as following, one trigger/gate element is defined (assigned to an axis in theTriggerGateController
) and configured as synchronizer of an experimental channel controller in the measurement group. During the continuous scan process, it is then loaded with a synchronization description using theSynchOne(axis, synch_description)
method and started.In order to enhance the
TriggerGateController
plugin interface with the multiplexor mode we need to consider:Output signal (axis) identification
TriggerGateController
uses axis number to identify which output should be used during the measurement (scan). If hardware can work in both modes, then the axis number is used to choose between the outputs e.g.IcePAPTriggerGateController
could reserve axis 1, 2, 3, etc. for the coupled mode outputs and axis 0 for the multiplexor mode output.Input signal (encoder) to motor assignment
Each trigger/gate element (only core and Tango levels, not plugin level) has a new attribute, let's call it,
moveable_on_input
(MoveableOnInput
). Its value differs depending on the supported mode of a given trigger/gate element:Setting of this configuration does not reach the plugin level and reaches only the core level.
Input selection
TriggerGateController
has an axis parameter, let's call itactive_input
(settable withSetAxisPar(axis, name, value)
). The core is responsible for finding which input should be used during the measurement based on themoveable_on_input
configuration and the measurement group'smoveable
attribute. Theactive_input
parameter is set during the measurement preparation phase prior to setting the synchronization description.Synchronization description value
Synchronization description value in position domain should reach the
TriggerGateController
as moveables dial position. This is a change with respect to the current behavior. It is not strictly necessary to add the multiplexor mode, but it would be nice to have.Synchronization description factor
Motor's step per unit is not always the correct conversion factor to be applied on the synchronization description (in motor's dial position). A conversion factor of encoder counts per unit may be necessary hence a trigger/gate element (core and Tango levels) has a new attribute, let's call it
conversion_factor
(ConversionFactor
). It's value reaches theTriggerGateController
level in for of theconversion_factor
axis parameter (settable withSetAxisPar(axis, name, value)
).The above names and implementation details are just proposals and are fully open for changes/comments. What I wanted to share with you are the concepts that IMO we will need to consider when adding the trigger/gate multiplexor mode. Thanks for reading!
The text was updated successfully, but these errors were encountered: