diff --git a/README b/README index ca50d779..59e44bcd 100644 --- a/README +++ b/README @@ -99,7 +99,7 @@ Modification Log from R5-1 to R5-2 an error message response, print the error message and then, recursively, call itself. This restored communication transmit/receive synchronization. - File modified: - recv_mess() in drvMM3000.c + File modified: - recv_mess() in drvMM3000.cc 2) Spurious interrupts were occurring with OMS VX2-006 ver 1.04 controller boards. For the sake of throughput, the OMS VME8/44 device driver @@ -135,6 +135,67 @@ Modification Log from R5-1 to R5-2 - OmsSrc/drvOms.cc; support TBE_E interrupt. - MotorSrc/motordrvCom.h +3) 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. + + File modified: - do_work() in motorRecord.cc + +4) 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 new document /motorApp/NewportSrc/README. + + Files modified: - NewportSrc/devESP300.c + - NewportSrc/drvESP300.c + File added: - NewportSrc/README (notes on serial communication and + ESP300 configuration). + +5) 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 controllers an INFO update + after a LOAD_POS command would, intermittently, yield the previous + position. + + File modified: motor_task() and process_messages() in motordrvCom.cc + +6) 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 item#3 above, backlash + correction is always done after jogging, regardless of the jog + acceleration and speed parameters. + + File modified: Added extra jog backlash states to postProcess() in + motorRecord.cc + +7) 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). + + File modified: - callbackFunc() and process() in motorRecord.cc + Modification Log from R4-5 to R5-1 ================================== diff --git a/documentation/motorRecord.html b/documentation/motorRecord.html index 02b49fb2..29f6db32 100644 --- a/documentation/motorRecord.html +++ b/documentation/motorRecord.html @@ -37,9 +37,9 @@ -

Overview

This documentation describes version 5.1 of the EPICS motor +

Overview

This documentation describes version 5.2 of the EPICS motor record, and related EPICS software required to build and use it.  Version -5.1 of the motor record is compatible with EPICS base R3.14.2 and above. +5.2 of the motor record is compatible with EPICS base R3.14.4 and above.

The motor record is intended to support motors of all kinds, but currently supports only the following variety of motor controllers (in addition to Soft diff --git a/documentation/motor_release.html b/documentation/motor_release.html index bfb1663e..045a2be6 100644 --- a/documentation/motor_release.html +++ b/documentation/motor_release.html @@ -1,920 +1,1304 @@ - - + + + - - - - EPICS Motor Record Release Notice - + + EPICS Motor Record Release R5.2 Notice + + + - -

-
-

Motor Record Version 5.1 Release Notice

-
-
!WARNING!
+
+

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

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

+
+ + + +
+

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

+
Requirements

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

New Features

+
- -

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

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

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

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

+ 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

- +
+

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

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

+

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

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

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

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
LinkLink Type Associated Field
OUT*DBOUTPUT -
DVAL
-
STOODBOUTPUTSTOP
DINPDBINPUTDMOV
RDBL*DBINPUT -
DRBV
-
RINPDBINPUT -
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
- -
    -
  • -CKP  = -GAIN                              -CKP =        1999.9 * GAIN
    • +
    + 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 +

    + +
    • -CKI   = 2 * -GAIN                        -CKI =  2 * 1999.9 * GAIN
      • -
    • CKD = 3 * -GAIN                        -CKD = 3 * 1999.9 * GAIN
      • - -
    - Note that setting any of the individual PID record fields is not reflected -in the value of the GAIN field. -

    Highland V544 Device Support

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

    Motor Record Version 3.4 Release Notice

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

    Device driver design error fix

    - A design error was discovered in the OMS device drivers (drvOms and drvOms58).  -The EPICS device driver support task (i.e., tmotor) would query the OMS motion + 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. +
  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: +

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

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

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
LinkLink Type Associated Field
OUT*DBOUTPUT +
+ DVAL +
+
STOODBOUTPUTSTOP
DINPDBINPUTDMOV
RDBL*DBINPUT +
+ DRBV +
+
RINPDBINPUT +
+ 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 +
+ +
    +
  • + 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.
+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.
+     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.
+  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.
 
- 

- +  +

+
+
+
+
+
+
+
+ +