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