# Motor Record Version 6-11 Release Notice

See release notes on github: https://github.com/epics-modules/motor/releases/tag/R6-11

# Motor Record Version 6-10-1 Release Notice

See release notes on github: https://github.com/epics-modules/motor/releases/tag/R6-10-1

# Motor Record Version 6-10 Release Notice

#### Modifications to Existing Features

OMS support

Ron Sluiter added a check for an invalid MAXv interrupt level (IRQ=1) (1196bbe4df5968ae4ac05c142a9f4be93827d06e)

Ron Sluiter added a check for a new MAXv failure mode where the board reboots after the 1st command with response (e604c9588a087228dc6c0333818e00113df841ea)

Ron Sluiter added an optional test for VME58 failure mode where the board reboots after the 1st motion related command (4f54eb502bb1e4157db9a0587cfdbabd66de0c95)

Aerotech A3200 support

Ron Sluiter Removed the "Task number" argument from A3200AsynConfig and switched to using Task #2 for the ASCII Interface (a52ec2f62ff34b30597bccc7de9d70b4d2ed7f86)

Newport support

Mark Rivers modified the ESP300 driver so that it correctly determines the resolution when open-loop steppers are used (5245991323fb8c73cd6383e064da7b02c2629fea)

Mark Rivers changed the XPS PositionCompare API (44351c99d92837cbb283b21877a87ecc821875e0) and made numerous improvements to the PositionCompare functionality.

Motor Record improvments

jmdewart & Ken Lauer changed the acceleration calculation so that VBAS is ignored when VELO==VBAS (4b89359e1cc1b411f974c0733bdf0b70df303aa8)

Ron Sluiter changed the motor record logic so that the motor is stopped if URIP=Yes and RDBL read returns an error (220d18fcff89507a236152bd17aa48e5f13ca471)

Tim Mooney added a field, IGSET, to allow the SET field to be ignored. More info on why this was desirable can be found in pull request #53. (5cad105357739d603218502eb38be20ee736b4ee)

Tim Mooney modified the motor record's SYNC functionality so that it works when URIP=True (ac900b90615ef650f13a9f21a5f1c145c0402408)

#### New Features

AMCI ANG1 support

Kurt Goetze added support for the AMCI ANG1 controller/driver (8966aeabf292874de8c78754e95e14cde1f1c776) and made numerous improvements to the PositionCompare functionality.

Newport CONEX-PP support

Mark Rivers added support for the CONEX-PP series to the AG_CONEX driver (2b853366f48230356c869a46691acbd8c7391810) and made numerous improvements to the PositionCompare functionality.

iocsh scripts

Keenan Lang add iocsh setup scripts for many motor controllers (17d10a8158ba5ca23bfc97133901d8d6e859f1ac & a87835c14a20a8e11745e16591d031fb674f0e14)

PI E-517 support

Bruno Luvizotto added files for supporting PIE517 piezo controller (f31ed90b255a554a1930ac721d595ade0c8095a2)

New Focus 874x support

Wayne Lewis added support for the NewFocus 874x series of controllers (634e49d5076d87fefbd875cd0700e7feb6d062e3)

asynMotor support

Matthew Pearson added parameters to asynMotorController to deal with automatic amplifier control via setClosedLoop. (36dfab4a78725866fab5bd212c4c128a86e9f044)

# Motor Record Version 6-9 Release Notice

#### Modifications to Existing Features

#### New Features

Micronix Asyn Motor Support

Kevin Peterson (APS) added asyn motor support for the Micronix MMC-200 & MMC-100 Controllers.

MicroMo MVP2001 Asyn Motor Support

Kevin Peterson (APS) added asyn motor support for the MicroMo MVP2001 Controller.

Trajectory support

Tim Mooney (APS) added trajectory support for a single-motor Aerotech Ensemble

Tim Mooney (APS) added trajectory support for the Pro-Dex OMS MAXv

ProfileMove support

Mark Rivers (GSECARS) added ProfileMoveMode to support absolute and relative moves.

Newport AG_CONEX and AG_UC controllers

Mark Rivers (GSECARS) made changes to support CONEX-CC servo controller; it has KD; supports limits, velocity, acceleration; fixed homing problems

Mark Rivers (GSECARS) made changes to support AG-UC8 model that requires CC command to select a channel pair; add delay between writes for all commands on all ARCHs.

SmarAct MCS Motor Support

Kevin Peterson (APS) added support for rotary stages.

motorUtil improvements

Kevin Peterson (APS) made the following improvments to motorUtil:

- The listMovingMotors function can now be called on non-VxWorks iocs
- The name of the motor is written to a waveform record when its DMOV field changes, enabling smart clients to maintain a list of moving motors.

