Motor Issues and Plans

[Ron Sluiter <sluiter@aps.anl.gov>]

This is a multi-part message in MIME format.
--------------ACA57E8365C2AB7A56D4B00A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The items in the attached file are either motor record bug fixes or
enhancements; some items have been completed; most are planned for in
the near future.  The purpose of this communication is not to announce
changes to the next xfd release, but to inform others of the BCDA
groups' development plans.  No decision has yet been made to include any
of the enhancements described here in the next xfd release.  Comments
and suggestions on motor related features are welcome.  Please respond.

Note: The ID#'s in the attached document have no meaning for readers
outside the BCDA group.  They refer to a previous 'Motor issues meeting
minutes' document.
--------------ACA57E8365C2AB7A56D4B00A
Content-Type: text/plain; charset=us-ascii; name='motomemo.txt'
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename='motomemo.txt'



                              Motor Issues


-> Inconsistent or stale status information (ID #12)

Two problems have occurred recently that are symptoms of the same error
in the Oregon Microsystems (OMS) device support.  The first problem is
unwanted and erroneous motor stop commands being issued at the beginning
of a motion command.  The second problem is old information in the RRBV
field.  Under certain circumstance (which I have not yet determined) the
data in the RRBV field is consistently old.

The root cause in both the above problems is that the status response
from the OMS boards is not guaranteed to be always consistent.  For
example, given direction and position status after a motion command, if
there was a change in motion direction, either one of the following two
results may occur:

  1. The direction indicator may change, but not the position.
  2. The position may change, but not the direction indicator.

The process() function from motorRecord.c does a test for whether or not
to issue a STOP_AXIS command.  That test assumes that the status
response from the OMS board is consistent.  When the status is
inconsistent, an erroneous STOP_AXIS command is issued.

If the time between issuing motion commands and status query is greater
than approximately 10ms, the status response from the OMS board is
always consistent.  This was found empirically and is the solution I
intend to implement.  Namely, to insure there is always a minimum delay
of 10ms between the OMS device driver issuing a motion command and a
status update.

Status: Implemented and tested.  Found hole in the logic.  Solution is
under review.

-> Servo support (ID #31)

The motor record classifies a motor as a servo if it has two features;
an adjustable closed loop position response gain and the ability to
enable/disable closed loop position control (i.e., motor torque).  A
motor lacking either of the above two features is classified as a
stepper and is supported by the standard motor record features.  The
following three motor record fields support servo motors:

  1. GAIN - Closed loop position response gain of the motor.
  2. CNEN - Enable/disable closed loop position control request.
  3. STEN - Closed loop position control status (i.e.,
     enabled/disabled).

Currently, servo support is only available with OMS's VME58 device
support (i.e., VME58-[4S/8S/2S2/2S6/4S4/6S2] model boards).  At driver
initialization, the driver automatically detects whether or not the
underlying device supports the use of the GAIN field and thereby
classifies the motor as a stepper or a servo.   Bit#11 of the MSTA field
is set on/off based on the results of this test.  If the device supports
the GAIN field, then bit#11 of the MSTA is set on and all of the above
servo fields are enabled.   Otherwise, they are disabled and bit#11 of
the MSTA is set off.  When the servo fields are disabled, they can still
be read or written to without an error response.

The VME58 device support allows the closed loop position gain of the
motor to be set directly through the GAIN field.  For the VME58, setting
the GAIN field value results in the Combined Coefficient command (i.e.,
KK#) being executed with the GAIN field value as the argument to the
command.  This command, in turn, sets the PID loop parameter values.

The user can request that the closed loop position control be enabled or
disabled by setting the CNEN field nonzero or zero, respectively.
Likewise, the user can monitor the state of closed loop position control
(i.e., enabled/disabled) by reading the STEN field.  See the OMS 'VME58
Family User's Manual' for further details.

Status: Implemented, waiting for field testing.

-> Record initialization, pre-move and post-move command primitives (ID
	#6,#7, #8, #9, #26,#30)

Three motor record fields are available to the user that can be used to
send ASCII command primitives to the servo control board at fixed,
predefined, times.  Each field is defined as a character string.

  1. INIT - Sent at record initialization.
  2. PRE  - Sent before every command string that causes motion.
  3. POST - Sent after a complete motion is finished.

No error checking is done by the motor record or the device driver to
insure that the command strings are valid.  Command primitives that
result in a response from the motion control board are valid, but the
response is not processed.

Status: Work in progress.

-> Continuous status updates (ID #11)

Currently the OMS device support only updates status information when
the motor is in motion.  Our plan is to change this so that Limit Switch
and encoder (if present) status are continuously, periodically, updated.
Also under consideration is a means for reading switches and positions
on demand.

Status: Feature definition.

-> Compumotor and Klinger serial controller support (ID #17, #18)

Add device driver support for Compumotor and Klinger serial controllers
with features and functionality similar to the existing MM4000.

Status: Preliminary investigation into MM4000 device driver.

The remainder of the features are listed with little or no comment:

   * Backlash takeout implemented entirely in the motor record (ID #27).
   * Add explicit maximum speed field (VMAX) to motor record (ID #1).
     VMAX defined in EGU.
   * Backlash takeout option for on-the-fly scans (ID #5).  No pause
     when moving in the preferred direction.
   * Add user comment field to motor record (ID #19).
   * Support high/low software travel limit fields with INLINK field
     types (ID #4).
   * Support modulo positioning (ID #14).  User specifies
     CW/CCW/Shortest_Path positioning.
   * Add BUSY field to motor record (ID #22).


--------------ACA57E8365C2AB7A56D4B00A--