From 22ab36caa3af80ea1ad224bfc3ab4598e968749a Mon Sep 17 00:00:00 2001 From: MarkRivers Date: Wed, 14 Apr 2010 18:06:40 +0000 Subject: [PATCH] Converted to XHTML 1.1 Strict and validated --- documentation/motor_release.html | 4203 ++++++++++++++---------------- 1 file changed, 2009 insertions(+), 2194 deletions(-) diff --git a/documentation/motor_release.html b/documentation/motor_release.html index 058224ab..c5e23ad4 100644 --- a/documentation/motor_release.html +++ b/documentation/motor_release.html @@ -1,2212 +1,2027 @@ - - + + - - - - + + EPICS Motor Record Release R6-5 Notice - - + + + - - -
-

Motor Record Version 6-5 Release Notice

-
- -
-

Modifications to Existing Features

-
- -
-

- 64-bit compatiablity -

-

- 64-bit compile problems with the PI E816 and Aerotech Ensemble device drivers - were fixed. Mark Rivers made numerous changes to eliminate all 64-bit compiler - warning messages. -

- OMS MAXv -

- Dirk Zimoch (PSI) fixed a bug in the OMS MAXv driver that caused the set_status() - function to overwrite the home switch status in the response string -

- asyn motor -

- - Highland Technologies -

-

- Support for the Highland Technologies V540 motor controller has been removed. -

- Aerotech Ensemble -

- -
- -
-

New Features

-
- -
-

- Aerotech Soloist and Ensemble asyn motor support -

-

- Added two new drivers from Aerotech; the Soloist controller and an asyn motor - version of the Ensemble. Since the Ensemble network connection requires period - communication from the host to prevent the Ensemble from closing the network - socket, the Ensemble support based on the old device driver architecture will be - removed after R5-6. The asyn motor architecture supports continuous, periodic - updates; the old architecture does not. -

-
- -
- - -
-

Motor Record Version 6-4 Release Notice

-
- -
-

Modifications to Existing Features

-
- -
-

- Stale SET position data from OMS VME58 controllers. -

-

- A problem with certain OMS VME58 firmware versions (2.24-8S and all 2.35 - versions) has arisen since modifications made under R6-3. When the user sets - the motor record's position, the previous target and readback positions are read - from the controller on the next update. This occurs with the previous release (R6-3) - because the "stale data delay" was changed from 10ms to zero for the drvOms58 - driver. -

-

- With this release the driver searches all VME58 board ID's for either 2.24-8S or - any 2.35 version. If any board is found with these versions, the "stale data - delay" is set to a non-zero value for all VME58 boards in the system. -

-

- "tdir=" error messages -

-

- A problem was reported by Emma Shepherd (Diamond) with the previous release if - the "Use RDBL Link" field (URIP) was set to "Yes". The NTM logic was sending - stop commands and issuing the "tdir=.." message to the console if the RDBL link - was used. This error was the result of changes to the NTM logic in R6-3. -

-

- With this release, the NTM logic is restored to using feedback rather than - reference positions. In addition, an "NTM deadband factor" field (NTMF) is - added to allow the user to set the NTM deadband as follows; -

-

- NTM deadband = NTMF * (|BDST| + RDBD) -

-

- NTMF must be >= 2. If properly configured, the NTM deadband prevents NTM - logic from issuing a STOP command at the end of a DC motor move that overshoots - its' target position. -

- -

- Access Security Level changes -

- -

- Major changes have been made to the Access Security Level (ASL) attribute of the - motor record fields. With previous releases, the following fields were set to - ASL=0; FOF, VOF, SSET, SUSE, VBAS, VMAX, SBAS, SMAX, UREV and MRES. All other - fields were set to ASL=1 by default. -

-

- With this release, the policy is to set all the fields that the user requires to - do the following to ASL = 0; -

-

-

- All other fields are set to ASL = 1. -

-

- This means that out of the list of fields that were previously set to ASL=0; - VBAS, VMAX, SBAS, SMAX, UREV and MRES are now set to ASL=1. -

- -

- OMS MAXv A24/A32 VMEbus addressing bug fix -

-

- Previous releases had a problem with the OMS MAXv device driver when it was - configured for more than one board, and, either A24 or A32 addressing was - specified. The driver was not sizing the address space occupied by each MAXv - correctly. -

- -

- asyn motor archtecture updates -

-

