Stepper Motor

Hardware Description

For driving stepper motors Cosylab's MBox MicroIOC controller is used.

The MBox combines a front-end computer (x86 based PC) to host the front-end control software and a powerfull stepper motor controller (PMac, from Delta Tau Data Systems, Inc., Chatsworth, CA, USA). The PMac stepper motor control is capable to handle simultaneously 8 motors independently. A second box, the power driver, hosts power stages to drive the motors and some electronics for position readback. The power driver should be located close to the motors. Connection to the MBox is by cables which may extend several tens of meters. One power driver can handle up to four motors. Two power drivers can be connected to one MBox.

The system MBox / power drivers:

• Controls up to eight motors idenpendently (two power drivers)
• Supports position read-back
• Supports evaluation of end-switches and middle-contact switch (to detect collisions of slits in the same plane)
• Supports independent drive of each motor as well as synchronous drive of a pair of motors (to motors composing a slit)

Set-Up of an MBox Controller Unit

The FESA software is operational.

To set-up a new MBox Controller unit on a 64-bit system, please refer to MicroIOC installation.

Interface to the Equipment

Handling of the equipment covers set-up of the PMac stepper motor controller and the other hardware, commands to the PMac controller for movement of the motors and read-back of data from the controller, read-back of the actual position and read-out of the end-switches.

A low level software shell (driver) is provided which implements the details of hardware access. The FESA class interacts with the hardware only by this driver.

Functional Aspects

Multiplexing and Timing Control

In the present stage of development (Summer 2013) the stepper motors will not be be driven under control of the timing system (not be driven by timing-events). Correspondingly, motion will not be multiplexed. A timing tinterface is not contained in the MBox hardware.

In a later stage a connection to the timing system is envisaged. The MBox then will be equipped with a timing interface.

Local Operation

For usage in the accelerator operation the stepper motors will be used under control of the accelerator control system with its FESA front-end framework (remote operation). Besides, for hardware maintenance local operation is required.

• The low level software on the MBox provides a direct access to the equipment, bypassing the control system. A basic functionality is provided by front-panel knobs und displays. Full control, and configuration, is supported by an expert control GUI which commmunicates with the MBox via network.
  • Although the expert control GUI communicates via network, it is called local control because it doesn' t use control system means.
• Configuration of the motors (defining moving range, moving direction, combination of two motors to one slit) is exclusively done in local operation mode.
  • A special local control mode is implemented for configuration of the MBox.
• Local operation is a useful means to check correct motor operation manually.
• Local operation of the motors is completely independent from the control system environment. While the MBox generally boots with the control system operation system, it can be booted also with local system. Local operation provides all means to drive and configure the motors.
• At any point the motor control can be switched to local operation. This will interrupt the access by the accelerator control system. However, indication to the accelerator control system is provided when the motors are switched to local control.
• Fall-back to remote control (control by the accelerator control system):
  • When the MBox is in local control mode, the operation mode is switched back automaticaly to remote control after some period of inactivity.
  • When the MBox is in local operation for configuration, no automatic fall-back to remote operation takes place. Switching to remote operation must be initiated explicitly, to protect from inconsistent states when configuration mode is left by some automatism.

The following covers development of the FESA class (remote control by the accelerator control system) for the stepper motors. Aspects of the implementation of the local control, and for local configuration of the motors, are not covered.

Functionality of the Front-End Software

In the implementation of the FESA class following topics should be considered (list is surely not complete):

• General usage in the FAIR facility is envisaged: We should aim at FESA classes which will fit to all (big word) stepper motor installations in FAIR.
  • At least, we should expect that we can extend the FESA classes to the needs of most stepper motor installations in FAIR.
• Local operation (by separate Java expert GUI) must be supported
  • In local operation, equipment modification by FESA properties is not possible (calling setting properties will be rejected)
  • In local operation, reading actual values by FESA properties should be supported
  • It must be indicated in the Status, when equipment is operated locally
  • Parametrization (setting motor parameters) is done in local operation only