Phytron I1AM01 Stepper Motor Controller Support

Tom Slejko and Bor Marolt (Cosylab d.d.) added asyn motor support for the Phytron I1AM01 Stepper Motor Controller.

# Motor Record Version 6-8 Release Notice

#### Modifications to Existing Features

!WARNING!
motorRecord.dbd has been modified. This requires rebuilding any and all user trees (i.e., <ioctop>) that load the motor record.

Newport XPS Asyn Motor (Phase-2) Support

The stepsPerUnit argument of XPSConfigAxis has changed from an integer to a string to make phase-2 consistent with phase-3 support. Failing to change the stepsPerUnit argument to a string results in parameter-out-of-range errors when attempting to move XPS motors.

Newport ESP300

Prior to this release, the ESP300 driver used the controller's resolution to scale the EGUtoRAWbacktoEGU conversion that is done between motor record and device driver support. With R6.8 the driver uses the motor record's MRES to scale this conversion. Users should now set the MRES like any other motor; i.e., to the precision of the stage.

Soft-travel limits

Several changes have been made with regard to the motor record's soft-travel limits (LVIO field).

- Since the soft-travel limits (HLM/LLM, DHLM/DLLM) are not defined until after a successful home search is performed, error checks have been removed from the home search request (HOMF/HOMR).
- All moves out of the invalid soft-limit travel range, toward the valid range, are allowed.

Retry Deadband

The retry deadband (RDBD) field no longer limits the smallest allowed move. The size of a move is now only limited by the motor resolution (MRES).

#### New Features

Physik Instrumente (PI) Asyn Motor Support

Steffen Rau (Physik Instrumente GmbH & Co.) has added asyn motor support for PI motion controllers that use the GCS2 (General Command Set) command language. This support resides in the <motor>/motorApp/PIGCS2Src/ directory of the motor module.

PI micos SMC hydra Asyn Motor Support

Kevin Peterson (APS) added support for asyn motor support for the PI micos SMC hydra controller.

Schneider Electric (IMS) MDrive/MForce Asyn Motor Support

Nia Fong (SLAC) added asyn motor support for the Schneider Electric (IMS) MDrive/MForce controller that uses the MCode command language.

Newport XPS Support

Kevin Peterson (APS) added a sequence program, xpsSlave.st, that allows master/slave mode to be used with any version of the XPS motor support.

Newport Hexapod Asyn Motor Support

Kevin Peterson (APS) added asyn motor support for the Newport Hexapod controller.

nPoint C300 Asyn Motor Support

Kevin Peterson (APS) added asyn motor support for the nPoint C300 piezo controller.

OMS MAXv and MAXnet Asyn Motor Support

Jens Eden (PTB) added asyn motor support for both the OMS MAXv and the OMS MAXnet controllers.

Newport Agilis UC series Asyn Motor Support

Mark Rivers (APS) added asyn motor support for the Newport Agilis UC series of controllers.

# Motor Record Version 6-6 and 6-7 Release Notice

#### Modifications to Existing Features

Aerotech 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 (phase 1) was removed with this release. The asyn motor architecture supports continuous, periodic updates; the old architecture does not.
- With this release, the Aerotech Ensemble driver only supports 4.01.00 Ensemble version firmware and above.
- In order to support SCURVE trajectories, the move commands have been changed from MOVE[ABS/INC] to LINEAR. Currently, the SCURVE command can only be set from an asyn record (e.g., SCURVE 75).
- There is a problem with initiating a home search with the Aerotech Ensemble motor controller with EPICS. The problem is that the EPICS Ensemble driver uses Aerotech's ASCII communication protocol and that protocol blocks all communication on ASCII communication ports during a home search. Consequently, once a home search is started from EPICS, it is unable to stop it. With release R6-6, the home search function was commented out of the Ensemble driver. Users that need to perform a home search should do it from Aerotech's IDE software, which can abort a home search. The Home Search ability will be restored in a future release.

OMS

- Watchdog and reboot error checks have been added to both the VME58 and MAXv (with firmware ver:1.33 and above) device drivers. The EPICS drivers check for a reboot error or Watchdog timeout (MAXv) with every motor status update.

  If an error occurs, an error message is sent to both the errlog task and the console. Since a reboot or watchdog timer trip indicates that the controller has rebooted and no longer has valid motor positions, the controller is disabled and is no longer available to EPICS until after the VME crate has been rebooted. Other OMS boards in the system are unaffected by this scenario.

  To better communicate this problem to the user, several medm displays have been changed. Small displays (motorx_tiny.adl, motorx.adl) will show a yellow border around their position readback values. Larger displays (motorx_more.adl, motorx_all.adl) will display the message "Controller Error" in yellow. The following error message at the console and/or in the IOC errlog is definitive;

  "***MAXv card #<card>Disabled*** Watchdog Timeout CTR =<ctr>"

  "***VME58 card #<card>Disabled*** Reboot Detected."

