forked from epics_driver_modules/motorBase
Ron Sluiter
716 lines
36 KiB
HTML
716 lines
36 KiB
HTML
<!DOCTYPE html PUBLIC "-//w3c//dtd html 4.0 transitional//en">
|
|
<html>
|
|
<head>
|
|
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
|
|
<meta name="GENERATOR" content="Mozilla/4.77 [en] (X11; U; SunOS 5.8 sun4u) [Netscape]">
|
|
|
|
<meta name="Author" content="Ronald L. Sluiter">
|
|
|
|
<meta name="Description" content="Synopsis of modifications, fixes and new features for each motor record release.">
|
|
<title>EPICS Motor Record Release Notice</title>
|
|
</head>
|
|
<body>
|
|
|
|
<center>
|
|
<h1> <b><u>Motor Record Version 4.5 Release Notice</u></b></h1>
|
|
</center>
|
|
<b>!WARNING!</b><br>
|
|
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).
|
|
<center>
|
|
<h4> <u>Modifications to Existing Features</u></h4>
|
|
</center>
|
|
<b><u>Communication Retries</u></b>
|
|
<p>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).
|
|
</p>
|
|
<h4> </h4>
|
|
<h4>
|
|
<h4><u>Requirements Clarification</u></h4>
|
|
</h4>
|
|
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:<br>
|
|
<blockquote>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.</blockquote>
|
|
<blockquote>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.<br>
|
|
<br>
|
|
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.)</blockquote>
|
|
<h4><u>Bug Fix for Driver Power Monitoring error</u></h4>
|
|
The <i>Driver Power Monitoring</i> feature (available only with OMS VME58
|
|
controllers) was erroneously and randomly being enabled. This resulted
|
|
in the error message <i>Drive power failure at VME58 card# motor# </i>appearing
|
|
at the VxWorks console.
|
|
<p><b><u>Soft Channel device support modifications</u></b> </p>
|
|
<ul>
|
|
<li> Prevent record processing before "interruptAccept" is true. This
|
|
helps prevent alarms.</li>
|
|
<li> 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.</li>
|
|
<li>Lowered the priority of the "soft_motor task below the "dbCaLink"
|
|
task. This fixes the "DMOV processing before the last DRBV update"
|
|
problem.<br>
|
|
</li>
|
|
|
|
</ul>
|
|
<b><u>Bug Fix for Array Holes in VMEbus based controllers</u></b>
|
|
<p>For VMEbus based motor controllers only (i.e., OMS), a <i>hole</i>
|
|
in an array of VME based motor controller boards caused the system to crash
|
|
with a memory <i>access error</i> 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.</p>
|
|
<p>This release allows <i>holes </i>in an array of VMEbus based motor
|
|
controllers. </p>
|
|
<p><b><u>RES Field</u></b> </p>
|
|
<p>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).</p>
|
|
<p>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. <br>
|
|
</p>
|
|
<h4><u>Backlash Correction</u></h4>
|
|
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.<br>
|
|
<br>
|
|
With this release, backlash correction commands are not issued to the controller
|
|
until after the slew move is completed.<br>
|
|
<h4><u>Separa</u><b>te +/- Limit Switch status bits</b></h4>
|
|
The MSTA field has been modified by providing separate +/- limit switch status
|
|
bits. The MSTA bits are defined as follows:
|
|
<blockquote>
|
|
<ol>
|
|
<li> DIRECTION: (0:Negative, 1:Positive)</li>
|
|
<li> DONE: motion is complete.</li>
|
|
<li>PLUS_LS: plus limit switch has been hit.</li>
|
|
<li> HOMELS: state of the home limit switch.</li>
|
|
<li> Unused</li>
|
|
<li> POSITION: closed-loop position control is enabled.</li>
|
|
<li> Unused</li>
|
|
<li> HOME: if at home position.</li>
|
|
<li> PRESENT: encoder is present.</li>
|
|
<li> PROBLEM: driver stopped polling.</li>
|
|
<li> MOVING: non-zero velocity present.</li>
|
|
<li> GAIN_SUPPORT: motor supports closed-loop position control.</li>
|
|
<li>COMM_ERR: Controller communication error.</li>
|
|
<li>MINUS_LS: minus limit switch has been hit.<br>
|
|
</li>
|
|
</ol>
|
|
</blockquote>
|
|
<br>
|
|
<center>
|
|
<p><b><u>New Features</u></b></p>
|
|
</center>
|
|
|
|
<p><b><u>Advanced Control Systems and Mclennan device driver support</u></b>
|
|
</p>
|
|
<p>Mark Rivers has added device driver support for the following motor
|
|
controllers: </p>
|
|
<ul>
|
|
<li> Advanced Control Systems, Corp. model MCB-4B</li>
|
|
<li> Mclennan model PM304</li>
|
|
|
|
</ul>
|
|
|
|
<center>
|
|
<h1> <b><u>Motor Record Version 4.4 Release Notice</u></b></h1>
|
|
</center>
|
|
|
|
<center>
|
|
<h4> <u>Modifications to Existing Features</u></h4>
|
|
</center>
|
|
<b><u>Disable Travel Limits</u></b>
|
|
<p>The travel limits can be disabled by setting both dial high and
|
|
low limits equal to zero; i.e., DHLM = DLLM = 0. </p>
|
|
<p><b><u>RVAL ignored error</u></b> </p>
|
|
<p>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. </p>
|
|
<center><b><u>New Features</u></b></center>
|
|
<b><u>Jog velocity and acceleration parameters</u></b>
|
|
<p>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. </p>
|
|
<center>
|
|
<h1> <b><u>Motor Record Version 4.3 Release Notice</u></b></h1>
|
|
</center>
|
|
This release of the motor record is strictly a bug fix release; no new features
|
|
have been added.
|
|
<p><b><u>STOP field hangs record</u></b> </p>
|
|
<p>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. </p>
|
|
<p><b><u>HIDEOS support removed</u></b> </p>
|
|
<p>HIDEOS is no longer supported. MPF is the only supported alternative
|
|
to HIDEOS. <br>
|
|
</p>
|
|
<center>
|
|
<h1> <b><u>Motor Record Version 4.2 Release Notice</u></b></h1>
|
|
</center>
|
|
This release of the motor record is compatible with EPICS R3.13.2 and above.
|
|
<p><b>!WARNING!</b> <br>
|
|
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). <br>
|
|
<br>
|
|
</p>
|
|
<center>
|
|
<h4> <u>Modifications to Existing Features</u></h4>
|
|
</center>
|
|
<b><u>Precedence between field pairs</u></b>
|
|
<p>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. </p>
|
|
<p><b><u>Moving Off a Limit Switch with a Oms58 device</u></b> </p>
|
|
<p>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. </p>
|
|
<p><b><u>Separate motion commands for target and backlash moves</u></b>
|
|
</p>
|
|
<p>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. </p>
|
|
<p><b><u>Errors introduced in V4.0</u></b> </p>
|
|
<p>Unfortunately, several errors were introduced into the motor record
|
|
with V4.0. The following have been fixed: </p>
|
|
<ul>
|
|
<li> 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.</li>
|
|
<li> Jog request would not work after the state of the UEIP field was changd.</li>
|
|
<li> Backlash correction was not occurring after a JOG.</li>
|
|
<li> 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)</li>
|
|
|
|
</ul>
|
|
|
|
<center>
|
|
<h4> <b><u>New Features</u></b></h4>
|
|
</center>
|
|
<b><u>Newport PM500 device support</u></b>
|
|
<p>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. </p>
|
|
<p><b><u>Intelligent Motion Systems, Inc. IM483 device support</u></b>
|
|
</p>
|
|
<p>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, <i>
|
|
party line </i>and <i>single mode</i>, respectively (see the IMS Software
|
|
Reference Manual for details). <br>
|
|
</p>
|
|
<center>
|
|
<h1> <u>Motor Record Version 4.1 Release Notice</u></h1>
|
|
</center>
|
|
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.
|
|
<center>
|
|
<h4> <u>Modifications to Existing Features</u></h4>
|
|
</center>
|
|
|
|
<h4> <b><u>OMS VME58 retry problem</u></b></h4>
|
|
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.
|
|
<h4> <b><u>OMS Stop problem</u></b></h4>
|
|
A problem with issuing a stop command (via either the STOP or SPMG field)
|
|
was found with <b>all</b> OMS boards and <b>all </b>versions of the OMS device
|
|
drivers. The root cause of this problem is a statement in the OMS manual
|
|
<i>that is not entirely correct</i>; the AC and VL commands are not
|
|
completely queued. <br>
|
|
<br>
|
|
|
|
<center>
|
|
<h1> <u>Motor Record Version 4.0 Release Notice</u></h1>
|
|
</center>
|
|
Release 4.0 of the motor record is <u>only</u> 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.
|
|
<center>
|
|
<h4> <u>Modifications to Existing Features</u></h4>
|
|
</center>
|
|
|
|
<h4> <b><u>GAIN Field Removed</u></b></h4>
|
|
Since the GAIN field is redundant (i.e., PID parameters can be set individually)
|
|
it has been removed. <br>
|
|
|
|
<h4> <b><u>HOM[F/R] Bug Fix</u></b></h4>
|
|
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 <i>pollRate</i> defined
|
|
in the st.cmd <i>Setup</i> 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.
|
|
<p>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. <i>motorx_all.adl_V2.2</i> (which
|
|
is included with this distribution) sets the HOM[F/R] fields on when the
|
|
user presses the homing button, but is does <b>not</b> 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). <br>
|
|
</p>
|
|
<h4> <u>Initial Position</u></h4>
|
|
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.
|
|
<p>Previous releases of the motor record allowed the auto restore to
|
|
take precedence over the controller when initializing the target position
|
|
(i.e., DVAL). <br>
|
|
</p>
|
|
<h4> <u>Access Security Level</u></h4>
|
|
In order to support the new VMAX/SMAX fields, the Access Security Level for
|
|
the following fields have been changed from one to zero:
|
|
<blockquote>
|
|
<ul>
|
|
<li> MRES</li>
|
|
<li> UREV</li>
|
|
<li> VBAS</li>
|
|
<li> SBAS</li>
|
|
|
|
</ul>
|
|
</blockquote>
|
|
|
|
<h4> <u>MM4000/5 Device Driver</u></h4>
|
|
Although the previous motor record release (V3.5) had device driver support
|
|
for the MM4000, it is <b>not</b> 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:
|
|
<ol>
|
|
<li> 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.</li>
|
|
|
|
<ol>
|
|
<li> 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.</li>
|
|
<li> Since the MM4005's position cannot be set by EPICS, the initial position
|
|
of its' motors (see <i>Initial Position </i>above) will always be initialized
|
|
from the controller's value.</li>
|
|
|
|
</ol>
|
|
<li> 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 <i>remote mode</i> locks out the user from using the controller's
|
|
front panel, the motor record no longer puts the MM4000/5 in <i>remote mode</i>
|
|
. EPICS is unable to communicate with the MM4000/5 controller if it
|
|
is in <i>local</i> <i>mode</i> and the front panel is not at the top menu.
|
|
A <i>Controller communication error</i> 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.</li>
|
|
|
|
</ol>
|
|
|
|
<h4> <u>Bug Fix for OMS VME58 running on PowerPC</u></h4>
|
|
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.
|
|
<center>
|
|
<h4> <u>New Features</u></h4>
|
|
</center>
|
|
<b><u>Newport MM3000 Device Support</u></b>
|
|
<p>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: </p>
|
|
<ul>
|
|
<li> The MM3000 does not support a generic <i>Load Position </i>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.</li>
|
|
<li> The only position units the MM3000 will communicate with the host
|
|
in, are either encoder ticks or stepper motor steps.</li>
|
|
|
|
</ul>
|
|
|
|
<h4> <u>Uninitialized Oms/Oms58 Driver Error Check</u></h4>
|
|
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.)
|
|
<h4> <u>Maximum Velocity Fields (VMAX/SMAX)</u></h4>
|
|
Maximum velocity fields have been added; VMAX in EGU/s units and SMAX in
|
|
RPS units.
|
|
<p>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.
|
|
</p>
|
|
<p>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 <i>request files. </i>VMAX/SMAX have Access Security Level
|
|
zero. </p>
|
|
<p><i>motorx_setup_1.7.adl</i> (which is included with this distribution)
|
|
includes support for the maximum velocity fields. <br>
|
|
</p>
|
|
<center>
|
|
<h1> <u>Motor Record Version 3.5 Release Notice</u></h1>
|
|
</center>
|
|
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:
|
|
<center>
|
|
<h4> <u>Modifications to Existing Features</u></h4>
|
|
</center>
|
|
|
|
<h4> <u>Command Primitives</u></h4>
|
|
<b>This feature is available only with OMS VME8/44/58 or Newport MM4000 device
|
|
support (i.e., devOms, devOms58, devMM4000)</b>. 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:
|
|
<blockquote> 1. INIT - Sent at record initialization. <br>
|
|
2. PREM - Sent before every command string that causes motion. <br>
|
|
3. POST - Sent after a complete motion is finished <b>or when an overtravel
|
|
limit switch is detected</b>.</blockquote>
|
|
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.
|
|
<h4> <u>Servo related Fields</u></h4>
|
|
|
|
<ul>
|
|
<li> 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.</li>
|
|
<li> The <i>status enable </i>field (i.e., STEN) has been eliminated; the
|
|
<i>control enable </i>field (i.e., CNEN) is used to both control
|
|
the torque enable and show its' status.</li>
|
|
|
|
</ul>
|
|
|
|
<h4> <u>Unused Fields Removed</u></h4>
|
|
The following unused motor record fields were deleted: MODE, TRAK, MDEL,
|
|
ADEL, CVEL, POSM, ALST, MLST <br>
|
|
<br>
|
|
|
|
<center>
|
|
<h4> <u>New Features</u></h4>
|
|
</center>
|
|
|
|
<h4> <u>Device Directives</u></h4>
|
|
Device directive definition and processing:
|
|
<ul>
|
|
<li> Valid only in the INIT field.</li>
|
|
<li> Must be identified by the following;</li>
|
|
|
|
<blockquote> <li> First character of INIT string must be a '@'.</li>
|
|
<li> One or more characters followed by a terminating '@'; i.e., device
|
|
directives must have nonzero length.</li>
|
|
<li> A valid device directive; currently, only "DPM_ON".</li>
|
|
</blockquote>
|
|
<li> 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.</li>
|
|
|
|
</ul>
|
|
|
|
<h4> <u>Driver Power Monitoring</u></h4>
|
|
|
|
<ul>
|
|
<li> This feature is only available with the OMS VME58 device support.</li>
|
|
<li> The 8 User I/O signals are assigned to the 8 possible VME58 axes as
|
|
follows:</li>
|
|
|
|
</ul>
|
|
|
|
<ul>
|
|
|
|
User I/O #0 <> X axis <br>
|
|
|
|
" " 1 <> Y " <br>
|
|
|
|
..................... <br>
|
|
|
|
" " 7 <> S " <li> 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.</li>
|
|
<li> 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.</li>
|
|
<li> 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#??".</li>
|
|
|
|
</ul>
|
|
|
|
<h4> <u>Soft Channel Device Support</u></h4>
|
|
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.
|
|
<p>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: <br>
|
|
<br>
|
|
</p>
|
|
<center>
|
|
<table border="1" nosave="">
|
|
<tbody>
|
|
<tr align="center" nosave="">
|
|
<td nosave=""><u>Link</u></td>
|
|
<td><u>Link Type</u></td>
|
|
<td> <u>Associated Field</u></td>
|
|
</tr>
|
|
<tr>
|
|
<td>OUT*</td>
|
|
<td>DBOUTPUT</td>
|
|
<td>
|
|
<center>DVAL</center>
|
|
</td>
|
|
</tr>
|
|
<tr align="center" nosave="">
|
|
<td nosave="">STOO</td>
|
|
<td>DBOUTPUT</td>
|
|
<td align="center" nosave="">STOP</td>
|
|
</tr>
|
|
<tr align="center" nosave="">
|
|
<td nosave="">DINP</td>
|
|
<td>DBINPUT</td>
|
|
<td>DMOV</td>
|
|
</tr>
|
|
<tr>
|
|
<td>RDBL*</td>
|
|
<td>DBINPUT</td>
|
|
<td>
|
|
<center>DRBV</center>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>RINP</td>
|
|
<td>DBINPUT</td>
|
|
<td>
|
|
<center>RMP</center>
|
|
</td>
|
|
</tr>
|
|
|
|
</tbody>
|
|
</table>
|
|
</center>
|
|
|
|
<center>
|
|
<p>* - Not a new field, but a new function provided only by soft
|
|
channel device support.</p>
|
|
</center>
|
|
|
|
<p>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 <b>not</b> dynamically retargetable. </p>
|
|
<p>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. <br>
|
|
<br>
|
|
</p>
|
|
<h4> <u>Newport MM4000 Device Support</u></h4>
|
|
This is <a href="http://cars1.uchicago.edu/software/dev_mm4000.html">Mark
|
|
Rivers MM4000</a>
|
|
device support ported to the latest motor record release. The following
|
|
are the functional differences between Mark's version 1.01 and <br>
|
|
this release:
|
|
<blockquote>
|
|
<ol>
|
|
<li> 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.</li>
|
|
<li> Servo support has been extended to the MM4000 controller.</li>
|
|
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<h4> <u>PID Gain Parameters</u></h4>
|
|
With this release there are two ways to set the motor controllers' PID parameters;
|
|
either through the <i>Combined Gain </i>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:
|
|
<blockquote><u>For the MM4000</u>
|
|
<u>For all OMS controllers</u></blockquote>
|
|
|
|
<ul>
|
|
<li> CKP = GAIN
|
|
CKP = 1999.9 * GAIN</li>
|
|
<li> CKI = 2 * GAIN
|
|
CKI = 2 * 1999.9 * GAIN</li>
|
|
<li> CKD = 3 * GAIN
|
|
CKD = 3 * 1999.9 * GAIN</li>
|
|
|
|
</ul>
|
|
Note that setting any of the individual PID record fields is <b>not</b> reflected
|
|
in the value of the GAIN field.
|
|
<h4> <u>Highland V544 Device Support</u></h4>
|
|
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. <br>
|
|
|
|
<center>
|
|
<h1> <u>Motor Record Version 3.4 Release Notice</u></h1>
|
|
</center>
|
|
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:
|
|
<h3> <u><font size="+0">Device driver design error fix</font></u></h3>
|
|
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.
|
|
<p>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: </p>
|
|
<blockquote>
|
|
<ul>
|
|
<li> Erroneous motor stops being issued by the device support when changing
|
|
motor direction.</li>
|
|
<li> Backlash occurring when the motor is moving in the same direction
|
|
as the sign of BDST.</li>
|
|
<li> DVAL and RBV becoming out-of-synch. RBV would always be an old
|
|
value from the previous move.</li>
|
|
|
|
</ul>
|
|
</blockquote>
|
|
|
|
<h3> <u><font size="+0">PID Parameter Support for VME58</font></u></h3>
|
|
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:
|
|
<p> 1. GAIN - Closed loop position response gain
|
|
of the motor. <br>
|
|
2. CNEN - Enable/disable closed loop position control request. <br>
|
|
3. STEN - Closed loop position control status (i.e., <br>
|
|
enabled/disabled). </p>
|
|
<p>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. </p>
|
|
<p>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). </p>
|
|
<p>The user can request that the closed loop position control
|
|
be enabled or disabled by setting the CNEN field nonzero or zero, respectively.
|
|
<br>
|
|
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. </p>
|
|
<h3> <u><font size="+0">Command primitives feature</font></u></h3>
|
|
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.
|
|
<p> 1. INIT - Sent at record initialization. <br>
|
|
2. PREM - Sent before every command string that causes motion. <br>
|
|
3. POST - Sent after a complete motion is finished. </p>
|
|
<p>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. <br>
|
|
<br>
|
|
</p>
|
|
</body>
|
|
</html>
|