Motor Record Version 4.8 Release Notice
Requirements
EPICS base R3.13.5 or greater. See the "Required Modules" section of
the Motor Record web page for details.
New Features
Mclennan PM600
Mark Rivers added support for the Mclennan PM600 controller.
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).
Modifications to Existing Features
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.
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
Motor Record Version 4.7 Release Notice
!WARNING!
motorRecord.dbd has been modified. This requires rebuilding any and
all user trees (i.e., <ioctop>) that load the motor record (see README
items #3 and #4 for details).
Modifications to Existing Features
Redundant DMOV Monitor Postings
Eliminated redundant DMOV monitor postings. Under certain conditions
the motor record would post the state of the DMOV field twice. For
example, with previous releases the motor record would post DMOV=0 twice
if backlash correction was enabled and the user jogged the motor.
OMS VME58 Intermittent Limit Switch Status Error
There is a problem with OMS VME58 ver 2.35-8 firmware when used with
MVME2700 CPU boards. The problem is that the controller board intermittently,
reports that there is no limit switch error when there is an error.
This error can occur if the user repeatedly, tries to move in the direction
of the limit switch when the limit error condition exits. A delay has
been added to work around the problem.
New Features
Motor Synchronized DB Puts
device directive support has been extended to the PREM and POST fields
for OMS devices only. The new device directive supports changing the
value of a database variable. The syntax is as follows:
PREM - @PUT(pvname, pv-value, delay in seconds)@
POST - @PUT(pvname, pv-value)@
Note that the PREM supports a delay argument, but that POST does not. The
Readback settle time field (DLY) should be used to create a time delay after the PV specified in the POST field is written. See the
Miscellaneous fields section of motorRecord.html for further information on the INIT, PREM and POST fields.
IMS MDrive17 device support
Device driver support for the Intelligent Motion Systems (IMS) MDrive17 model motor controller is available with this release.
Home Velocity
A home velocity field (HVEL) was added with this release. Like all
speed related fields, the HVEL is limited by the maximum (VMAX) and base
(VBAS) velocity fields.
In addition, if HVEL is not initialized by the user, the motor record sets HVEL to VBAS.
Motor Record Version 4.6 Release Notice
!WARNING!
motorRecord.dbd has been modified. This requires rebuilding any and
all user trees (i.e., <ioctop>) that load the motor record (see README
items #3 and #4 for details).
Modifications to Existing Features
Soft Channel Device Support
A conflict between the requirements specified under Requirements
Clarification below and the goal of having the same record level functionality
for all device drivers, including Soft Channel device support, was found by
Tim Graber.
A problem occurred with, for example, the SoftMotorEx.db
that is distributed with the motor record, when backlash was enabled in the
hard motor(a motor configured without Soft Channel device support).
The result was that the soft motor (a motor configured with
Soft Channel device support) would interpret the hard motor's backlash correction
as the motor going in the wrong direction, and stop the "hard" motor from
completing the backlash correction.
With this release, the requirements on how the motor record
processes a new target position while the motor is in motion have been modified
based on a new field; New Target Monitor (NTM).
Case #1: The motor record is given a new position, which is in
the opposite direction from the current motor motion. If NTM is yes,
the motor is immediately stopped and given a motion command to the new position.
If NTM is no, the motor completes the previous move before it
is given a motion command to the new position.
Case #2: The motor record is given a new position, which is in
the same direction as the current motor motion, but the new position is closer
to the motor's current position than the original target position. If
NTM is yes, the motor is stopped after it has gone past the new position;
then a command is given to return to the new position. If NTM is no,
the motor completes the previous move before it is given a motion command
to the new position.
Case #3: The motor record is given a new position, which is in
the same direction as the current motor motion, but the new position is further
from the motor's current position than the original position. After
the motor reaches the original target position and stops, a command is given
to the new target position. This case is independent of NTM.
A Soft Channel device support design limitation was discovered
by Tim Mooney. The problem is a result of the modifications made with
R4-5 below, where the soft motor synchronizes it's target position (i.e.,
VAL/DVAL/RVAL) with it's readback position (RBV/DRBV/RRBV). Given an
application where there are two or more soft motors driving the system (e.g.,
slit), when one soft motor is moved, the other soft motor sees it's
readback changing and synchronizes it's target position with it's readback
position at the end of the move, thereby losing it's target position.
With this release, the LOCK field has been added to allow
the user to enable/disable synchronization due to the readback changing.
Backlash Correction Bug Fixes
The following scenario would put the motor record into an invalid state. A
new target position (i.e., VAL/DVAL/RVAL) is written to the motor record
under the following conditions;
- motion is in progress (i.e., DMOV is false).
- the new target position is different from the actual position by less
than the retry deadband (|DIFF| < RDBD).
- backlash correction is enabled (i.e., BDST is non-zero) and the new
move is not in the "preferred direction" (preferred direction is the
direction in which the motor moves during the backlash-takeout part of a motor
move).
A bug was introduced in R4.5 when backlash correction was changed. The
error occurred when a new target position was issued while the motor was
moving. The motor would move to the new target position at the backlash
velocity rather than the slew velocity.
Thanks to Kevin M. Peterson, James B. Stevens and John Maclean for their help
in finding and fixing these bugs.
New Features
Newport ESP300 device support
Device support for the Newport ESP300 motor controller is available with
this release.
Motor Record Version 4.5 Release Notice
!WARNING!
motorRecord.dbd has been modified. This requires you to 'rebuild' any
and all user trees (i.e., <ioctop>) that load the motor record (see
README item #2 for details).
Modifications to Existing Features
Communication Retries
Once a communication error is detected, one retry is attempted (Further
retries are made, if the position RETRY field is non-zero). If the
retry fails, then a communication error is reported. No further attempt
is made to communicate with the controller until subsequent user input (e.g.,
a new target position is entered). This change affects all device drivers
using GPIB or RS232 serial communication mechanisms (i.e., non-VME Bus boards).
Requirements Clarification
The requirements on how the motor record processes a new target position while
the motor is in motion have never been specified. The requirements are
as follows:
Case #1: The motor record is given a new position, which
is in the opposite direction from the current motor motion. The motor
is immediately stopped and given a motion command to the new position.
Case #2: The motor record is given a new position, which
is in the same direction as the current motor motion, but the new position
is closer to the motor's current position than the original target position.
The motor is stopped after it has gone past the new position; then a command
is given to return to the new position.
Case #3: The motor record is given a new position, which is in the same
direction as the current motor motion, but the new position is further from
the motor's current position than the original position. After the
motor reaches the original target position and stops, a command is given to
the new target position (Previous motor record versions ignored the new target
position.)
Bug Fix for Driver Power Monitoring error
The Driver Power Monitoring feature (available only with OMS VME58
controllers) was erroneously and randomly being enabled. This resulted
in the error message Drive power failure at VME58 card# motor# appearing
at the VxWorks console.
Soft Channel device support modifications
- Prevent record processing before "interruptAccept" is true. This
helps prevent alarms.
- If the readback is changing, but motion was not initiated by this record,
then reset the motor record's target to actual position (i.e., VAL/DVAL/RVAL
= RBV/DRBV/RRBV) after the move.
- Lowered the priority of the "soft_motor task below the "dbCaLink"
task. This fixes the "DMOV processing before the last DRBV update" problem.
Bug Fix for Array Holes in VMEbus based controllers
For VMEbus based motor controllers only (i.e., OMS), a hole in
an array of VME based motor controller boards caused the system to crash
with a memory access error on the address of the missing controller.
For example, if oms58Setup(3, 8, 0x4000, 190, 5, 10) was issued without a
board at 0xFFFF5000, a bus error would occur if the user attempted to move
a motor on the missing board.
This release allows holes in an array of VMEbus based motor controllers.
RES Field
With previous releases of the motor record, the RES field was set to either
ERES or MRES, based on whether or not the following statement was true;
MSTA indicates an encoder is present, AND, UEIP is set to YES. This
state (i.e., MSTA indicates an encoder is present, AND, UEIP is set to YES)
resulted in the record converting all position and velocity related values
from EGU's to raw encoder counts before sending them to the motor controller.
This is the manner in which the OMS controllers work (see OMS User's Manual,
ER# command).
With this release, all raw positions, velocity and acceleration are in
terms of motor steps. The RES field is preserved for backward compatibility
only. With this release, the RES field is always equal to MRES.
Backlash Correction
Previous motor record releases put both the "slew" and backlash correction
moves on the same motor controller command line. Some controllers (i.e.,
OMS) handled this correctly by processing the slew move followed by the backlash
correction move. Other controllers (i.e, Newport) did not handle this
correctly and processed the commands immediately, resulting in the controller
moving to the target position without backlash correction, but at the backlash
correction velocity.
With this release, backlash correction commands are not issued to the controller
until after the slew move is completed.
Separate +/- Limit Switch status bits
The MSTA field has been modified by providing separate +/- limit switch status
bits. The MSTA bits are defined as follows:
- 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:
- 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:
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:
- 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.
- 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.
- 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.
- The MM4005 supports up to eight axes. User access to the controller's
front panel is required to scroll the front panel display through all eight
axes. Since remote mode locks out the user from using the controller's
front panel, the motor record no longer puts the MM4000/5 in remote mode
. EPICS is unable to communicate with the MM4000/5 controller if it
is in local mode and the front panel is not at the top menu.
A Controller communication error bit was allocated in the MSTA field
to help aid user's in diagnosing a controller communication error. Currently,
only the MM4000/5 device driver sets this error indicator. When the
communication error bit is set True in the MSTA, the motor record SEVR field
is set to INVALID_ALARM and the STAT field is set to COMM_ALARM. User's
who want their MM4000/5 in remote mode at boot-up can add the remote mode
command ("MR") to their INIT field.
Bug Fix for OMS VME58 running on PowerPC
Through an odd set of circumstances the Oms58 driver was not performing
status updates on PowerPC (PPC) platforms. All users of the OMS VME58
controller on a PPC platform must upgrade to Motor Record version 4.0 for
full functionality.
New Features
Newport MM3000 Device Support
Device driver support for the MM3000 exist for this release of the motor
record. Note the following differences between the MM4000 and MM3000
device drivers:
- The MM3000 does not support a generic Load Position commands.
In other words, the user can only define the current controller position
as being the zero position. This limitation is reflected in the motor
record device support. When the SET field is true, the only valid entry
to either the DVAL or RVAL fields is zero.
- The only position units the MM3000 will communicate with the host in,
are either encoder ticks or stepper motor steps.
Uninitialized Oms/Oms58 Driver Error Check
With previous release, if the Oms or Oms58 driver was some how omitted from
the database, a "... card does not exist" error message would result.
With this release, an explicit error check and corresponding error message
(i.e., "Oms[58] driver uninitialized.") is issued at record initialization
if a required driver is not initialized. (Because of the particulars of MM[3000/4000]
initialization, this is not an issue with Newport controllers.)
Maximum Velocity Fields (VMAX/SMAX)
Maximum velocity fields have been added; VMAX in EGU/s units and SMAX in
RPS units.
In order to support BURT, range checking is done in such a way that any
minimum (i.e., VBAS/SBAS) or maximum (i.e., VMAX/SMAX) value entered is
valid. For example, if the minimum is entered and it exceeds the maximum,
then the maximum is set to the new minimum value. Slew (VELO/S) and
backup velocity (BVEL/SBAK) fields are forced by the motor record to be within
the range set by VMAX/SMAX and VBAS/SBAS, inclusively. For example,
if VELO is entered and it is less than the minimum, then VELO is set to VBAS.
To facilitate software upgrades, a zero VMAX disables maximum velocity
error checking. Those who use both BURT and VMAX (i.e., nonzero VMAX)
should insure that VMAX and VBAS are placed before VELO and BVEL in their
BURT request files. VMAX/SMAX have Access Security Level zero.
motorx_setup_1.7.adl (which is included with this distribution)
includes support for the maximum velocity fields.
Motor Record Version 3.5 Release Notice
Release 3.5 of the motor record is only compatible with EPICS baseR3.13.1.1
and above. This document describes changes made to the motor record
and its' associated device driver support between versions 3.4 and 3.5.
Those changes are as follows:
Modifications to Existing Features
Command Primitives
This feature is available only with OMS VME8/44/58 or Newport MM4000
device support (i.e., devOms, devOms58, devMM4000). Three motor record
fields are available to the user to send ASCII command primitives to the
servo control board at fixed, predefined, times. Each of the following
fields is defined as a character string:
1. INIT - Sent at record initialization.
2. PREM - Sent before every command string that causes motion.
3. POST - Sent after a complete motion is finished or when an overtravel
limit switch is detected.
No error checking is done by the motor record or the device driver to insure
that the command strings are valid. Command primitives that result
in a response from the motion control board are valid, but the response is
not processed.
Servo related Fields
- The GAIN field "prompt" has been changed from "Response Gain" to "Combined
Gain". In addition, valid values for the GAIN field have been changed
to [0.0, for MM4000 - 0.00005, for OMS] <= GAIN <= 1. For more
on PID, see "PID Gain Parameters" below.
- The status enable field (i.e., STEN) has been eliminated; the
control enable field (i.e., CNEN) is used to both control
the torque enable and show its' status.
Unused Fields Removed
The following unused motor record fields were deleted: MODE, TRAK, MDEL,
ADEL, CVEL, POSM, ALST, MLST
New Features
Device Directives
Device directive definition and processing:
- Valid only in the INIT field.
- Must be identified by the following;
- First character of INIT string must be a '@'.
- One or more characters followed by a terminating '@'; i.e., device
directives must have nonzero length.
- A valid device directive; currently, only "DPM_ON".
- INIT strings are stripped of valid device directives (including @'s)
and tested for nonzero length before being sent to the controller. For
example, given the INIT string, "@DPM_ON@HE", the device directive @DPM_ON@
is stripped out before HE is sent to the controller.
Driver Power Monitoring
- This feature is only available with the OMS VME58 device support.
- The 8 User I/O signals are assigned to the 8 possible VME58 axes as
follows:
User I/O #0 <> X axis
" " 1 <> Y "
.....................
" " 7 <> S " - Drive-power
monitoring defaults to disabled at boot-up. Request enabling drive-power
monitoring by entering the device directive "@DPM_ON@" command into the motor
record initialization field (i.e., INIT). The INIT field is processed
at record initialization (i.e., bootup), hence if there are no errors, drive-power
monitoring will be enabled after the next bootup.
- Whenever a request is made to enable drive-power status monitoring,
an error check is made (using the VME58 "RB" command) to verify that the User
I/O has been configured as an input. The following message will appear
in the error log if a configuration error is detected; "Invalid VME58 configuration;
RB = 0x####", where "####" is the VME58's response to the RB command.
- When drive-power status monitoring is enabled and a power failure is
detected, the device driver will respond by activating the the RA_OVERTRAVEL
bit in the MSTA. This results in either HLS or LLS being activated depending
on the DIR field. In addition, the following message will appear in the error
log; "Drive power failure at VME58 card#?? motor#??".
Soft Channel Device Support
The immediate goals for soft channel motor record device support were twofold.
First, to solve the problem of nonlinear position conversion in the data
base, rather than in the record. Second, to provide a more flexible
motor record interface for Table Records and SPEC.
New fields have been added to the motor record to support the Soft Channel
device driver. The new fields are all database links associated
with existing motor record fields. The new links and their associated
fields are listed in the table below:
Link |
Link Type |
Associated Field |
OUT* |
DBOUTPUT |
DVAL
|
STOO |
DBOUTPUT |
STOP |
DINP |
DBINPUT |
DMOV |
RDBL* |
DBINPUT |
DRBV
|
RINP |
DBINPUT |
RMP
|
* - Not a new field, but a new function provided only by soft channel
device support.
The Soft Channel database links are only processed when the Soft Channel
device driver is selected. These links are ignored when using any other
Motor Record device driver. At this time, the above links are not
dynamically retargetable.
The OUT, DINP and RDBL are monitored for value changes via a CA event
task. Users must choose either a dial input link (RDBL) or a raw input
link (RINP), but not both.
Newport MM4000 Device Support
This is Mark
Rivers MM4000 device support ported to the latest motor record release.
The following are the functional differences between Mark's version 1.01
and
this release:
- 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.
PID Gain Parameters
With this release there are two ways to set the motor controllers' PID parameters;
either through the Combined Gain field (i.e., GAIN) or through the
individual PID gain parameter fields (i.e., PCOF, ICOF, DCOF). Let the
motor controller PID parameters be represented by CKP, CKI and CKD; then the
relationship between these two methods is as follows:
For the MM4000
For all OMS controllers
- CKP = GAIN
CKP = 1999.9 * GAIN
-
CKI = 2 * GAIN
CKI = 2 * 1999.9 * GAIN
- CKD = 3 * GAIN
CKD = 3 * 1999.9 * GAIN
Note that setting any of the individual PID record fields is notreflected
in the value of the GAIN field.
Highland V544 Device Support
Device support for the Highland V544 is available with this release.
This version (i.e., version 1.3) is functionally the same as the earlier
release (i.e., version 1.2). No new features have been added.
Motor Record Version 3.4 Release Notice
This document describes changes made to the motor record and its' associated
device driver support between versions 3.3 and 3.4. Those changes are
as follows:
Device driver design error fix
A design error was discovered in the OMS device drivers (drvOms and drvOms58).
The EPICS device driver support task (i.e., tmotor) would query the OMS motion
controller for status information immediately after a motion command.
Since the state of the controller board was in the midst of changing, this
sometimes resulted in inconsistent or conflicting status information being
returned to the motor record. This problem was remedied by enforcing
a minimum time delay (16.67 ms) between a motion command and a status query.
It is difficult to enumerate the symptoms associated with this problem.
Sometimes they exhibited themselves intermittently, other times bad data
stayed in the record. Several symptoms are as follows:
- Erroneous motor stops being issued by the device support when changing
motor direction.
- Backlash occurring when the motor is moving in the same direction as
the sign of BDST.
- DVAL and RBV becoming out-of-synch. RBV would always be an old
value from the previous move.
PID Parameter Support for VME58
The motor record classifies a motor as a servo if it has two features; an
adjustable closed loop position response gain and the ability to enable/disable
closed loop position control (i.e., motor torque). A motor lacking
either of the above two features is classified as a stepper and is supported
by the standard motor record features. The following three motor record
fields support servo motors:
1. GAIN - Closed loop position response gain of the motor.
2. CNEN - Enable/disable closed loop position control request.
3. STEN - Closed loop position control status (i.e.,
enabled/disabled).
Currently, servo support is only available with OMS's VME58 device support
(i.e., VME58-[4S/8S/2S2/2S6/4S4/6S2] model boards). At driver initialization,
the driver automatically detects whether or not the underlying device supports
the use of the GAIN field and thereby classifies the motor as a stepper or
a servo. Bit#11 of the MSTA field is set on/off based on the
results of this test. If the device supports the GAIN field, then bit#11
of the MSTA is set on and all of the above servo fields are enabled.
Otherwise, they are disabled and bit#11 of the MSTA is set off. When
the servo fields are disabled, they can still be read or written to without
an error response.
The VME58 device support allows the closed loop position gain of the motor
to be set directly through the GAIN field. For the VME58, setting the
GAIN field value results in the Combined Coefficient command (i.e., KK#)
being executed with the GAIN field value as the argument to the command.
This command, in turn, sets the PID loop parameter values (with the OMS VME58,
gain changes do not take effect until the command velocity is zero).
The user can request that the closed loop position control be enabled
or disabled by setting the CNEN field nonzero or zero, respectively.
Likewise, the user can monitor the state of closed loop position control
(i.e., enabled/disabled) by reading the STEN field. See the OMS "VME58
Family User's Manual" for further details.
Command primitives feature
Three motor record fields are available to the user that can be used to
send ASCII command primitives to the servo control board at fixed, predefined,
times. Each field is defined as a character string.
1. INIT - Sent at record initialization.
2. PREM - Sent before every command string that causes motion.
3. POST - Sent after a complete motion is finished.
No error checking is done by the motor record or the device driver to
insure that the command strings are valid. Command primitives that
result in a response from the motion control board are valid, but the response
is not processed.