• Support single motors and pairs of motors (slits).
  • Each motor will be represented as a single motor, also if the motor is part of a slit
  • Each slit will be represented as one device of type slit, in addition to representation as single motors.
    Therefore each slit (pair of motors) will be represented in parallel as:
    • one device 'slit'
    • two devices 'motor'
• Slits provide simultaneous movement of both motors
  • parallel movement: move center
  • antiparallel movement: change width
• For slits: Setting data and acquisition data (readbacks) always must be consistent between the values for the single motors and for the slit
  • This holds only on the FESA level. If motors are moved by local control, the FESA set value should not be adjusted.
    • When switched back to remote control, actual position may differ from set position, which is accepted.
  • No correction should be made when switched back from local control to remote (FESA) control:
    • Neither should FESA set postion be adjusted to actual position
    • Nor should motors be moved to present FESA set value
• Automatic movement of motors to some maybe old set value in FESA must never happen (also not when from local operation switching back to remote control).
  • In remote operation (control by FESA) motors must move only when a property is called
• Apertures (four motors) may be supported in future.
  • They then may be combined of two slits.
  • No reason can be seen why all four motors have to be moved synchronously. Modification of aperture should always be possible by separate movement of slits in horizontal and in vertical plane (have to be started successively, then both planes move simultaneously but not synchronously).
• No provision will be forseen for synchronous movement of more than two motors.

Equipment Representation Aspects

• For each device, a property 'Setting' must contain all data needed to position the motor / the motors
• For each device, a property 'Acquisition' must provide all information on the actual position of the motors. This includes
  • momentary position (readback)
  • setting value (where motor should be)
  • information whether motor is moving (when still moving, final position is not yet reached)
  • information on precision of position data
    • potentiometer readback: estimation of precision
    • encoder readback: resolution of encoder
  • information whether endswitch is reached
  • For slits, information on both motors are required
• In addtition to absolute position, relative movement should be supported
  • e.g. move 1.2 mm to right
  • e.g. increase slit width by 3.5 mm
• For single motors, stepwise movement should be supported
• Movement to endposition (endswitch) should be supported
  • For slits, only movement to outer end positon must be supported
• Information on precision should be provided:
  • setting: minimal possible movement (position change by one step)
  • aquisition: how accurate is measured position (encoder: exact?, potentiometer: estimated accuracy)
• Position data should be represented by floats, in metric units (to be fixed: meter or mm), except of number of steps for stepwise movement
• Setting properties should not block but return when motor movement is started.
  • Waiting for the motors to reach the desired position is not recommended, since this can take many ten seconds
• First stage should implement FESA properties
  • In a second stage, the existing GSI properties should be provided as GSI DevAcc properties
  • It mut be checked wether implementation may be possible using the gateway only

TODO rework Separation of property definition (and general handling) from MBox specifics by FESA inheritance is recommended.

Property Layout

Proposition for properties see here.

The outline of control software and the outline of the properties con be found in the provided documentation: Stepper Motor Control, System Design.

Additional Information

Comments

Minutes

Meeting 09-Nov-2012

Proposed Extensions

• Move with adjustable constant velocity
  • Reason: Minimize time for emittance measurements, slits without time needed to stop and start movement
  • has to be discussed: relly needed, implementation details
• Provide position in steps
  • Reason: May be helpful for diagnostic purposes
  • Stepper motors only have discrete positions (whole steps). Quite sure, lower software levels (at least PMAC itself) keep track on steps. Make this available by property.
  • Would need extension on driver software level: It looks like internal layers of the motor driver (up to Motor.h) provide set position in steps. Driver, as seen by front-end applications like FESA (MBox.h) should be extended to provide set postion in steps.
  • Can be implemented with next update of motor driver / FESA-class

Documentation

Outline of control software, outline of properties: Stepper Motor Control, System Design.

Additional manuals from Cosylab are provided as part of the Motion-project in the subversion repository.