From 1582388ceda02971844774ec59aeb56b516d5ae3 Mon Sep 17 00:00:00 2001 From: Ron Sluiter Date: Thu, 12 Jun 2003 22:00:05 +0000 Subject: [PATCH] R5.1 --- documentation/motor_release.html | 235 +++++++++++++++++++++++++++++-- 1 file changed, 220 insertions(+), 15 deletions(-) diff --git a/documentation/motor_release.html b/documentation/motor_release.html index daa541de..bfb1663e 100644 --- a/documentation/motor_release.html +++ b/documentation/motor_release.html @@ -1,6 +1,4 @@ - - - + @@ -8,13 +6,216 @@ - - EPICS Motor Record Release Notice - - + EPICS Motor Record Release Notice + +
-

Motor Record Version 4.5 Release Notice

+
+

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;
+
  1. motion is in progress (i.e., DMOV is false).
  2. the new target position is different from the actual position by less +than the retry deadband (|DIFF| < RDBD).
  3. 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 @@ -33,8 +234,8 @@ using GPIB or RS232 serial communication mechanisms (i.e., non-VME Bus boards).

-

Requirements Clarification

- +

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:
@@ -618,11 +819,16 @@ the relationship between these two methods is as follows: For all OMS controllers @@ -711,5 +917,4 @@ primitives that result in a response from the motion control board are valid, but the response is not processed.
 
 

- - +