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 statment 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 local mode 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.

Unused Fields Removed

The following unused motor record fields were deleted: MODE, TRAK, MDEL, ADEL, CVEL, POSM, ALST, MLST

New Features

Device Directives

Device directive definition and processing:

Valid only in the INIT field.
Must be identified by the following;

First character of INIT string must be a '@'.

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:

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 MM4000 For 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 not reflected 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:

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