-

  • - Motor record GET_INFO commands were not supported by the asyn motor archtecture - in previous releases. -
    • -
  • - A motor record bug was fixed that caused unscheduled retries to occur with asyn - motor. -
    • -

    - -
    - -
    -

    New Features

    -
    - -
    -

    - Deferred moves for asyn motors -

    -

    - The asyn motor framework now supports a flag to indicate that moves should be - deferred. When at zero, moves proceed as normal. When set to one, moves - should be deferred and remembered by the controller driver, but not executed - immediately. When set back to zero, the controller driver should then start - all the moves (or at least moves to the last requested demand positions) that - have been deferred, as near to simultaneously as is possible for the - particular model of controller. The flag is implemented per-controller, so - all axes on a particular controller instance are affected, but axes on other - controllers via the same driver are unaffected. -

    -

    - It is the responsibility of the motor controller driver to actually provide - such functionality, or to give an error if the parameter is not recognised. - Currently the Newport XPS controller driver and the Delta Tau PMAC driver - (in the tpmac module available from Diamond) support this. -

    -

    - To use the flag, connect to any asyn port/addr combination on the controller, - using the parameter "DEFER". e.g. for a bo record, use DTYP=asynUInt32Digital, - OUT=@asynMask(port,1,1)DEFER, ZNAM="Go", ONAM="Defer" -

    -

    - 64-bit compatiablity -

    -

    - Previous releases of the motor record distribution would not compile for 64-bit - platforms. Numerous minor modifications were made for this release to attain 64-bit - compatibility. Note that at the time of writing (03/14/08), this release was - successfully compiled on a Linux Fedora Core 6 x86_64 host using gcc version - 4.1.2, but there are bugs. Since EPICS base (R3.14.9) has not had all the bugs - wrung out (Mantis ID's #309, #310), there are no immediate plans to debug 64-bit - related problems. -

    - - attocube systems AG ANC150 -

    -

    - Ron Sluiter added support for the attocube systems AG ANC150 Piezo Step - Controller. -

    - - Aerotech's Ensemble -

    -

    - Chad Weimer (Aerotech) added support for Aerotech's Ensemble family of digital - servo controllers. -

    - - Physik Instrumente GmbH & Co. Model E-816 -

    -

    - John Hammonds added support of the Physik Instrumente (PI) GmbH & Co. E-816 - motor controller. -

    -
    - -
    - -
    -

    Motor Record Version 6.3 Release Notice

    -
    - -
    -

    Modifications to Existing Features

    -
    - -
    -

    - save/restore of motor positions -

    -

    - Mark Rivers found and fixed a bug in the motor record that resulted in motor - positions not being initialized from save/restore at boot-up if the retry - deadband field (RDBD) was not included in a save set. -

    -

    - motorUtil error message -

    -

    - A bug was introduced into the shell command "motorUtilInit()" affecting these - versions of the motor distribution; R6-2, R6-2-1 and R6-2-2. This bug resulted - in the erroneous error message; "motorUtilInit: Prefix %c: has more than 53 - characters. Exiting" -

    -

    - DC motor support -

    -

    - Two changes were made to the motor record to better support DC motors. -

    -

    - Examples renamed -

    -

    - The examples iocNoMPF and iocWithMPF were renamed iocNoAsyn and iocWithAsyn, - respectively. -

    -
    - - -
    -

    New Features

    -
    - -
    -

    - Animatics Corporation SmartMotor -

    -

    - Shifu Xu's support for the Animatics Corporation SmartMotor was added. -

    -

    - piezosystem jena, Inc. EDS -

    -

    - Joe Sullivan added support for the piezosystem jena GmbH EDS data interface module. -

    - Kohzu SC-800 -

    -

    - Ron Sluiter added support for the Kohzu SC-800 stepper motor controller. -

    -
    - - -
    -

    Motor Record Version 6.2 Release Notice

    -
    - -
    -

    Modifications to Existing Features

    -
    - -
    -

    - Newport PM500 Initialization Problem -

    -

    - The PM500 driver was not issuing the correct command when it queried for the - number of axes at boot up. This resulted in a "PM500 system error" message on - the 1st axis. -

    -

    - Overwritten PID Parameters -

    -

    - A bug was introduced with R6-0; the OMS device support was overwriting PID - parameter fields during its' normalization calculation. -

    -

    - Motor Position Initialization -

    -

    - There was a bug in the logic that determines the precedence between using the - controller's or save/restore's motor position at boot-up. Negative controller - positions were not handled correctly. -

    - Newport Build Problem -

    -

    - Due to releasing R6-1 during Newport development, R6-1 can result in linker - errors on the symbol "xpsgathering". Newport users should upgrade to R6-2. -

    -
    - - -
    -

    New Features

    -
    - -
    -

    - Thorlabs model MDT695 -

    -

    - Joe Sullivan added support for Thorlabs Piezo Control Module, model MDT695. -

    -
    - - -
    -

    Motor Record Version 6.1 Release Notice

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

    Modifications to Existing Features

    -
    - -
    -

    - PI C-862 communiation errors -

    -

    - A 17ms "status update delay" was added to the driver to prevent the controller - from dropping communication characters. This problem resulted in erroneous - error responses from the controller. -

    -

    - motorStatus[xx].adl displays -

    -

    - All motorStatus[xx].adl displays were modified to show motor position with text - rather than with bar graphs. -

    -
    - - -
    -

    New Features

    -
    - -
    -

    - Physik Instrumente GmbH & Co. Model E-710 -

    -

    - Joe Sullivan added support for the Physik Instrumente (PI) GmbH & Co. Model E-710 - motor controller. -

    -
    - - -
    -

    Motor Record Version 6.0 Release Notice

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

    Modifications to Existing Features

    -
    - -
    -

    - OMS MAXv Polling Rate -

    -

    - The OMS MAXv polling rate, which is set from the MAXvSetup() st.cmd command, is - allowed to be as high as the OS clock rate; i.e., (1/epicsThreadSleepQuantum()). -

    -

    - Changes to New Focus Device Support -

    -

    - The New Focus Model 8750 Network Controller device support ("PMNC8750") has been - changed to "PMNC87xx". It now supports both the 8750 and 8752 models. -

    -
    - - -
    -

    New Features

    -
    - -
    -

    - Physik Instrumente GmbH & Co. Model C-862 -

    -

    - Mohan Ramanathan and Ron Sluiter added support for the Physik Instrumente (PI) - GmbH & Co. Model C-862 motor controller. -

    - -

    - ACS Tech80 SPiiPlus -

    -

    - Joe Sullivan added support for the ACS Tech80 SPiiPlus motor controller. -

    - -

    - Spectra-Physics Encoder Mike -

    -

    - Joe Sullivan added support for the Spectra-Physics Encoder Mike Controller (Model: - 18011). -

    -
    - - -
    -

    Motor Record Version 5.9 Release Notice

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

    Modifications to Existing Features

    -
    - -
    -

    - Soft Motor allocation limit -

    -

    - Peter Denison (Diamond Light Source) enhanced the Soft Channel device support by - eliminating the 50 soft motor limit and replacing it with an unlimited linked list. -

    -
    - - -
    -

    New Features

    -
    - -
    -

    - All motors done/stop/moving utility -

    -

    - Kevin Peterson's (UNI-CAT) motorUtil task was added to the motor record - distribution. The motorUtil task monitors and maintains 3 PV's; $(P)alldone, $(P)allstop, - $(P)moving. motorUtil is a replacement for the all_com_##.db distributed with - the STD support module. See the motorUtil.db file for details. -

    - -

    - Asyn Motor -

    -

    - Peter Denison (Diamond), Nick Rees (Diamond) and Mark Rivers (APS) have added a - new motor record device support architecture based on ASYN; called "asyn motor" - support. The asyn motor support is an attempt to define a clean, extensible - API for motor controller drivers to support. This is a preliminary release - of work in progress. Do not use asynMotor device support at this time, except - for development and testing purposes only. -

    - -

    - New Focus 8750 Network Controller -

    -

    - Joe Sullivan added support for the New Focus Model 8750 Network Controller. -

    - -

    - Physik Instrumente (PI) E-662 piezo controller -

    -

    - Joe Sullivan added support for the Physik Instrumente (PI) GmbH & Co. Model E-662 - piezo controller. -

    - -

    - Newport XPS-C8 asyn motor support -

    -

    - Mark Rivers added asyn motor support for the Newport XPS-C8 motor controller. - This is a preliminary release of work in progress. However, it has fewer - problems than the previous XPS support, so we recommend using the new asyn - support for the XPS, with the understanding that it is still under development. -

    - -

    - Trajectory Scanning -

    -

    - Mark Rivers added the Trajectory Scanning software for both the Newport MM4005 - and XPS-C8 motor controllers to the motor record distribution. -

    - -

    - OMS PC68 and PC78 support -

    -

    - Brian Tieman and Ron Sluiter added support for the standalone, RS-232 versions - of the OMS PC68 and PC78 model controllers. The same device driver (OMS PC68/78) - supports both models. -

    -
    - - -
    -

    Motor Record Version 5.8 Release Notice

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

    New Features

    -
    - -
    -

    - Faulhaber MCDC2805 -

    -

    - Mark Rivers added support for the Faulhaber MCDC2805 servo controller. -

    - -

    - Parker Hannifin, Compumotor Division, 6K Series -

    -

    - Joe Sullivan added support for Parker Hannifin, Compumotor Division, 6K Series - controllers. -

    -
    - - -
    -

    Motor Record Version 5.7 Release Notice

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

    Modifications to Existing Features

    -
    - -
    - Initial Position -

    - With this release, if the absolute values of both the save/restore's target - position and the controller's commanded position are greater than the re-try - deadband (RDBD) at boot-up, then DVAL will be initialized from the controller's - value. In other words, if the absolute value of the controller's commanded - position is greater than the re-try deadband at boot-up, than the controller's - position takes precedence over the save/restore value. -

    -
    - -
    -

    New Features

    -
    - -
    -

    - Physik Instrumente (PI) C-630 -

    -

    - Kurt Goetze added support for the Physik Instrumente (PI) model C-630 motion - controller. -

    - -

    - Physik Instrumente (PI) C-848 -

    -

    - Support added for the Physik Instrumente (PI) C-848 motor controller. -

    -
    - - -
    -

    Motor Record Version 5.6 Release Notice

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

    Modifications to Existing Features

    -
    - -
    - IMS MDrive Configuration -

    - IMS MDrive users must make the following configuration changes to their MDrive's - as described in the distribution document "motorR5-6/motorApp/ImsSrc/README". -

    -

    -
    - - -
    -

    Motor Record Version 5.5 Release Notice

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

    Modifications to Existing Features

    -
    - - -
    - Conversion to ASYN -

    - The motor record distribution has been converted from MPF to ASYN R4.1. All - support for MPF has been removed. -

    -
    - -
    - Acceleration Correction -

    - Slew acceleration calculations were incorrect. Instead of the correct - calculation; A = (Vf - Vo) / t, the record was using A = Vf / t, which is - correct only if Vo (VBAS) is zero. Thanks to Harvey Rarback for pointing out - this long standing error. -

    -
    - - -
    -

    Motor Record Version 5.4 Release Notice

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

    Modifications to Existing Features

    -
    - -
    - Status Updates -

    - If the motor record is processed and there are no functions to perform (i.e., no - current or outstanding move request), then the motor record will perform a status - update using the STUP field. -

    -
    - -
    -

    New Features

    -
    - -
    -

    - OMS MAXv device support -

    - Device support for Oregon Micro Systems, Inc. MAXv controller was added. -

    -

    - -

    - Delta Tau PMAC -

    -

    - Device support for Delta Tau's PMAC2-VME controller was added. -

    -
    - - -
    -

    Motor Record Version 5.3 Release Notice

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

    Modifications to Existing Features

    -
    - -
    - OMS VME58 Servo Limit Switch Problem -

    - The motor record would lock-up when a user tried to move off an activated limit - switch with the OMS VME58 servo motor controller board (i.e., model -8S). - Although this problem has been resolved there is a design problem with the OMS - VME58 servo controller that prevents it, in most cases, from moving off an - activated limit switch. Users are advised to avoid this situation -

    - - Encoder Resolution (ERES) Polarity -

    - Previous releases of the motor record forced the sign of ERES to match the sign - of MRES. With this release, ERES and MRES may have different signs. This - allows the user to change the sign of ERES rather than reverse encoder wires - when the motor and encoder direction are reversed. Warning! This does - not work with controllers that are doing closed-loop control; e.g., DC motors. - Reference (D/A) and feedback (encoder) signals must have the same polarity for - DC motors or the motor will literally run away. -

    - -

    - PID parameter initialization -

    -

    - PID parameters (i.e., PCOF, ICOF and DCOF fields) were not initialized at boot-up. - With this release, if the GAIN_SUPPORT bit in the MSTA is true, each nonzero, - PID parameter will be initialized. For backwards compatibility, zero valued PID - parameters will not be initialized. -

    - -

    - IMS MDrive Device Driver -

    -

    - Previous releases of the IMS MDrive device driver did not work. Thanks to Kevin - M. Peterson (UNI-CAT) for identifying and fixing the errors in previous releases. - A README file has been added to the ImsSrc directory that documents how the - MDrive must be initialized before using it with this device driver. -

    -

    - - Three Device Drivers New To R3.14.x -

    -

    - The following three device drivers have been ported from the R3.13.x compatible - version of the motor record: -

    -

    -
    - -
    -

    New Features

    -
    - -
    -

    - Status Update (STUP) -

    -

    - The STUP field (Status Update) has been modified due to bug fixes. The STUP - field functions as follows; -

    -

    -

    - With the STUP field it is possible to have another EPICS record periodically - write ON(1) to the motor record's STUP field. This would result in continuous, - periodic status updates. -

    -
    - -
    -

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

    - -

    - OMS VX2-006 Spurious Interrupts -

    -

    - Spurious interrupts were occurring with OMS VX2-006 ver 1.04 controller boards. - For the sake of throughput, the OMS VME8/44 device driver enables the done (DON_E) - and input buffer full (IBF_E) interrupts, but disables the transmit buffer empty - (TBE_E). -

    -

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

    + Motor Record Version 6-5 Release Notice

    +
    +
    +

    + Modifications to Existing Features

    +
    +

    - New Features + 64-bit compatability

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

    + 64-bit compile problems with the PI E816 and Aerotech Ensemble device drivers were + fixed. Mark Rivers made numerous changes to eliminate all 64-bit compiler warning + messages. +

    + OMS MAXv +

    + Dirk Zimoch (PSI) fixed a bug in the OMS MAXv driver that caused the set_status() + function to overwrite the home switch status in the response string +

    +

    + asyn motor +

    +
      +
    • Matthew Pearson (Diamond) fixed a bug on Newport XPS and MM4000 asyn motor port + drives that was causing idle polling to interfere with setting positions and prevented + auto save/restore from working.
      • +
    • The asynMotor device support would leave a motor-in-motion indicator on if the + motor record issued a LOAD_POS command before the 2nd pass of device support initialization. +
      • +
    +

    + Highland Technologies +

    +

    + Support for the Highland Technologies V540 motor controller has been removed. +

    +

    + Aerotech Ensemble +

    +
      +
    • Aerotech Ensemble device driver fixes for incorrect Jog speeds, support for a + negative PosScaleFactor parameter and detecting maximum travel limit switch faults. +
      • +
    • This is the latest release to include the old Ensemble device driver architecture + version. See below.
      • +
    +
    +
    +

    + New Features

    +
    +
    +

    + Aerotech Soloist and Ensemble asyn motor support +

    +

    + Added two new drivers from Aerotech; the Soloist controller and an asyn motor version + of the Ensemble. Since the Ensemble network connection requires period communication + from the host to prevent the Ensemble from closing the network socket, the Ensemble + support based on the old device driver architecture will be removed after R5-6. + The asyn motor architecture supports continuous, periodic updates; the old architecture + does not. +

    +
    +

    +

    +
    +

    + Motor Record Version 6-4 Release Notice

    +
    +
    +

    + Modifications to Existing Features

    +
    +
    +

    + Stale SET position data from OMS VME58 controllers. +

    +

    + A problem with certain OMS VME58 firmware versions (2.24-8S and all 2.35 versions) + has arisen since modifications made under R6-3. When the user sets the motor record's + position, the previous target and readback positions are read from the controller + on the next update. This occurs with the previous release (R6-3) because the "stale + data delay" was changed from 10ms to zero for the drvOms58 driver. +

    +

    + With this release the driver searches all VME58 board ID's for either 2.24-8S or + any 2.35 version. If any board is found with these versions, the "stale data delay" + is set to a non-zero value for all VME58 boards in the system. +

    +

    + "tdir=" error messages +

    +

    + A problem was reported by Emma Shepherd (Diamond) with the previous release if the + "Use RDBL Link" field (URIP) was set to "Yes". The NTM logic was sending stop commands + and issuing the "tdir=.." message to the console if the RDBL link was used. This + error was the result of changes to the NTM logic in R6-3. +

    +

    + With this release, the NTM logic is restored to using feedback rather than reference + positions. In addition, an "NTM deadband factor" field (NTMF) is added to allow + the user to set the NTM deadband as follows; +

    +

    + NTM deadband = NTMF * (|BDST| + RDBD) +

    +

    + NTMF must be >= 2. If properly configured, the NTM deadband prevents NTM logic from + issuing a STOP command at the end of a DC motor move that overshoots its' target + position. +

    +

    + Access Security Level changes +

    +

    + Major changes have been made to the Access Security Level (ASL) attribute of the + motor record fields. With previous releases, the following fields were set to ASL=0; + FOF, VOF, SSET, SUSE, VBAS, VMAX, SBAS, SMAX, UREV and MRES. All other fields were + set to ASL=1 by default. +

    +

    + With this release, the policy is to set all the fields that the user requires to + do the following to ASL = 0;

    +
      +
    • move a motor; (VAL, DVAL, RVAL, TWF, TWR, TWV, RLV, JOGF, JOGR)
      • +
    • stop a motor; (STOP, SPMG)
      • +
    • enable/disable motor torque; (CNEN)
      • +
    • set the position of a motor; (SSET, SUSE, SET)
      • +
    • set the "user" offset of a motor; (FOF, VOF, FOFF,OFF)
      • +
    • update the status of a motor; (STUP)
      • +
    • adjust or turn off backlash; (BDST)
      • +
    +

    + All other fields are set to ASL = 1. +

    +

    + This means that out of the list of fields that were previously set to ASL=0; VBAS, + VMAX, SBAS, SMAX, UREV and MRES are now set to ASL=1. +

    +

    + OMS MAXv A24/A32 VMEbus addressing bug fix +

    +

    + Previous releases had a problem with the OMS MAXv device driver when it was configured + for more than one board, and, either A24 or A32 addressing was specified. The driver + was not sizing the address space occupied by each MAXv correctly. +

    +

    + asyn motor archtecture updates +

    +
      +
    • Motor record GET_INFO commands were not supported by the asyn motor archtecture + in previous releases.
      • +
    • A motor record bug was fixed that caused unscheduled retries to occur with asyn + motor.
      • +
    +
    +
    +

    + New Features

    +
    +
    +

    + Deferred moves for asyn motors +

    +

    + The asyn motor framework now supports a flag to indicate that moves should be deferred. + When at zero, moves proceed as normal. When set to one, moves should be deferred + and remembered by the controller driver, but not executed immediately. When set + back to zero, the controller driver should then start all the moves (or at least + moves to the last requested demand positions) that have been deferred, as near to + simultaneously as is possible for the particular model of controller. The flag is + implemented per-controller, so all axes on a particular controller instance are + affected, but axes on other controllers via the same driver are unaffected. +

    +

    + It is the responsibility of the motor controller driver to actually provide such + functionality, or to give an error if the parameter is not recognised. Currently + the Newport XPS controller driver and the Delta Tau PMAC driver (in the tpmac module + available from Diamond) support this. +

    +

    + To use the flag, connect to any asyn port/addr combination on the controller, using + the parameter "DEFER". e.g. for a bo record, use DTYP=asynUInt32Digital, OUT=@asynMask(port,1,1)DEFER, + ZNAM="Go", ONAM="Defer" +

    +

    + 64-bit compatiablity +

    +

    + Previous releases of the motor record distribution would not compile for 64-bit + platforms. Numerous minor modifications were made for this release to attain 64-bit + compatibility. Note that at the time of writing (03/14/08), this release was successfully + compiled on a Linux Fedora Core 6 x86_64 host using gcc version 4.1.2, but there + are bugs. Since EPICS base (R3.14.9) has not had all the bugs wrung out (Mantis + ID's #309, #310), there are no immediate plans to debug 64-bit related problems. +

    +

    + attocube systems AG ANC150 +

    +

    + Ron Sluiter added support for the attocube systems AG ANC150 Piezo Step Controller. +

    +

    + Aerotech's Ensemble +

    +

    + Chad Weimer (Aerotech) added support for Aerotech's Ensemble family of digital servo + controllers. +

    +

    + Physik Instrumente GmbH & Co. Model E-816 +

    +

    + John Hammonds added support of the Physik Instrumente (PI) GmbH & Co. E-816 + motor controller. +

    +
    +

    +

    +
    +

    + Motor Record Version 6.3 Release Notice

    +
    +
    +

    + Modifications to Existing Features

    +
    +
    +

    + save/restore of motor positions +

    +

    + Mark Rivers found and fixed a bug in the motor record that resulted in motor positions + not being initialized from save/restore at boot-up if the retry deadband field (RDBD) + was not included in a save set. +

    +

    + motorUtil error message +

    +

    + A bug was introduced into the shell command "motorUtilInit()" affecting these versions + of the motor distribution; R6-2, R6-2-1 and R6-2-2. This bug resulted in the erroneous + error message; "motorUtilInit: Prefix %c: has more than 53 characters. Exiting" +

    +

    + DC motor support +

    +

    + Two changes were made to the motor record to better support DC motors.

    +
      +
    • With this release, if retries are disabled (RTRY=0), then all moves are done in + absolute mode. This allows a DC motor user to have the readback values calculated + based on either the local encoder (UEIP) or the readback link (URIP), but still + have all moves commanded in absolute mode. Previous releases the of the motor record + would use relative moves if either the local or external readbacks were enabled, + regardless of the state (enable/disable) of the retries.
      • +
    • The New Target Monitoring (NTM field) logic is changed to use reference rather + than feedback positions. This eliminates unwanted motor record STOP commands at + the end of DC motor moves.
      • +
    +

    + Examples renamed +

    +

    + The examples iocNoMPF and iocWithMPF were renamed iocNoAsyn and iocWithAsyn, respectively. +

    +
    +
    +

    + New Features

    +
    +
    +

    + Animatics Corporation SmartMotor +

    +

    + Shifu Xu's support for the Animatics Corporation SmartMotor was added. +

    +

    + piezosystem jena, Inc. EDS +

    +

    + Joe Sullivan added support for the piezosystem jena GmbH EDS data interface module. +

    +

    + Kohzu SC-800 +

    +

    + Ron Sluiter added support for the Kohzu SC-800 stepper motor controller. +

    +
    +
    +

    + Motor Record Version 6.2 Release Notice

    +
    +
    +

    + Modifications to Existing Features

    +
    +
    +

    + Newport PM500 Initialization Problem +

    +

    + The PM500 driver was not issuing the correct command when it queried for the number + of axes at boot up. This resulted in a "PM500 system error" message on the 1st axis. +

    +

    + Overwritten PID Parameters +

    +

    + A bug was introduced with R6-0; the OMS device support was overwriting PID parameter + fields during its' normalization calculation. +

    +

    + Motor Position Initialization +

    +

    + There was a bug in the logic that determines the precedence between using the controller's + or save/restore's motor position at boot-up. Negative controller positions were + not handled correctly. +

    +

    + Newport Build Problem +

    +

    + Due to releasing R6-1 during Newport development, R6-1 can result in linker errors + on the symbol "xpsgathering". Newport users should upgrade to R6-2. +

    +
    +
    +

    + New Features

    +
    +
    +

    + Thorlabs model MDT695 +

    +

    + Joe Sullivan added support for Thorlabs Piezo Control Module, model MDT695. +

    +
    +
    +

    + Motor Record Version 6.1 Release Notice

    +
    +

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

    +
    +

    + Modifications to Existing Features

    +
    +
    +

    + PI C-862 communiation errors +

    +

    + A 17ms "status update delay" was added to the driver to prevent the controller from + dropping communication characters. This problem resulted in erroneous error responses + from the controller. +

    +

    + motorStatus[xx].adl displays +

    +

    + All motorStatus[xx].adl displays were modified to show motor position with text + rather than with bar graphs. +

    +
    +
    +

    + New Features

    +
    +
    +

    + Physik Instrumente GmbH & Co. Model E-710 +

    +

    + Joe Sullivan added support for the Physik Instrumente (PI) GmbH & Co. Model + E-710 motor controller. +

    +
    +
    +

    + Motor Record Version 6.0 Release Notice

    +
    +

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

    +
    +

    + Modifications to Existing Features

    +
    +
    +

    + OMS MAXv Polling Rate +

    +

    + The OMS MAXv polling rate, which is set from the MAXvSetup() st.cmd command, is + allowed to be as high as the OS clock rate; i.e., (1/epicsThreadSleepQuantum()). +

    +

    + Changes to New Focus Device Support +

    +

    + The New Focus Model 8750 Network Controller device support ("PMNC8750") has been + changed to "PMNC87xx". It now supports both the 8750 and 8752 models. +

    +
    +
    +

    + New Features

    +
    +
    +

    + Physik Instrumente GmbH & Co. Model C-862 +

    +

    + Mohan Ramanathan and Ron Sluiter added support for the Physik Instrumente (PI) GmbH + & Co. Model C-862 motor controller. +

    +

    + ACS Tech80 SPiiPlus +

    +

    + Joe Sullivan added support for the ACS Tech80 SPiiPlus motor controller. +

    +

    + Spectra-Physics Encoder Mike +

    +

    + Joe Sullivan added support for the Spectra-Physics Encoder Mike Controller (Model: + 18011). +

    +
    +
    +

    + Motor Record Version 5.9 Release Notice

    +
    +

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

    +
    +

    + Modifications to Existing Features

    +
    +
    +

    + Soft Motor allocation limit +

    +

    + Peter Denison (Diamond Light Source) enhanced the Soft Channel device support by + eliminating the 50 soft motor limit and replacing it with an unlimited linked list. +

    +
    +
    +

    + New Features

    +
    +
    +

    + All motors done/stop/moving utility +

    +

    + Kevin Peterson's (UNI-CAT) motorUtil task was added to the motor record distribution. + The motorUtil task monitors and maintains 3 PV's; $(P)alldone, $(P)allstop, $(P)moving. + motorUtil is a replacement for the all_com_##.db distributed with the STD support + module. See the motorUtil.db file for details. +

    +

    + Asyn Motor +

    +

    + Peter Denison (Diamond), Nick Rees (Diamond) and Mark Rivers (APS) have added a + new motor record device support architecture based on ASYN; called "asyn motor" + support. The asyn motor support is an attempt to define a clean, extensible API + for motor controller drivers to support. This is a preliminary release of + work in progress. Do not use asynMotor device support at this time, except + for development and testing purposes only. +

    +

    + New Focus 8750 Network Controller +

    +

    + Joe Sullivan added support for the New Focus Model 8750 Network Controller. +

    +

    + Physik Instrumente (PI) E-662 piezo controller +

    +

    + Joe Sullivan added support for the Physik Instrumente (PI) GmbH & Co. Model + E-662 piezo controller. +

    +

    + Newport XPS-C8 asyn motor support +

    +

    + Mark Rivers added asyn motor support for the Newport XPS-C8 motor controller. This + is a preliminary release of work in progress. However, it has fewer problems than + the previous XPS support, so we recommend using the new asyn support for the XPS, + with the understanding that it is still under development. +

    +

    + Trajectory Scanning +

    +

    + Mark Rivers added the Trajectory Scanning software for both the Newport MM4005 and + XPS-C8 motor controllers to the motor record distribution. +

    +

    + OMS PC68 and PC78 support +

    +

    + Brian Tieman and Ron Sluiter added support for the standalone, RS-232 versions of + the OMS PC68 and PC78 model controllers. The same device driver (OMS PC68/78) supports + both models. +

    +
    +
    +

    + Motor Record Version 5.8 Release Notice

    +
    +

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

    +
    +

    + New Features

    +
    +
    +

    + Faulhaber MCDC2805 +

    +

    + Mark Rivers added support for the Faulhaber MCDC2805 servo controller. +

    +

    + Parker Hannifin, Compumotor Division, 6K Series +

    +

    + Joe Sullivan added support for Parker Hannifin, Compumotor Division, 6K Series controllers. +

    +
    +
    +

    + Motor Record Version 5.7 Release Notice

    +
    +

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

    +
    +

    + Modifications to Existing Features

    +
    +
    + Initial Position +

    + With this release, if the absolute values of both the save/restore's target position + and the controller's commanded position are greater than the re-try deadband (RDBD) + at boot-up, then DVAL will be initialized from the controller's value. In other + words, if the absolute value of the controller's commanded position is greater than + the re-try deadband at boot-up, than the controller's position takes precedence + over the save/restore value. +

    +
    +
    +

    + New Features

    +
    +
    +

    + Physik Instrumente (PI) C-630 +

    +

    + Kurt Goetze added support for the Physik Instrumente (PI) model C-630 motion controller. +

    +

    + Physik Instrumente (PI) C-848 +

    +

    + Support added for the Physik Instrumente (PI) C-848 motor controller. +

    +
    +
    +

    + Motor Record Version 5.6 Release Notice

    +
    +

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

    +
    +

    + Modifications to Existing Features

    +
    +
    + IMS MDrive Configuration +

    + IMS MDrive users must make the following configuration changes to their MDrive's + as described in the distribution document "motorR5-6/motorApp/ImsSrc/README". +

    +
      +
    • Configure the limit and home switches.
      • +
    • Change the MDrives' Echo Mode Flag to two (EM=2).
      • +
    +
    +
    +

    + Motor Record Version 5.5 Release Notice

    +
    +

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

    +
    +

    + Modifications to Existing Features

    +
    +
    + Conversion to ASYN +

    + The motor record distribution has been converted from MPF to ASYN R4.1. All support + for MPF has been removed. +

    +
    +
    + Acceleration Correction +

    + Slew acceleration calculations were incorrect. Instead of the correct calculation; + A = (Vf - Vo) / t, the record was using A = Vf / t, which is correct only if Vo + (VBAS) is zero. Thanks to Harvey Rarback for pointing out this long standing error. +

    +
    +
    +

    + Motor Record Version 5.4 Release Notice

    +
    +

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

    +
    +

    + Modifications to Existing Features

    +
    +
    + Status Updates +

    + If the motor record is processed and there are no functions to perform (i.e., no + current or outstanding move request), then the motor record will perform a status + update using the STUP field. +

    +
    +
    +

    + New Features

    +
    +
    +

    + OMS MAXv device support +

    + Device support for Oregon Micro Systems, Inc. MAXv controller was added. +

    +

    +

    + Delta Tau PMAC +

    +

    + Device support for Delta Tau's PMAC2-VME controller was added. +

    +
    +
    +

    + Motor Record Version 5.3 Release Notice

    +
    +

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

    +
    +

    + Modifications to Existing Features

    +
    +

    + OMS VME58 Servo Limit Switch Problem

    +

    + The motor record would lock-up when a user tried to move off an activated limit + switch with the OMS VME58 servo motor controller board (i.e., model -8S). Although + this problem has been resolved there is a design problem with the OMS VME58 servo + controller that prevents it, in most cases, from moving off an activated limit switch. + Users are advised to avoid this situation +

    +

    + Encoder Resolution (ERES) Polarity

    +

    + Previous releases of the motor record forced the sign of ERES to match the sign + of MRES. With this release, ERES and MRES may have different signs. This allows + the user to change the sign of ERES rather than reverse encoder wires when the motor + and encoder direction are reversed. Warning! This does not work with controllers + that are doing closed-loop control; e.g., DC motors. Reference (D/A) and feedback + (encoder) signals must have the same polarity for DC motors or the motor will literally + run away. +

    +

    + PID parameter initialization +

    +

    + PID parameters (i.e., PCOF, ICOF and DCOF fields) were not initialized at boot-up. + With this release, if the GAIN_SUPPORT bit in the MSTA is true, each nonzero, PID + parameter will be initialized. For backwards compatibility, zero valued PID parameters + will not be initialized. +

    +

    + IMS MDrive Device Driver +

    +

    + Previous releases of the IMS MDrive device driver did not work. Thanks to Kevin + M. Peterson (UNI-CAT) for identifying and fixing the errors in previous releases. + A README file has been added to the ImsSrc directory that documents how the MDrive + must be initialized before using it with this device driver. +

    +

    + Three Device Drivers New To R3.14.x +

    +

    + The following three device drivers have been ported from the R3.13.x compatible + version of the motor record:

    +
      +
    • the Physik Instrumente (PI) GmbH & Co. C-844 motor controller.
      • +
    • Kevin Peterson's support for the MicroMo MVP 2001 B02 controller.
      • +
    • Kurt Goetze's support for the Micos MoCo dc controller.
      • +
    +
    +

    + New Features

    +
    +
    +

    + Status Update (STUP) +

    +

    + The STUP field (Status Update) has been modified due to bug fixes. The STUP field + functions as follows;

    +
      +
    • Valid values for STUP are OFF(0), ON(1) and BUSY(2).
      • +
    • A Channel Access (CA) client writes ON(1) to the STUP field which causes the motor + record to set STUP to BUSY(2) and request a single controller status update. After + the status is updated the record sets STUP to OFF(0).
      • +
    • CA clients are restricted to writing ON(1) to STUP only when STUP is OFF(0).
      • +
    • It is the responsibility of the user to restrict the frequency (and thus the incurred + overhead) at which the CA client writes ON(1) to STUP.
      • +
    +

    + With the STUP field it is possible to have another EPICS record periodically write + ON(1) to the motor record's STUP field. This would result in continuous, periodic + status updates. +

    +
    +
    +

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

    +

    + OMS VX2-006 Spurious Interrupts +

    +

    + Spurious interrupts were occurring with OMS VX2-006 ver 1.04 controller boards. + For the sake of throughput, the OMS VME8/44 device driver enables the done (DON_E) + and input buffer full (IBF_E) interrupts, but disables the transmit buffer empty + (TBE_E). +

    +

    + 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).
    -
    -
    +
    + 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. +
    2. the new target position is different from the actual position by less than the + retry deadband (|DIFF| < RDBD).
      3. +
    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).
      4. +
    + 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.  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. -
    2. - the new target position is different from the actual position by less than the - retry deadband (|DIFF| < RDBD). -
      3. -
    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). -
      4. -
    - 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 + 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.

    -
    -

    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 -

    - - -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: -
    -
      -
    1. - DIRECTION: (0:Negative, 1:Positive) -
      2. -
    2. - DONE: motion is complete. -
      3. -
    3. - PLUS_LS: plus limit switch has been hit. -
      4. -
    4. - HOMELS: state of the home limit switch. -
      5. -
    5. - Unused -
      6. -
    6. - POSITION: closed-loop position control is enabled. -
      7. -
    7. - Unused -
      8. -
    8. - HOME: if at home position. -
      9. -
    9. - PRESENT: encoder is present. -
      10. -
    10. - PROBLEM: driver stopped polling. -
      11. -
    11. - MOVING: non-zero velocity present. -
      12. -
    12. - GAIN_SUPPORT: motor supports closed-loop position control. -
      13. -
    13. - COMM_ERR: Controller communication error. -
      14. -
    14. - MINUS_LS: minus limit switch has been hit.
      -
      15. - -
    -
    -
    - -
    -

    - New Features -

    -
    - -

    -Advanced Control Systems and Mclennan device driver support -

    - -

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

    - - - -
    -

    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: -

    - - - -
    -

    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: -
    - -
    - -

    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: - -
      -
    1. - 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. -
      2. - -
        -
      1. - 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. -
        2. -
      2. - 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. -
        3. - -
      -
    2. - 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. -
      3. - -
    - -

    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: -

    - - - -

    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

    - - - -

    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: - - -

    Driver Power Monitoring

    - - - - - -

    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:
    - 
    -  -

    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    LinkLink Type Associated Field
    OUT*DBOUTPUT -
    - DVAL -
    -
    STOODBOUTPUTSTOP
    DINPDBINPUTDMOV
    RDBL*DBINPUT -
    - DRBV -
    -
    RINPDBINPUT -
    - RMP -
    -
    -
    - -
    +
    +

    + 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

    - * - Not a new field, but a new function provided only by soft channel device - support. + 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

    -
    - -

    -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: -
    -
      -
    1. - 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. -
      2. -
    2. - Servo support has been extended to the MM4000 controller. -
      3. - -
    -
    - -

    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 -
    - - -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: -

    - -
    -
    - -

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

    - -

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

    -
    -
    -
    -
    -
    -
    -
    +

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

    +
    +
      +
    1. DIRECTION: (0:Negative, 1:Positive)
      2. +
    2. DONE: motion is complete.
      3. +
    3. PLUS_LS: plus limit switch has been hit.
      4. +
    4. HOMELS: state of the home limit switch.
      5. +
    5. Unused
      6. +
    6. POSITION: closed-loop position control is enabled.
      7. +
    7. Unused
      8. +
    8. HOME: if at home position.
      9. +
    9. PRESENT: encoder is present.
      10. +
    10. PROBLEM: driver stopped polling.
      11. +
    11. MOVING: non-zero velocity present.
      12. +
    12. GAIN_SUPPORT: motor supports closed-loop position control.
      13. +
    13. COMM_ERR: Controller communication error.
      14. +
    14. MINUS_LS: minus limit switch has been hit.
      +
      15. +
    +
    +

    +

    +
    +

    + New Features +

    +
    +

    + Advanced Control Systems and Mclennan device driver support +

    +

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

    + +
    +

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

    + +
    +

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

    +
    + +
    +

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

    +
      +
    1. 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. +
        +
      1. 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.
        2. +
      2. 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.
        3. +
      +
      2. +
    2. 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.
      3. +
    +

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

    + +

    + 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

    + +

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

    + +

    + Driver Power Monitoring

    + +

    +                 + User I/O #0 <> X axis +

    +

    +                 + "       " 1 <> Y  " +

    +

    +                 + ..................... +

    +

    +                 + "       " 7 <> S  "

    + +

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

    +
    +
      +
    1. 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.
      2. +
    2. Servo support has been extended to the MM4000 controller.
      3. +
    +
    +

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

    +
    + +

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

    +
    + +
    +

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

    +

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