Motor Record Version 5.2 Release Notice

Requirements

EPICS base R3.14.4 or greater. See the "Required Modules" section of
the Motor Record web page for details.

Modifications to Existing Features

Newport MM3000 Communication

Communication with the Newport MM3000 motor controller was getting out of
synchronization whenever the MM3000 responded with an error message. This
problem was resolved by having recv_mess() in drvMM3000.c detect an error
message response, print the error message and then, recursively, call itself.
This restored communication transmit/receive synchronization.

The OMS boards are RORA VME type interrupters. The "release" register is the
status register. It contains information on the status of the transmit/receive
buffer interrupts and the done interrupt. Since the device driver was not using
the transmit buffer empty interrupt, it was polling the status register when
sending a command to the controller. With the VX2, if the IRQ became active
during a status register read cycle, the IRQ was negated at the end of the cycle
and the CPU board generated a spurious interrupt.

The VME8/44 models somehow prevented the spurious interrupts from occurring by
latching the IRQ, if and when, the IRQ became active during a status register
read.

This problem has been fixed by using all of the OMS board interrupts (i.e.,
enable transmit buffer empty). The OMS VME8/44/VX2/VS4 design is limited with
regard to interrupts by an all or none choice.

Backlash Correction Bug Fix

With release R4-7, there was a slight (undocumented) modification made to the
way that backlash correction functioned. If a move is in the preferred direction
and the backlash speed and acceleration are the same as the slew speed and
acceleration, then the backlash move is skipped and the motor moves directly to
the target position.

Unfortunately, there was a bug in the logic that appeared only when MRES< 0.
When MRES < 0, and the backlash speed and acceleration were the same as the slew
speed and acceleration, the motor record did the opposite of the requirements; i.e.,
it did backlash correction when the move was in the preferred direction and did
not do backlash correction when the move was not in the preferred direction.

Newport ESP300 Device Driver Crash

The Newport ESP300 would randomly crash at boot-up because an internal parameter
("drive_resolution") was not always, under all configurations, initialized. With
this release, the "drive_resolution" is set based on the response to the ESP300
"SU?" command.

In addition, the user is required to set MRES to the resolution of the
controller as explained in the distribution document motor/motorApp/NewportSrc/README.

Update Rate Bug Fix

There were two timing related bugs with the previous release (R5.1). First, the
update rate was not working properly. The end result was that the motor task
was polling controllers as fast as possible. Second, there was an error in the
motor_task function process_messages() that enforces a time delay between
UNDEFINED or IMMEDIATE type commands (e.g., LOAD_POS, SET_ENC_RATIO, etc.) and
an INFO type command. One result of this error was that on OMS VME58
controllersan INFO update after a LOAD_POS command would, intermittently, yield
the previous position.

Backlash Correction after Jogging Bug Fix

Backlash correction after jogging was not working for controllers that do not
support multiple position commands on the same command line (e.g., Newport
ESP300). This has been corrected with this release with one caveat; in contrast
to the feature described in Backlash Correction Bug Fix above, backlash
correction is always done after jogging, regardless of the jog acceleration and
speed parameters

DLY field

Although there is no explicit statement in the motor record documentation, most
user's would expect the "Readback settle time" field (DLY) to update the
readback after the delay timeout. It did not do this. With this release, the
readback is updated one time after the timeout.

Since a functioning DLY field performs the same function as the drvReadbackDelay
variables, with the added advantage that the delay can be motor specific, the
drvReadbackDelay variables have been deleted (except for the MM4000).

Motor Record Version 5.1 Release Notice

!WARNING!

This release of the motor record contains major modifications. It has not,
yet, undergone rigorous testing. I highly recommend that user's test this
release in a safe, non-critical environment before committing themselves to
using it with their critical applications.

This is the first R3.14 compatible release of the motor record. All of the
device drivers, with the exception of OMS, are operating system independent (OSI).
Thanks to Joe Sullivan for his work with the initial port to R3.14.

