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).
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.
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.
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.
IMS MDrive users must make the following configuration changes to their MDrive's as described in the distribution document "motorR5-6/motorApp/ImsSrc/README".
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.
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.
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) PolarityPrevious 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.
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 drv
New Features
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.
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
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).
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.)
Soft Channel device support modifications
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.
- 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:
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.
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.
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.
!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).
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:
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).
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).
Previous releases of the motor record allowed the auto restore to take
precedence over the controller when initializing the target position (i.e., DVAL).
- MRES
- UREV
- VBAS
- SBAS
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:
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.
1. INIT - Sent at record initialization.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.
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.
- 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".
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 |
|
| STOO | DBOUTPUT | STOP |
| DINP | DBINPUT | DMOV |
| RDBL* | DBINPUT |
|
| RINP | DBINPUT |
|
* - 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.
- 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.
For the MM4000 For all OMS controllers
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.
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.
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.