- A third argument was added to the MAXvConfig() call; the SSI based absolute encoder bit flag.

  MAXvConfig(0, config0, 0x00)

  Bit #0 for Axis X, bit #1 for Axis Y, etc.. Set a bit flag to '1' for absolute encoder values; '0' for the standard incremental encoder values.

#### New Features

Hytec 8601

Asyn motor driver support was added by Hytec for the 8601 stepper motor driver.

# Motor Record Version 6-5 Release Notice

#### Modifications to Existing Features

64-bit compatability

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 last release to include the old Ensemble device driver architecture version. See below.

RES field deleted

The RES field was removed from the motor record database definition with this release (R6-5). The RES field has been depreciated by the MRES field since R4-5.

#### New Features

Aerotech Soloist and Ensemble motor controller support

Two new drivers from Aerotech were add; an asyn motor version of the Ensemble and the Soloist under the old driver architecture. 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.

ADEL and MDEL fields added

Matthew Pearson (Diamond) added support for the ADEL and MDEL motor record fields. Unlike most records, the ADEL/MDEL fields in the motor record apply to the User Readback Value (RBV). See the motorRecord.html document for details.

Synchronize field (SYNC)

When the SYNC field is set to Yes(1) the record sets the Drive fields (VAL/DVAL/RVAL) to their readback values (RBV/DRBV/RRBV) and sets SYNC field back to No(0).

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

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

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

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

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

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

#### Backlash Correction Bug Fixes

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

1. motion is in progress (i.e., DMOV is false).
2. the new target position is different from the actual position by less than the retry deadband (|DIFF| < RDBD).
3. backlash correction is enabled (i.e., BDST is non-zero) and the new move is not in the "preferred direction" (preferred direction is the direction in which the motor moves during the backlash-takeout part of a motor move).

A bug was introduced in R4.5 when backlash correction was changed. The error occurred when a new target position was issued while the motor was moving. The motor would move to the new target position at the backlash velocity rather than the slew velocity.
Thanks to Kevin M. Peterson, James B. Stevens and John Maclean for their help in finding and fixing these bugs.

New Features

#### Newport ESP300 device support

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

#

# Motor Record Version 4.5 Release Notice

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

#### Modifications to Existing Features

Communication Retries

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

#### Requirements Clarification

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

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

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

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

#### Bug Fix for Driver Power Monitoring error

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

Soft Channel device support modifications

- Prevent record processing before "interruptAccept" is true. This helps prevent alarms.
- If the readback is changing, but motion was not initiated by this record, then reset the motor record's target to actual position (i.e., VAL/DVAL/RVAL = RBV/DRBV/RRBV) after the move.
- Lowered the priority of the "soft_motor task below the "dbCaLink"task. This fixes the "DMOV processing before the last DRBV update" problem.

Bug Fix for Array Holes in VMEbus based controllers

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

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

RES Field

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

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

#### Backlash Correction

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

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

#### Separate +/- Limit Switch status bits

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

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

New Features

Advanced Control Systems and Mclennan device driver support

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

- Advanced Control Systems, Corp. model MCB-4B
- Mclennan model PM304

# Motor Record Version 4.4 Release Notice

#### Modifications to Existing Features

Disable Travel Limits

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

RVAL ignored error

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

New Features

Jog velocity and acceleration parameters

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

# Motor Record Version 4.3 Release Notice

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

STOP field hangs record

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

HIDEOS support removed

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

# Motor Record Version 4.2 Release Notice

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

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

#### Modifications to Existing Features

Precedence between field pairs

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

Moving Off a Limit Switch with a Oms58 device

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

Separate motion commands for target and backlash moves

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

Errors introduced in V4.0

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

- If the "ncards" argument of the omsSetup() function in st.cmd file was not accurate (i.e., did not match the actual number of OMS VME8/44 boards in the VME crate); the "dbior" command could result in erroneous information or a bus error.
- Jog request would not work after the state of the UEIP field was changd.
- Backlash correction was not occurring after a JOG.
- The motor record would 'hang' in the moving state on the rare occasion when a target position (i.e., VAL or DVAL) fell almost exactly half way between two integer RVAL values, and the retry feature was enabled (i.e., RTRY is nonzero)

#### New Features

Newport PM500 device support

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

Intelligent Motion Systems, Inc. IM483 device support

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

# Motor Record Version 4.1 Release Notice

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

