See release notes on github: https://github.com/epics-modules/motor/releases/tag/R6-10-1
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)
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)
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:
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.
!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).
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).
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.
Aerotech Ensemble
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."
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.Hytec 8601
Asyn motor driver support was added by Hytec for the 8601 stepper motor driver.
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 MAXvDirk Zimoch (PSI) fixed a bug in the OMS MAXv driver that caused the set_status() function to overwrite the home switch status in the response string
asyn motor
Highland Technologies
Support for the Highland Technologies V540 motor controller has been removed.
Aerotech Ensemble
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.
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).
Stale SET position data from OMS VME58 controllers.
A problem with certain OMS VME58 firmware versions (2.24-8S and all 2.35 versions) has arisen since modifications made under R6-3. When the user sets the motor record's position, the previous target and readback positions are read from the controller on the next update. This occurs with the previous release (R6-3) because the "stale data delay" was changed from 10ms to zero for the drvOms58 driver.
With this release the driver searches all VME58 board ID's for either 2.24-8S or any 2.35 version. If any board is found with these versions, the "stale data delay" is set to a non-zero value for all VME58 boards in the system.
"tdir=" error messages
A problem was reported by Emma Shepherd (Diamond) with the previous release if the "Use RDBL Link" field (URIP) was set to "Yes". The NTM logic was sending stop commands and issuing the "tdir=.." message to the console if the RDBL link was used. This error was the result of changes to the NTM logic in R6-3.
With this release, the NTM logic is restored to using feedback rather than reference positions. In addition, an "NTM deadband factor" field (NTMF) is added to allow the user to set the NTM deadband as follows;
NTM deadband = NTMF * (|BDST| + RDBD)
NTMF must be >= 2. If properly configured, the NTM deadband prevents NTM logic from issuing a STOP command at the end of a DC motor move that overshoots its' target position.
Access Security Level changes
Major changes have been made to the Access Security Level (ASL) attribute of the motor record fields. With previous releases, the following fields were set to ASL=0; FOF, VOF, SSET, SUSE, VBAS, VMAX, SBAS, SMAX, UREV and MRES. All other fields were set to ASL=1 by default.
With this release, the policy is to set all the fields that the user requires to do the following to ASL = 0;
All other fields are set to ASL = 1.
This means that out of the list of fields that were previously set to ASL=0; VBAS, VMAX, SBAS, SMAX, UREV and MRES are now set to ASL=1.
OMS MAXv A24/A32 VMEbus addressing bug fix
Previous releases had a problem with the OMS MAXv device driver when it was configured for more than one board, and, either A24 or A32 addressing was specified. The driver was not sizing the address space occupied by each MAXv correctly.
asyn motor archtecture updates
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.
save/restore of motor positions
Mark Rivers found and fixed a bug in the motor record that resulted in motor positions not being initialized from save/restore at boot-up if the retry deadband field (RDBD) was not included in a save set.
motorUtil error message
A bug was introduced into the shell command "motorUtilInit()" affecting these versions of the motor distribution; R6-2, R6-2-1 and R6-2-2. This bug resulted in the erroneous error message; "motorUtilInit: Prefix %c: has more than 53 characters. Exiting"
DC motor support
Two changes were made to the motor record to better support DC motors.
Examples renamed
The examples iocNoMPF and iocWithMPF were renamed iocNoAsyn and iocWithAsyn, respectively.
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.
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.
Thorlabs model MDT695
Joe Sullivan added support for Thorlabs Piezo Control Module, model MDT695.
Requirements
EPICS base R3.14.8.2 or greater. See the "Required Modules" section of the
Motor Record web page for details.
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.
Physik Instrumente GmbH & Co. Model E-710
Joe Sullivan added support for the Physik Instrumente (PI) GmbH & Co. Model E-710 motor controller.
Requirements
EPICS base R3.14.8.2 or greater. See the "Required Modules" section of the
Motor Record web page for details.
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.
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).
Requirements
EPICS base R3.14.8.2 or greater. See the "Required Modules" section of the
Motor Record web page for details.
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.
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.
Requirements
EPICS base R3.14.7 or greater. See the "Required Modules" section of the Motor
Record web page for details.
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.
Requirements
EPICS base R3.14.7 or greater. See the "Required Modules" section of the Motor
Record web page for details.
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.
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.
Requirements
EPICS base R3.14.7 or greater. See the "Required Modules" section of the Motor
Record web page for details.
IMS MDrive users must make the following configuration changes to their MDrive's as described in the distribution document "motorR5-6/motorApp/ImsSrc/README".
Requirements
EPICS base R3.14.7 or greater. See the "Required Modules" section of the Motor
Record web page for details.
The motor record distribution has been converted from MPF to ASYN R4.1. All support for MPF has been removed.
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.
Requirements
EPICS base R3.14.6 or greater. See the "Required Modules" section of the Motor
Record web page for details.
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.
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.
Requirements
EPICS base R3.14.5 or greater. See the "Required Modules" section of the Motor
Record web page for details.
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:
Status Update (STUP)
The STUP field (Status Update) has been modified due to bug fixes. The STUP field functions as follows;
With the STUP field it is possible to have another EPICS record periodically write ON(1) to the motor record's STUP field. This would result in continuous, periodic status updates.
Requirements
EPICS base R3.14.4 or greater. See the "Required Modules" section of the Motor
Record web page for details.
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).
!WARNING!
Requirements
EPICS base R3.14.2 or greater. See the "Required Modules" section of the Motor
Record web page for details.
!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).
New Features
!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).
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.
New Features
!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).
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).
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.)
The Driver Power Monitoring feature (available only with OMS VME58 controllers) was erroneously and randomly being enabled. This resulted in the error message Drive power failure at VME58 card# motor# appearing at the VxWorks console.
Soft Channel device support modifications
Bug Fix for Array Holes in VMEbus based controllers
For VMEbus based motor controllers only (i.e., OMS), a hole in an array of VME based motor controller boards caused the system to crash with a memory access error on the address of the missing controller. For example, if oms58Setup(3, 8, 0x4000, 190, 5, 10) was issued without a board at 0xFFFF5000, a bus error would occur if the user attempted to move a motor on the missing board.
This release allows holes in an array of VMEbus based motor controllers.
RES Field
With previous releases of the motor record, the RES field was set to either ERES or MRES, based on whether or not the following statement was true; MSTA indicates an encoder is present, AND, UEIP is set to YES. This state (i.e., MSTA indicates an encoder is present, AND, UEIP is set to YES) resulted in the record converting all position and velocity related values from EGU's to raw encoder counts before sending them to the motor controller. This is the manner in which the OMS controllers work (see OMS User's Manual, ER# command).
With this release, all raw positions, velocity and acceleration are in terms of
motor steps. The RES field is preserved for backward compatibility only. With
this release, the RES field is always equal to MRES.
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.
The MSTA field has been modified by providing separate +/- limit switch status bits. The MSTA bits are defined as follows:
- DIRECTION: (0:Negative, 1:Positive)
- DONE: motion is complete.
- PLUS_LS: plus limit switch has been hit.
- HOMELS: state of the home limit switch.
- Unused
- POSITION: closed-loop position control is enabled.
- Unused
- HOME: if at home position.
- PRESENT: encoder is present.
- PROBLEM: driver stopped polling.
- MOVING: non-zero velocity present.
- GAIN_SUPPORT: motor supports closed-loop position control.
- COMM_ERR: Controller communication error.
- 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:
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.
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.
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.
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).
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:
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).
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.
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.
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.
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.
Since the GAIN field is redundant (i.e., PID parameters can be set individually) it has been removed.
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).
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).
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
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:
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.
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:
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 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.
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:
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.
The following unused motor record fields were deleted: MODE, TRAK, MDEL, ADEL, CVEL, POSM, ALST, MLST
Device directive definition and processing:
User I/O #0 <> X axis
" " 1 <> Y "
.....................
" " 7 <> S "
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.
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:
- 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.
- Servo support has been extended to the MM4000 controller.
With this release there are two ways to set the motor controllers' PID parameters; either through the Combined Gain field (i.e., GAIN) or through the individual PID gain parameter fields (i.e., PCOF, ICOF, DCOF). Let the motor controller PID parameters be represented by CKP, CKI and CKD; then the relationship between these two methods is as follows:
For the MM4000 For all OMS controllers
Note that setting any of the individual PID record fields is notreflected in the value of the GAIN field.
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.
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:
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.
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.
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.