Requirements

EPICS base R3.14.2 or greater. See the "Required Modules" section of
the Motor Record web page for details.

New Features

MX Device Driver

This release includes a device driver for MX. The MX device driver gives
EPICS user's access to motor controllers that are not currently supported by the
motor record. An MX example is included with the motor distribution. This
device driver requires MX release 0.62.0 or greater.

Mclennan PM600

Mark Rivers added support for the Mclennan PM600 controller.

Motor Record Version 4.7 Release Notice

!WARNING!
motorRecord.dbd has been modified. This requires rebuilding any and all
user trees (i.e., <ioctop>) that load the motor record (see README items
#3 and #4 for details).

Modifications to Existing Features

Redundant DMOV Monitor Postings

Eliminated redundant DMOV monitor postings. Under certain conditions the
motor record would post the state of the DMOV field twice. For example,
with previous releases the motor record would post DMOV=0 twice if backlash
correction was enabled and the user jogged the motor.

OMS VME58 Intermittent Limit Switch Status Error

There is a problem with OMS VME58 ver 2.35-8 firmware when used with
MVME2700 CPU boards. The problem is that the controller board
intermittently, reports that there is no limit switch error when there is an
error. This error can occur if the user repeatedly, tries to move in the
direction of the limit switch when the limit error condition exits. A
delay has been added to work around the problem.

New Features

Motor Synchronized DB Puts

device directive support has been extended to the PREM and POST fields
for OMS devices only. The new device directive supports changing the value
of a database variable. The syntax is as follows:

PREM - @PUT(pvname, pv-value, delay in seconds)@

POST - @PUT(pvname, pv-value)@

Note that the PREM supports a delay argument, but that POST does not. The Readback
settle time field (DLY) should be used to create a time delay after the PV
specified in the POST field is written. See the Miscellaneous fields
section of motorRecord.html for further information on the INIT, PREM and POST
fields.

IMS MDrive17 device support

Device driver support for the Intelligent Motion Systems (IMS) MDrive17 model
motor controller is available with this release.
Home Velocity

A home velocity field (HVEL) was added with this release. Like all speed
related fields, the HVEL is limited by the maximum (VMAX) and base (VBAS)
velocity fields. In addition, if HVEL is not initialized by
the user, the motor record sets HVEL to VBAS.

Motor Record Version 4.6 Release Notice

!WARNING!
motorRecord.dbd has been modified. This requires rebuilding any and all
user trees (i.e., <ioctop>) that load the motor record (see README items
#3 and #4 for details).

Modifications to Existing Features

Soft Channel Device Support

A conflict between the requirements specified under Requirements
Clarification below and the goal of having the same record level
functionality for all device drivers, including Soft Channel device support, was
found by Tim Graber.

A problem occurred with, for example, the SoftMotorEx.db that is distributed
with the motor record, when backlash was enabled in the hard motor(a
motor configured without Soft Channel device support). The result
was that the soft motor (a motor configured with Soft Channel
device support) would interpret the hard motor's backlash correction as the
motor going in the wrong direction, and stop the "hard" motor from completing
the backlash correction.

With this release, the requirements on how the motor record processes a new
target position while the motor is in motion have been modified based on a new
field; New Target Monitor (NTM).

Case #1: The motor record is given a new position, which is in the opposite
direction from the current motor motion. If NTM is yes, the motor
is immediately stopped and given a motion command to the new position. If
NTM is no, the motor completes the previous move before it is given a
motion command to the new position.

Case #2: The motor record is given a new position, which is in the same
direction as the current motor motion, but the new position is closer to the
motor's current position than the original target position. If NTM is yes,
the motor is stopped after it has gone past the new position; then a command is
given to return to the new position. If NTM is no, the motor
completes the previous move before it is given a motion command to the new
position.

Case #3: The motor record is given a new position, which is in the same
direction as the current motor motion, but the new position is further from the
motor's current position than the original position. After the motor
reaches the original target position and stops, a command is given to the new
target position. This case is independent of NTM.

A Soft Channel device support design limitation was discovered by Tim Mooney.
The problem is a result of the modifications made with R4-5 below, where the
soft motor synchronizes it's target position (i.e., VAL/DVAL/RVAL) with it's
readback position (RBV/DRBV/RRBV). Given an application where there are
two or more soft motors driving the system (e.g., slit), when one soft motor is
moved, the other soft motor sees it's readback changing and synchronizes
it's target position with it's readback position at the end of the move, thereby
losing it's target position.

With this release, the LOCK field has been added to allow the user to enable/disable
synchronization due to the readback changing.

Backlash Correction Bug Fixes

The following scenario would put
the motor record into an invalid state. A new target position (i.e., VAL/DVAL/RVAL)
is written to the motor record under the following conditions;

motion is in progress (i.e., DMOV is false).

the new target position is different from the actual position by less than the
retry deadband (|DIFF| < RDBD).

backlash correction is enabled (i.e., BDST is non-zero) and the new move is not
in the "preferred direction" (preferred direction is the direction in which the
motor moves during the backlash-takeout part of a motor move).

A bug was introduced in R4.5 when backlash correction was changed. The
error occurred when a new target position was issued while the motor was moving.
The motor would move to the new target position at the backlash velocity rather
than the slew velocity.

Thanks to Kevin M. Peterson, James B. Stevens and John Maclean for their help in
finding and fixing these bugs.

New Features

Newport ESP300 device support

Device support for the Newport
ESP300 motor controller is available with this release.

Motor Record Version 4.5 Release Notice

!WARNING!
motorRecord.dbd has been modified. This requires you to 'rebuild' any and
all user trees (i.e., <ioctop>) that load the motor record (see README
item #2 for details).

Modifications to Existing Features

Communication Retries

Once a communication error is detected, one retry is attempted (Further retries
are made, if the position RETRY field is non-zero). If the retry fails,
then a communication error is reported. No further attempt is made to
communicate with the controller until subsequent user input (e.g., a new target
position is entered). This change affects all device drivers using GPIB or
RS232 serial communication mechanisms (i.e., non-VME Bus boards).

Requirements Clarification

The requirements
on how the motor record processes a new target position while the motor is in
motion have never been specified. The requirements are as follows:

Case #1: The motor record is given a new position, which is in the
opposite direction from the current motor motion. The motor is immediately
stopped and given a motion command to the new position.

Case #2: The motor record is given a new position, which is in the same
direction as the current motor motion, but the new position is closer to the
motor's current position than the original target position. The motor is
stopped after it has gone past the new position; then a command is given to
return to the new position.

Case #3: The motor record is given a new position, which is in the same
direction as the current motor motion, but the new position is further from the
motor's current position than the original position. After the motor
reaches the original target position and stops, a command is given to the new
target position (Previous motor record versions ignored the new target position.)

Bug Fix for Driver Power Monitoring error

The Driver Power
Monitoring feature (available only with OMS VME58 controllers) was
erroneously and randomly being enabled. This resulted in the error message Drive
power failure at VME58 card# motor# appearing at the VxWorks console.

Soft Channel device support modifications

Prevent record processing before "interruptAccept" is true. This helps
prevent alarms.

If the readback is changing, but motion was not initiated by this record, then
reset the motor record's target to actual position (i.e., VAL/DVAL/RVAL = RBV/DRBV/RRBV)
after the move.

Lowered the priority of the "soft_motor task below the "dbCaLink"task.
This fixes the "DMOV processing before the last DRBV update" problem.

Bug Fix for Array Holes in VMEbus based controllers

For VMEbus based motor controllers only (i.e., OMS), a hole in an array
of VME based motor controller boards caused the system to crash with a memory access
error on the address of the missing controller. For example, if
oms58Setup(3, 8, 0x4000, 190, 5, 10) was issued without a board at 0xFFFF5000, a
bus error would occur if the user attempted to move a motor on the missing board.

This release allows holes in an array of VMEbus based motor controllers.

RES Field

With previous releases of the motor record, the RES field was set to either ERES
or MRES, based on whether or not the following statement was true; MSTA
indicates an encoder is present, AND, UEIP is set to YES. This state (i.e.,
MSTA indicates an encoder is present, AND, UEIP is set to YES) resulted in the
record converting all position and velocity related values from EGU's to raw
encoder counts before sending them to the motor controller. This is the
manner in which the OMS controllers work (see OMS User's Manual, ER# command).

With this release, all raw positions, velocity and acceleration are in terms of
motor steps. The RES field is preserved for backward compatibility only. With
this release, the RES field is always equal to MRES.

Backlash Correction

Previous motor record releases put both the
"slew" and backlash correction moves on the same motor controller command line.
Some controllers (i.e., OMS) handled this correctly by processing the slew move
followed by the backlash correction move. Other controllers (i.e, Newport)
did not handle this correctly and processed the commands immediately, resulting
in the controller moving to the target position without backlash correction, but
at the backlash correction velocity.

With this release, backlash correction commands are not issued to the controller
until after the slew move is completed.

Separate +/- Limit Switch status bits

The MSTA field has
been modified by providing separate +/- limit switch status bits. The MSTA
bits are defined as follows:

DIRECTION: (0:Negative, 1:Positive)

DONE: motion is complete.

PLUS_LS: plus limit switch has been hit.

HOMELS: state of the home limit switch.

Unused

POSITION: closed-loop position control is enabled.

Unused

HOME: if at home position.

PRESENT: encoder is present.

PROBLEM: driver stopped polling.

MOVING: non-zero velocity present.

GAIN_SUPPORT: motor supports closed-loop position control.

COMM_ERR: Controller communication error.

MINUS_LS: minus limit switch has been hit.

New Features

Advanced Control Systems and Mclennan device driver support

Mark Rivers has added device driver support for the following motor controllers:

Advanced Control Systems, Corp. model MCB-4B

Mclennan model PM304

Motor Record Version 4.4 Release Notice

Modifications to Existing Features

Disable Travel Limits

The travel limits can be disabled by setting both dial high and low limits equal
to zero; i.e., DHLM = DLLM = 0.

RVAL ignored error

A problem was discovered with entering target positions through RVAL. If
the difference between the current and the next target position (i.e., RDIF,
DIFF) was less than the retry deadband (RDBD), and the next target position was
in the "preferred direction", then the new RVAL was ignored. This error
occured on releases as far back as V3.4.

New Features

Jog velocity and acceleration parameters

Two new fields (JVEL and JAR) were added to support jog velocity and
acceleration parameters. These fields are only supported with Oregon Micro
Systems, Inc device driver support. The JVEL field allows the user to
change the jog velocity of the motor on-the-fly.

Motor Record Version 4.3 Release Notice

This release of the motor record is strictly a bug fix release; no new features
have been added.

STOP field hangs record

An error was introduced into the motor record with the release of V4.2 (see
README file item #14 under V4.2 ). This error occurred if the STOP field
was activated when the motor was not moving (i.e., MIP = 0). The motor
record would become "stuck", and not respond to a move request (due to the
internal state machine associated with IP being set to the "stop" state), until
the condition was cleared by either a SPMG-stop or some other user action that
forced the MIP field to zero.

HIDEOS support removed

HIDEOS is no longer supported. MPF is the only supported alternative to
HIDEOS.

Motor Record Version 4.2 Release Notice

This release of the motor record is compatible with EPICS R3.13.2 and above.

!WARNING!
motorRecord.dbd has been modified. This requires you to 'rebuild' any and
all user trees (i.e., <ioctop>) that load the motor record (see README
item #20 for details).

Modifications to Existing Features

Precedence between field pairs

At boot-up, if one field of a field pair (i.e., VMAX/SMAX, VBAS/SBAS, VELO/S,
BVEL/SBAK) is zero and the other field is nonzero, the nonzero field takes
precedence. If both fields of a given field pair are nonzero, the RPS
member of the field pair (i.e., SMAX, SBAS, S, SBAK) takes precedence.
This requirement was lost with the release of V4.0.

Moving Off a Limit Switch with a Oms58 device

An error occurs with the OMS VME58 when the user runs the motor into a limit
switch and then attempts to move away from the limit switch. If either an
absolute or incremental move is utilized to move away from the limit switch, the
OMS VME58 ignores the 1st move attempt. Subsequent moves work. In
addition, the user can jog off a limit switch. This error was hidden in
most applications if RTRY was nonzero.

Separate motion commands for target and backlash moves

The record level support assumed that the motor controller would accept two
motion commands on the same command line. This occurs when backlash
compensation is enabled. Since the IM483[PL/SM] controller does not have
this capability, support for a command line "record separator" character was
added. The record separator is defined as an ASCII (IS2) character = /x1E.
Currently, only one record separator is allowed in a command line.

Errors introduced in V4.0

Unfortunately, several errors were introduced into the motor record with V4.0.
The following have been fixed:

If the "ncards" argument of the omsSetup() function in st.cmd file was not
accurate (i.e., did not match the actual number of OMS VME8/44 boards in the VME
crate); the "dbior" command could result in erroneous information or a bus error.

Jog request would not work after the state of the UEIP field was changd.

Backlash correction was not occurring after a JOG.

The motor record would 'hang' in the moving state on the rare occasion when a
target position (i.e., VAL or DVAL) fell almost exactly half way between two
integer RVAL values, and the retry feature was enabled (i.e., RTRY is nonzero)

New Features

Newport PM500 device support

Device driver support for the Newport PM500 is available for this release of the
motor record. This device/driver is based on Mark River's PM500 V2.0
release.

Intelligent Motion Systems, Inc. IM483 device support

Device driver support for Intelligent Motion Systems (IMS) IM483[I/IE] is
available with this release. Two different device/drivers are available
for the same motor controller. The two device/drivers, IM483PL and
IM483SM, correspond to the two available IM483 communication modes, party
line and single mode, respectively (see the IMS Software Reference
Manual for details).

Motor Record Version 4.1 Release Notice

Although the motor record software in this release is compatible with EPICS
baseR3.13.1.1 and above, the directory structure, the "make" files and the
configuration files are intended for the "unbundled" architecture of EPICS R3.13.2
and above.

Modifications to Existing Features

OMS VME58 retry problem

Several errors in the OMS VME58
driver were found. All the errors caused the same problem. Namely,
erroneous retries occurred intermittently when multiple axes were commanded to
move on the same controller. This error occurred because old position data
was being passed back from the driver after Done was detected. The
erroneous intermittent retries occurred more often when the Oms setup parameters
called for a high frequency (e.g., 60 Hz) "polling" rate and OMS board
interrupts were enabled.

OMS Stop problem

A problem with
issuing a stop command (via either the STOP or SPMG field) was found with all
OMS boards and all versions of the OMS device drivers. The root
cause of this problem is a statement in the OMS manual that is not entirely
correct; the AC and VL commands are not completely queued.

Motor Record Version 4.0 Release Notice

Release 4.0 of the motor record is only compatible with EPICS baseR3.13.1.1
and above. This document describes changes made to the motor record and
its' associated device driver support between versions 3.5 and 4.0.

Modifications to Existing Features

GAIN Field Removed

Since the GAIN field is redundant (i.e.,
PID parameters can be set individually) it has been removed.

HOM[F/R] Bug Fix

Previous releases of the motor
record had a potential problem associated with the homing function. The
motorx_all.adl V1.9 MEDM display sets the HOM[F/R] fields on and off,
corresponding to the user pressing and releasing the respective home button.
Depending on the pollRate defined in the st.cmd Setup command and
the speed at which the user toggled the HOM[F/R] buttons; the record level
software would turn off the DMOV field when the HOM[F/R] button was turned off
and a motor status update had not yet been received. As a result, when the
motor completed it's homing function the command positions (i.e., VAL, DVAL,
RVAL) were not updated.

All previous motor record releases contained the DMOV problem; the commanded
position update problem was limited to the previous release (V3.5). With
this release, a dbPutField to either HOMF or HOMR is valid on a FALSE to TRUE
transition (i.e., 0 to 1), but a TRUE to FALSE transition (i.e., 1 to 0) will
result in an error. motorx_all.adl_V2.2 (which is included
with this distribution) sets the HOM[F/R] fields on when the user presses the
homing button, but is does not set it off when the button is released.
The motor record clears the HOM[F/R] field when the homing operation is done (i.e.,
completed or terminated).

Initial Position

If both the auto restore and controller target
position values are non-zero at boot-up, then DVAL will be initialized from the
controller's value. In other words, the controller's target position takes
precedence over the autorestore value when both systems have non-zero DVAL
values. As before, it is assumed that a zero target position from
autorestore or the controller at boot-up are default values, and hence, they are
ignored in favor of a non-zero value.

Previous releases of the motor record allowed the auto restore to take
precedence over the controller when initializing the target position (i.e., DVAL).

Access Security Level

In order to support the new VMAX/SMAX
fields, the Access Security Level for the following fields have been changed
from one to zero:

MRES

UREV

VBAS

SBAS

MM4000/5 Device Driver

Although the previous motor record
release (V3.5) had device driver support for the MM4000, it is not
recommended for use with either the MM4000 or the MM4005 controllers. The
following changes were made to the previous release to create, what is now, the
MM4000/5 device driver support:

The MM4000 device driver software supports both the MM4000 and MM4005
controllers. Driver level software detects and saves which controller it
is communicating with at boot-up. Currently, there are two functional
differences between the two models.

The MM4005's position cannot be set by a host. This mean that, for the
MM4005 only, setting the motor record RVAL or DVAL fields has no effect.

Since the MM4005's position cannot be set by EPICS, the initial position of its'
motors (see Initial Position above) will always be initialized from the
controller's value.

The MM4005 supports up to eight axes. User access to the controller's
front panel is required to scroll the front panel display through all eight axes.
Since remote mode locks out the user from using the controller's front
panel, the motor record no longer puts the MM4000/5 in remote mode .
EPICS is unable to communicate with the MM4000/5 controller if it is in localmode and the front panel is not at the top menu. A Controller
communication error bit was allocated in the MSTA field to help aid user's
in diagnosing a controller communication error. Currently, only the MM4000/5
device driver sets this error indicator. When the communication error bit
is set True in the MSTA, the motor record SEVR field is set to INVALID_ALARM and
the STAT field is set to COMM_ALARM. User's who want their MM4000/5 in
remote mode at boot-up can add the remote mode command ("MR") to their
INIT field.

Bug Fix for OMS VME58 running on PowerPC

Through an odd set of
circumstances the Oms58 driver was not performing status updates on PowerPC (PPC)
platforms. All users of the OMS VME58 controller on a PPC platform must
upgrade to Motor Record version 4.0 for full functionality.

New Features

Newport MM3000 Device Support

Device driver support for the MM3000 exist for this release of the motor record.
Note the following differences between the MM4000 and MM3000 device drivers:

The MM3000 does not support a generic Load Position commands. In
other words, the user can only define the current controller position as being
the zero position. This limitation is reflected in the motor record device
support. When the SET field is true, the only valid entry to either the
DVAL or RVAL fields is zero.

The only position units the MM3000 will communicate with the host in, are either
encoder ticks or stepper motor steps.

Uninitialized Oms/Oms58 Driver Error Check

With previous release,
if the Oms or Oms58 driver was some how omitted from the database, a "... card
does not exist" error message would result. With this release, an explicit
error check and corresponding error message (i.e., "Oms[58] driver uninitialized.
") is issued at record initialization if a required driver is not initialized. (Because
of the particulars of MM[3000/4000] initialization, this is not an issue with
Newport controllers.)

Maximum Velocity Fields (VMAX/SMAX)

Maximum velocity fields have been added; VMAX in EGU/s units and SMAX in RPS
units.

In order to support BURT, range checking is done in such a way that any minimum
(i.e., VBAS/SBAS) or maximum (i.e., VMAX/SMAX) value entered is valid.
For example, if the minimum is entered and it exceeds the maximum, then the
maximum is set to the new minimum value. Slew (VELO/S) and backup
velocity (BVEL/SBAK) fields are forced by the motor record to be within the
range set by VMAX/SMAX and VBAS/SBAS, inclusively. For example, if VELO is
entered and it is less than the minimum, then VELO is set to VBAS.

To facilitate software upgrades, a zero VMAX disables maximum velocity error
checking. Those who use both BURT and VMAX (i.e., nonzero VMAX) should
insure that VMAX and VBAS are placed before VELO and BVEL in their BURT request
files. VMAX/SMAX have Access Security Level zero.

motorx_setup_1.7.adl (which is included with this distribution) includes
support for the maximum velocity fields.

Motor Record Version 3.5 Release Notice

Release 3.5 of the motor record is only compatible with EPICS baseR3.13.1.1 and
above. This document describes changes made to the motor record and its'
associated device driver support between versions 3.4 and 3.5. Those
changes are as follows:

Modifications to Existing Features

Command Primitives

This feature is available only with OMS
VME8/44/58 or Newport MM4000 device support (i.e., devOms, devOms58, devMM4000).
Three motor record fields are available to the user to send ASCII command
primitives to the servo control board at fixed, predefined, times. Each of
the following fields is defined as a character string:

1. INIT - Sent at record initialization.
2. PREM - Sent before every command string that causes motion.
3. POST - Sent after a complete motion is finished or when an
overtravel limit switch is detected.

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.

Servo related Fields

The GAIN field "prompt" has been changed from "Response Gain" to "Combined Gain".
In addition, valid values for the GAIN field have been changed to [0.0, for
MM4000 - 0.00005, for OMS] <= GAIN <= 1. For more on PID, see "PID
Gain Parameters" below.

The status enable field (i.e., STEN) has been eliminated; the control
enable field (i.e., CNEN) is used to both control the torque enable and show
its' status.

New Features

Device Directives

One or more characters followed by a terminating '@'; i.e., device directives
must have nonzero length.

A valid device directive; currently, only "DPM_ON".

INIT strings are stripped of valid device directives (including @'s) and tested
for nonzero length before being sent to the controller. For example, given
the INIT string, "@DPM_ON@HE", the device directive @DPM_ON@ is stripped out
before HE is sent to the controller.

Driver Power Monitoring

This feature is only available with the OMS VME58 device support.

The 8 User I/O signals are assigned to the 8 possible VME58 axes as follows:

User I/O #0 <> X axis
" " 1 <> Y "
.....................
" " 7 <> S "

Drive-power monitoring defaults to disabled at boot-up. Request enabling
drive-power monitoring by entering the device directive "@DPM_ON@" command into
the motor record initialization field (i.e., INIT). The INIT field is
processed at record initialization (i.e., bootup), hence if there are no errors,
drive-power monitoring will be enabled after the next bootup.

Whenever a request is made to enable drive-power status monitoring, an error
check is made (using the VME58 "RB" command) to verify that the User I/O has
been configured as an input. The following message will appear in the
error log if a configuration error is detected; "Invalid VME58 configuration; RB
= 0x####", where "####" is the VME58's response to the RB command.

When drive-power status monitoring is enabled and a power failure is detected,
the device driver will respond by activating the the RA_OVERTRAVEL bit in the
MSTA. This results in either HLS or LLS being activated depending on the
DIR field. In addition, the following message will appear in the error log; "Drive
power failure at VME58 card#?? motor#??".

Soft Channel Device Support

The immediate goals for soft channel
motor record device support were twofold. First, to solve the problem of
nonlinear position conversion in the data base, rather than in the record.
Second, to provide a more flexible motor record interface for Table Records and
SPEC.

New fields have been added to the motor record to support the Soft Channel
device driver. The new fields are all database links associated with
existing motor record fields. The new links and their associated fields
are listed in the table below:

Link

Link Type

Associated Field

OUT*

DBOUTPUT

DVAL

STOO

DBOUTPUT

STOP

DINP

DBINPUT

DMOV

RDBL*

DBINPUT

DRBV

RINP

DBINPUT

RMP

* - Not a new field, but a new function provided only by soft channel device
support.

The Soft Channel database links are only processed when the Soft Channel device
driver is selected. These links are ignored when using any other Motor
Record device driver. At this time, the above links are not
dynamically retargetable.

The OUT, DINP and RDBL are monitored for value changes via a CA event task.
Users must choose either a dial input link (RDBL) or a raw input link (RINP),
but not both.

Newport MM4000 Device Support

This is Mark
Rivers MM4000 device support ported to the latest motor record release.
The following are the functional differences between Mark's version 1.01 and
this release:

When either user or dial travel limit values are entered, a validity check is
made using the travel limit values from the MM4000 control. User and dial
travel limit values are valid if they are within the travel limits set on the
front panel of the MM4000 controller. Attempting to enter a travel limit
outside the MM4000 controller's range results in the travel limit being reset to
the MM4000's value.

Servo support has been extended to the MM4000 controller.

PID Gain Parameters

With this release there are two ways to set
the motor controllers' PID parameters; either through the Combined Gain field
(i.e., GAIN) or through the individual PID gain parameter fields (i.e., PCOF,
ICOF, DCOF). Let the motor controller PID parameters be represented by CKP,
CKI and CKD; then the relationship between these two methods is as follows:

For the MM4000For all OMS
controllers

CKP = GAIN
CKP = 1999.9 * GAIN

CKI = 2 * GAIN
CKI = 2 * 1999.9 * GAIN

CKD = 3 * GAIN
CKD = 3 * 1999.9 * GAIN

Note that setting any of the individual PID record fields is notreflected
in the value of the GAIN field.

Highland V544 Device Support

Device support for the Highland V544 is available with this release. This
version (i.e., version 1.3) is functionally the same as the earlier release (i.e.,
version 1.2). No new features have been added.

Motor Record Version 3.4 Release Notice

This document describes changes made to the motor record and its' associated
device driver support between versions 3.3 and 3.4. Those changes are as
follows:

Device driver design error fix

A
design error was discovered in the OMS device drivers (drvOms and drvOms58).
The EPICS device driver support task (i.e., tmotor) would query the OMS motion
controller for status information immediately after a motion command.
Since the state of the controller board was in the midst of changing, this
sometimes resulted in inconsistent or conflicting status information being
returned to the motor record. This problem was remedied by enforcing a
minimum time delay (16.67 ms) between a motion command and a status query.

It is difficult to enumerate the symptoms associated with this problem.
Sometimes they exhibited themselves intermittently, other times bad data stayed
in the record. Several symptoms are as follows:

Erroneous motor stops being issued by the device support when changing motor
direction.

Backlash occurring when the motor is moving in the same direction as the sign of
BDST.

DVAL and RBV becoming out-of-synch. RBV would always be an old value from
the previous move.

PID Parameter Support for VME58

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:

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 (with the OMS VME58, gain changes do
not take effect until the command velocity is zero).

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.

Command primitives feature

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. PREM - 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.