#### Modifications to Existing Features

#### OMS VME58 retry problem

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

#### OMS Stop problem

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

# Motor Record Version 4.0 Release Notice

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

#### Modifications to Existing Features

#### GAIN Field Removed

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

#### HOM[F/R] Bug Fix

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

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

#### Initial Position

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

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

#### Access Security Level

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

> - MRES
> - UREV
> - VBAS
> - SBAS

#### MM4000/5 Device Driver

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

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

#### Bug Fix for OMS VME58 running on PowerPC

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

#### New Features

Newport MM3000 Device Support

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

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

#### Uninitialized Oms/Oms58 Driver Error Check

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

#### Maximum Velocity Fields (VMAX/SMAX)

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

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

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

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

# Motor Record Version 3.5 Release Notice

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

#### Modifications to Existing Features

#### Command Primitives

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

> 1. INIT - Sent at record initialization.

> 2. PREM - Sent before every command string that causes motion.

> 3. POST - Sent after a complete motion is finished or when an overtravel limit switch is detected.

No error checking is done by the motor record or the device driver to insure that the command strings are valid. Command primitives that result in a response from the motion control board are valid, but the response is not processed.

#### Servo related Fields

- The GAIN field "prompt" has been changed from "Response Gain" to "Combined Gain". In addition, valid values for the GAIN field have been changed to [0.0, for MM4000 - 0.00005, for OMS] <= GAIN <= 1. For more on PID, see "PID Gain Parameters" below.
- The status enable field (i.e., STEN) has been eliminated; the control enable field (i.e., CNEN) is used to both control the torque enable and show its' status.

#### Unused Fields Removed

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

#### New Features

#### Device Directives

Device directive definition and processing:

- Valid only in the INIT field.
- Must be identified by the following;
  - First character of INIT string must be a '@'.
  - One or more characters followed by a terminating '@'; i.e., device directives must have nonzero length.
  - A valid device directive; currently, only "DPM_ON".
- INIT strings are stripped of valid device directives (including @'s) and tested for nonzero length before being sent to the controller. For example, given the INIT string, "@DPM_ON@HE", the device directive @DPM_ON@ is stripped out before HE is sent to the controller.

#### Driver Power Monitoring

- This feature is only available with the OMS VME58 device support.
- The 8 User I/O signals are assigned to the 8 possible VME58 axes as follows:

User I/O #0 <> X axis

" " 1 <> Y "

.....................

" " 7 <> S "

- Drive-power monitoring defaults to disabled at boot-up. Request enabling drive-power monitoring by entering the device directive "@DPM_ON@" command into the motor record initialization field (i.e., INIT). The INIT field is processed at record initialization (i.e., bootup), hence if there are no errors, drive-power monitoring will be enabled after the next bootup.
- Whenever a request is made to enable drive-power status monitoring, an error check is made (using the VME58 "RB" command) to verify that the User I/O has been configured as an input. The following message will appear in the error log if a configuration error is detected; "Invalid VME58 configuration; RB = 0x####", where "####" is the VME58's response to the RB command.
- When drive-power status monitoring is enabled and a power failure is detected, the device driver will respond by activating the the RA_OVERTRAVEL bit in the MSTA. This results in either HLS or LLS being activated depending on the DIR field. In addition, the following message will appear in the error log; "Drive power failure at VME58 card#?? motor#??".

#### Soft Channel Device Support

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

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

Link | Link Type | Associated Field
OUT* | DBOUTPUT | DVAL
STOO | DBOUTPUT | STOP
DINP | DBINPUT | DMOV
RDBL* | DBINPUT | DRBV
RINP | DBINPUT | RMP

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

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

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

#### Newport MM4000 Device Support

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

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

#### PID Gain Parameters

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

> For the MM4000 For all OMS controllers

- CKP = GAIN CKP = 1999.9 * GAIN
- CKI = 2 * GAIN CKI = 2 * 1999.9 * GAIN
- CKD = 3 * GAIN CKD = 3 * 1999.9 * GAIN

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

#### Highland V544 Device Support

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

# Motor Record Version 3.4 Release Notice

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

### Device driver design error fix

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

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

> - Erroneous motor stops being issued by the device support when changing motor direction.
> - Backlash occurring when the motor is moving in the same direction as the sign of BDST.
> - DVAL and RBV becoming out-of-synch. RBV would always be an old value from the previous move.

### PID Parameter Support for VME58

The motor record classifies a motor as a servo if it has two features; an adjustable closed loop position response gain and the ability to enable/disable closed loop position control (i.e., motor torque). A motor lacking either of the above two features is classified as a stepper and is supported by the standard motor record features. The following three motor record fields support servo motors:

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.