=================
The motion module
=================

:doc:`motion <cmd_motion>` is an abstraction layer that interfaces with the modules actually controlling the hardware and provides a unified API. The compatible modules presently implemented are:

.. toctree::
    :titlesonly:

    Thorlabs APT <cmd_th_apt>
    Newport ESP301 <cmd_nw_esp301>
    PARKER XLi <cmd_pk_xli>

Pool and identification
=======================

During init_motion, the initialization function for the particular model is called. Its name must be *init_MODEL* (e.g.: :py:func:`init_th_apt <cmd_th_apt.init_th_apt>`). The convention style for MODEL is a two-letter maker symbol plus the model, separated by an underscore (_). Any other function from the motion controller module must be able to determine how to address the hardware only based on its *model_id*.

Initialization
==============

As pointed out previously, cmd_motion provides a function init_motion and requires functions init_MODEL from the modules with which it interfaces. The init_motion declaration is:

.. py:function:: init_motion (motion_id,conf_string)

    Initialize motion system with id *motion_id*. Provide the :doc:`conf_strings <conf_strings>` for its axis.

Functions
=========

A series of functions in cmd_motion interface the corresponding functions on the motion controller modules. In most cases, a call to the function of the same name is performed (replacing _motion by _MODEL). All motion controller modules must include, at least, an implementation of the following functions:

- init_MODEL (*model_id*,*conf_string*)
- deinit_MODEL (*model_id*)
- config_MODEL (*model_id*, *pos_max*, *pos_min*)
- inval_MODEL (*model_id*)
- move_MODEL (*model_id*, *displacement*, *speed*, *acceleration*)
- get_pos_MODEL (*model_id*)

See the API below for a description of their functionality:

API
===

.. automodule:: cmd_motion
    :members:
    :member-order: bysource