forked from epics_driver_modules/motorBase
kpetersn
2554 lines
99 KiB
HTML
2554 lines
99 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
<html xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<meta content="Kevin Peterson" name="Author" />
|
|
<meta content="Synopsis of modifications, fixes and new features for each motor record release."
|
|
name="Description" />
|
|
<title>EPICS Motor Record Release R6-10 Notice</title>
|
|
<meta content="Notification of bug fixes, functional changes and new features." name="description" />
|
|
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type" />
|
|
</head>
|
|
<body>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 6-11 Release Notice</b></h1>
|
|
</div>
|
|
|
|
<div style="text-align: left">
|
|
<p>
|
|
See release notes on github: <a href="https://github.com/epics-modules/motor/releases/tag/R6-11">https://github.com/epics-modules/motor/releases/tag/R6-11</a>
|
|
</p>
|
|
</div>
|
|
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 6-10-1 Release Notice</b></h1>
|
|
</div>
|
|
|
|
<div style="text-align: left">
|
|
<p>
|
|
See release notes on github: <a href="https://github.com/epics-modules/motor/releases/tag/R6-10-1">https://github.com/epics-modules/motor/releases/tag/R6-10-1</a>
|
|
</p>
|
|
</div>
|
|
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 6-10 Release Notice</b></h1>
|
|
</div>
|
|
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>OMS support</b>
|
|
</p>
|
|
<p>
|
|
<a href="https://github.com/rsluiter">Ron Sluiter</a> added a check for an invalid MAXv interrupt level (IRQ=1)
|
|
(<a href="https://github.com/epics-modules/motor/commit/1196bbe4df5968ae4ac05c142a9f4be93827d06e">1196bbe4df5968ae4ac05c142a9f4be93827d06e</a>)
|
|
</p>
|
|
<p>
|
|
<a href="https://github.com/rsluiter">Ron Sluiter</a> added a check for a new MAXv failure mode where the board reboots after the 1st command with response
|
|
(<a href="https://github.com/epics-modules/motor/commit/e604c9588a087228dc6c0333818e00113df841ea">e604c9588a087228dc6c0333818e00113df841ea</a>)
|
|
</p>
|
|
<p>
|
|
<a href="https://github.com/rsluiter">Ron Sluiter</a> added an optional test for VME58 failure mode where the board reboots after the 1st motion related command
|
|
(<a href="https://github.com/epics-modules/motor/commit/4f54eb502bb1e4157db9a0587cfdbabd66de0c95">4f54eb502bb1e4157db9a0587cfdbabd66de0c95</a>)
|
|
</p>
|
|
</div>
|
|
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Aerotech A3200 support</b>
|
|
</p>
|
|
<p>
|
|
<a href="https://github.com/rsluiter">Ron Sluiter</a> Removed the "Task number" argument from A3200AsynConfig and switched to using Task #2 for the ASCII Interface
|
|
(<a href="https://github.com/epics-modules/motor/commit/a52ec2f62ff34b30597bccc7de9d70b4d2ed7f86">a52ec2f62ff34b30597bccc7de9d70b4d2ed7f86</a>)
|
|
</p>
|
|
</div>
|
|
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Newport support</b>
|
|
</p>
|
|
<p>
|
|
<a href="https://github.com/MarkRivers">Mark Rivers</a> modified the ESP300 driver so that it correctly determines the resolution when open-loop steppers are used
|
|
(<a href="https://github.com/epics-modules/motor/commit/5245991323fb8c73cd6383e064da7b02c2629fea">5245991323fb8c73cd6383e064da7b02c2629fea</a>)
|
|
</p>
|
|
<p>
|
|
<a href="https://github.com/MarkRivers">Mark Rivers</a> changed the XPS PositionCompare API
|
|
(<a href="https://github.com/epics-modules/motor/commit/44351c99d92837cbb283b21877a87ecc821875e0">44351c99d92837cbb283b21877a87ecc821875e0</a>) and made numerous improvements to the PositionCompare functionality.
|
|
</p>
|
|
</div>
|
|
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Motor Record improvments</b>
|
|
</p>
|
|
<p>
|
|
<a href="https://github.com/jmdewart">jmdewart</a> & <a href="https://github.com/klauer">Ken Lauer</a> changed the acceleration calculation so that VBAS is ignored when VELO==VBAS
|
|
(<a href="https://github.com/epics-modules/motor/commit/4b89359e1cc1b411f974c0733bdf0b70df303aa8">4b89359e1cc1b411f974c0733bdf0b70df303aa8</a>)
|
|
</p>
|
|
<p>
|
|
<a href="https://github.com/rsluiter">Ron Sluiter</a> changed the motor record logic so that the motor is stopped if URIP=Yes and RDBL read returns an error
|
|
(<a href="https://github.com/epics-modules/motor/commit/220d18fcff89507a236152bd17aa48e5f13ca471">220d18fcff89507a236152bd17aa48e5f13ca471</a>)
|
|
</p>
|
|
<p>
|
|
<a href="https://github.com/timmmooney">Tim Mooney</a> added a field, IGSET, to allow the SET field to be ignored.
|
|
More info on why this was desirable can be found in <a href="https://github.com/epics-modules/motor/pull/53">pull request #53</a>.
|
|
(<a href="https://github.com/epics-modules/motor/commit/5cad105357739d603218502eb38be20ee736b4ee">5cad105357739d603218502eb38be20ee736b4ee</a>)
|
|
</p>
|
|
<p>
|
|
<a href="https://github.com/timmmooney">Tim Mooney</a> modified the motor record's SYNC functionality so that it works when URIP=True
|
|
(<a href="https://github.com/epics-modules/motor/commit/ac900b90615ef650f13a9f21a5f1c145c0402408">ac900b90615ef650f13a9f21a5f1c145c0402408</a>)
|
|
</p>
|
|
</div>
|
|
|
|
<div style="text-align: center">
|
|
<h4>
|
|
New Features</h4>
|
|
</div>
|
|
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>AMCI ANG1 support</b>
|
|
</p>
|
|
<p>
|
|
<a href="https://github.com/kurtgoetze">Kurt Goetze</a> added support for the AMCI ANG1 controller/driver
|
|
(<a href="https://github.com/epics-modules/motor/commit/8966aeabf292874de8c78754e95e14cde1f1c776">8966aeabf292874de8c78754e95e14cde1f1c776</a>) and made numerous improvements to the PositionCompare functionality.
|
|
</p>
|
|
</div>
|
|
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Newport CONEX-PP support</b>
|
|
</p>
|
|
<p>
|
|
<a href="https://github.com/MarkRivers">Mark Rivers</a> added support for the CONEX-PP series to the AG_CONEX driver
|
|
(<a href="https://github.com/epics-modules/motor/commit/2b853366f48230356c869a46691acbd8c7391810">2b853366f48230356c869a46691acbd8c7391810</a>) and made numerous improvements to the PositionCompare functionality.
|
|
</p>
|
|
</div>
|
|
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>iocsh scripts</b>
|
|
</p>
|
|
<p>
|
|
<a href="https://github.com/keenanlang">Keenan Lang</a> add iocsh setup scripts for many motor controllers
|
|
(<a href="https://github.com/epics-modules/motor/commit/17d10a8158ba5ca23bfc97133901d8d6e859f1ac">17d10a8158ba5ca23bfc97133901d8d6e859f1ac</a>
|
|
&
|
|
<a href="https://github.com/epics-modules/motor/commit/a87835c14a20a8e11745e16591d031fb674f0e14">a87835c14a20a8e11745e16591d031fb674f0e14</a>)
|
|
</p>
|
|
</div>
|
|
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>PI E-517 support</b>
|
|
</p>
|
|
<p>
|
|
<a href="https://github.com/Brudhu">Bruno Luvizotto</a> added files for supporting PIE517 piezo controller
|
|
(<a href="https://github.com/epics-modules/motor/commit/f31ed90b255a554a1930ac721d595ade0c8095a2">f31ed90b255a554a1930ac721d595ade0c8095a2</a>)
|
|
</p>
|
|
</div>
|
|
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>New Focus 874x support</b>
|
|
</p>
|
|
<p>
|
|
<a href="https://github.com/waynelewis">Wayne Lewis</a> added support for the NewFocus 874x series of controllers
|
|
(<a href="https://github.com/epics-modules/motor/commit/634e49d5076d87fefbd875cd0700e7feb6d062e3">634e49d5076d87fefbd875cd0700e7feb6d062e3</a>)
|
|
</p>
|
|
</div>
|
|
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>asynMotor support</b>
|
|
</p>
|
|
<p>
|
|
<a href="https://github.com/mp49">Matthew Pearson</a> added parameters to asynMotorController to deal with automatic amplifier control via setClosedLoop.
|
|
(<a href="https://github.com/epics-modules/motor/commit/36dfab4a78725866fab5bd212c4c128a86e9f044">36dfab4a78725866fab5bd212c4c128a86e9f044</a>)
|
|
</p>
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 6-9 Release Notice</b></h1>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b></b>
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
New Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Micronix Asyn Motor Support</b>
|
|
</p>
|
|
<p>
|
|
Kevin Peterson (APS) added asyn motor support for the Micronix MMC-200 & MMC-100 Controllers.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>MicroMo MVP2001 Asyn Motor Support</b>
|
|
</p>
|
|
<p>
|
|
Kevin Peterson (APS) added asyn motor support for the MicroMo MVP2001 Controller.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Trajectory support</b>
|
|
</p>
|
|
<p>
|
|
Tim Mooney (APS) added trajectory support for a single-motor Aerotech Ensemble
|
|
</p>
|
|
<p>
|
|
Tim Mooney (APS) added trajectory support for the Pro-Dex OMS MAXv
|
|
</p>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>ProfileMove support</b>
|
|
</p>
|
|
<p>
|
|
Mark Rivers (GSECARS) added ProfileMoveMode to support absolute and relative moves.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Newport AG_CONEX and AG_UC controllers</b>
|
|
</p>
|
|
<p>
|
|
Mark Rivers (GSECARS) made changes to support CONEX-CC servo controller; it has
|
|
KD; supports limits, velocity, acceleration; fixed homing problems
|
|
</p>
|
|
<p>
|
|
Mark Rivers (GSECARS) made changes to support AG-UC8 model that requires CC command
|
|
to select a channel pair; add delay between writes for all commands on all ARCHs.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>SmarAct MCS Motor Support</b>
|
|
</p>
|
|
<p>
|
|
Kevin Peterson (APS) added support for rotary stages.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>motorUtil improvements</b>
|
|
</p>
|
|
<p>
|
|
Kevin Peterson (APS) made the following improvments to motorUtil:
|
|
<ul>
|
|
<li>The listMovingMotors function can now be called on non-VxWorks iocs</li>
|
|
<li>The name of the motor is written to a waveform record when its DMOV field changes,
|
|
enabling smart clients to maintain a list of moving motors.</li>
|
|
</ul> </p>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Phytron I1AM01 Stepper Motor Controller Support</b>
|
|
</p>
|
|
<p>
|
|
Tom Slejko and Bor Marolt (Cosylab d.d.) added asyn motor support for the Phytron I1AM01 Stepper Motor Controller.
|
|
</p>
|
|
</div>
|
|
|
|
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 6-8 Release Notice</b></h1>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>!WARNING!</b><br />
|
|
motorRecord.dbd has been modified. This requires rebuilding any and all user
|
|
trees (i.e., <ioctop>) that load the motor record.
|
|
</p>
|
|
<p>
|
|
<b>Newport XPS Asyn Motor (Phase-2) Support</b>
|
|
</p>
|
|
<p>
|
|
The stepsPerUnit argument of XPSConfigAxis has changed from an integer to a string
|
|
to make phase-2 consistent with phase-3 support. Failing to change the stepsPerUnit
|
|
argument to a string results in parameter-out-of-range errors when attempting to
|
|
move XPS motors.
|
|
</p>
|
|
<p>
|
|
<b>Newport ESP300</b>
|
|
</p>
|
|
<p>
|
|
Prior to this release, the ESP300 driver used the controller's resolution to scale
|
|
the EGUtoRAWbacktoEGU conversion that is done between motor record and device driver
|
|
support. With R6.8 the driver uses the motor record's MRES to scale this conversion.
|
|
Users should now set the MRES like any other motor; i.e., to the precision of the
|
|
stage.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Soft-travel limits</b>
|
|
</p>
|
|
<p>
|
|
Several changes have been made with regard to the motor record's soft-travel limits
|
|
(LVIO field).</p>
|
|
<ul>
|
|
<li>Since the soft-travel limits (HLM/LLM, DHLM/DLLM) are not defined until after
|
|
a successful home search is performed, error checks have been removed from the home
|
|
search request (HOMF/HOMR). </li>
|
|
<li>All moves out of the invalid soft-limit travel range, toward the valid range,
|
|
are allowed. </li>
|
|
</ul>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Retry Deadband </b>
|
|
</p>
|
|
<p>
|
|
The retry deadband (RDBD) field no longer limits the smallest allowed move. The
|
|
size of a move is now only limited by the motor resolution (MRES).
|
|
</p>
|
|
</div>
|
|
<div style="text-align: left">
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
New Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Physik Instrumente (PI) Asyn Motor Support</b>
|
|
</p>
|
|
<p>
|
|
Steffen Rau (Physik Instrumente GmbH & Co.) has added asyn motor support for PI
|
|
motion controllers that use the GCS2 (General Command Set) command language. This
|
|
support resides in the <motor>/motorApp/PIGCS2Src/ directory of the motor module.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>PI micos SMC hydra Asyn Motor Support</b>
|
|
</p>
|
|
<p>
|
|
Kevin Peterson (APS) added support for asyn motor support for the PI micos SMC hydra
|
|
controller.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Schneider Electric (IMS) MDrive/MForce Asyn Motor Support</b>
|
|
</p>
|
|
<p>
|
|
Nia Fong (SLAC) added asyn motor support for the Schneider Electric (IMS) MDrive/MForce
|
|
controller that uses the MCode command language.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Newport XPS Support</b>
|
|
</p>
|
|
<p>
|
|
Kevin Peterson (APS) added a sequence program, xpsSlave.st, that allows master/slave
|
|
mode to be used with any version of the XPS motor support.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Newport Hexapod Asyn Motor Support</b>
|
|
</p>
|
|
<p>
|
|
Kevin Peterson (APS) added asyn motor support for the Newport Hexapod controller.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>nPoint C300 Asyn Motor Support</b>
|
|
</p>
|
|
<p>
|
|
Kevin Peterson (APS) added asyn motor support for the nPoint C300 piezo controller.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>OMS MAXv and MAXnet Asyn Motor Support</b>
|
|
</p>
|
|
<p>
|
|
Jens Eden (PTB) added asyn motor support for both the OMS MAXv and the OMS MAXnet
|
|
controllers.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Newport Agilis UC series Asyn Motor Support</b>
|
|
</p>
|
|
<p>
|
|
Mark Rivers (APS) added asyn motor support for the Newport Agilis UC series of controllers.
|
|
</p>
|
|
</div>
|
|
<p>
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 6-6 and 6-7 Release Notice</b></h1>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Aerotech Ensemble</b>
|
|
</p>
|
|
<ul>
|
|
<li>Since the Ensemble network connection requires period communication from the host
|
|
to prevent the Ensemble from closing the network socket, the Ensemble support based
|
|
on the old device driver architecture (phase 1) was removed with this release. The
|
|
asyn motor architecture supports continuous, periodic updates; the old architecture
|
|
does not. </li>
|
|
<li>With this release, the Aerotech Ensemble driver only supports 4.01.00 Ensemble
|
|
version firmware and above. </li>
|
|
<li>In order to support SCURVE trajectories, the move commands have been changed from
|
|
MOVE[ABS/INC] to LINEAR. Currently, the SCURVE command can only be set from an asyn
|
|
record (e.g., SCURVE 75). </li>
|
|
<li>There is a problem with initiating a home search with the Aerotech Ensemble motor
|
|
controller with EPICS. The problem is that the EPICS Ensemble driver uses Aerotech's
|
|
ASCII communication protocol and that protocol blocks all communication on ASCII
|
|
communication ports during a home search. Consequently, once a home search is started
|
|
from EPICS, it is unable to stop it. With release R6-6, the home search function
|
|
was commented out of the Ensemble driver. Users that need to perform a home search
|
|
should do it from Aerotech's IDE software, which can abort a home search. The Home
|
|
Search ability will be restored in a future release. </li>
|
|
</ul>
|
|
<p>
|
|
<b>OMS</b>
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
Watchdog and reboot error checks have been added to both the VME58 and MAXv (with
|
|
firmware ver:1.33 and above) device drivers. The EPICS drivers check for a reboot
|
|
error or Watchdog timeout (MAXv) with every motor status update.
|
|
</p>
|
|
<p>
|
|
If an error occurs, an error message is sent to both the errlog task and the console.
|
|
Since a reboot or watchdog timer trip indicates that the controller has rebooted
|
|
and no longer has valid motor positions, the controller is disabled and is no longer
|
|
available to EPICS until after the VME crate has been rebooted. Other OMS boards
|
|
in the system are unaffected by this scenario.
|
|
</p>
|
|
<p>
|
|
To better communicate this problem to the user, several medm displays have been
|
|
changed. Small displays (motorx_tiny.adl, motorx.adl) will show a yellow border
|
|
around their position readback values. Larger displays (motorx_more.adl, motorx_all.adl)
|
|
will display the message "Controller Error" in yellow. The following error message
|
|
at the console and/or in the IOC errlog is definitive;
|
|
</p>
|
|
<p>
|
|
"***MAXv card #<card>Disabled*** Watchdog Timeout CTR =<ctr>"
|
|
</p>
|
|
<p>
|
|
"***VME58 card #<card>Disabled*** Reboot Detected."
|
|
</p>
|
|
</li>
|
|
<li>A third argument was added to the MAXvConfig() call; the SSI based absolute encoder
|
|
bit flag.
|
|
<p>
|
|
MAXvConfig(0, config0, 0x00)
|
|
</p>
|
|
Bit #0 for Axis X, bit #1 for Axis Y, etc.. Set a bit flag to '1' for absolute encoder
|
|
values; '0' for the standard incremental encoder values. </li>
|
|
</ul>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
New Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Hytec 8601</b>
|
|
</p>
|
|
<p>
|
|
Asyn motor driver support was added by Hytec for the 8601 stepper motor driver.
|
|
</p>
|
|
<p>
|
|
<b></b>
|
|
</p>
|
|
<p>
|
|
</p>
|
|
</div>
|
|
<p>
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 6-5 Release Notice</b></h1>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>64-bit compatability</b>
|
|
</p>
|
|
<p>
|
|
64-bit compile problems with the PI E816 and Aerotech Ensemble device drivers were
|
|
fixed. Mark Rivers made numerous changes to eliminate all 64-bit compiler warning
|
|
messages.
|
|
</p>
|
|
<b>OMS MAXv</b>
|
|
<p>
|
|
Dirk Zimoch (PSI) fixed a bug in the OMS MAXv driver that caused the set_status()
|
|
function to overwrite the home switch status in the response string
|
|
</p>
|
|
<p>
|
|
<b>asyn motor</b>
|
|
</p>
|
|
<ul>
|
|
<li>Matthew Pearson (Diamond) fixed a bug on Newport XPS and MM4000 asyn motor port
|
|
drives that was causing idle polling to interfere with setting positions and prevented
|
|
auto save/restore from working. </li>
|
|
<li>The asynMotor device support would leave a motor-in-motion indicator on if the
|
|
motor record issued a LOAD_POS command before the 2nd pass of device support initialization.
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
<b>Highland Technologies</b>
|
|
</p>
|
|
<p>
|
|
Support for the Highland Technologies V540 motor controller has been removed.
|
|
</p>
|
|
<p>
|
|
<b>Aerotech Ensemble</b>
|
|
</p>
|
|
<ul>
|
|
<li>Aerotech Ensemble device driver fixes for incorrect Jog speeds, support for a
|
|
negative PosScaleFactor parameter and detecting maximum travel limit switch faults.
|
|
</li>
|
|
<li>This is the last release to include the old Ensemble device driver architecture
|
|
version. See below. </li>
|
|
</ul>
|
|
<p>
|
|
<b>RES field deleted</b>
|
|
</p>
|
|
<p>
|
|
The RES field was removed from the motor record database definition with this release
|
|
(R6-5). The RES field has been depreciated by the MRES field since R4-5.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
New Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Aerotech Soloist and Ensemble motor controller support</b>
|
|
</p>
|
|
<p>
|
|
Two new drivers from Aerotech were add; an asyn motor version of the Ensemble and
|
|
the Soloist under the old driver architecture. Since the Ensemble network connection
|
|
requires period communication from the host to prevent the Ensemble from closing
|
|
the network socket, the Ensemble support based on the old device driver architecture
|
|
will be removed after R5-6. The asyn motor architecture supports continuous, periodic
|
|
updates; the old architecture does not.
|
|
</p>
|
|
<p>
|
|
<b>ADEL and MDEL fields added</b>
|
|
</p>
|
|
<p>
|
|
Matthew Pearson (Diamond) added support for the ADEL and MDEL motor record fields.
|
|
Unlike most records, the ADEL/MDEL fields in the motor record apply to the User
|
|
Readback Value (RBV). See the motorRecord.html document for details.
|
|
</p>
|
|
<p>
|
|
<b>Synchronize field (SYNC)</b>
|
|
</p>
|
|
<p>
|
|
When the SYNC field is set to Yes(1) the record sets the Drive fields (VAL/DVAL/RVAL)
|
|
to their readback values (RBV/DRBV/RRBV) and sets SYNC field back to No(0).
|
|
</p>
|
|
</div>
|
|
<p>
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 6-4 Release Notice</b></h1>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Stale SET position data from OMS VME58 controllers.</b>
|
|
</p>
|
|
<p>
|
|
A problem with certain OMS VME58 firmware versions (2.24-8S and all 2.35 versions)
|
|
has arisen since modifications made under R6-3. When the user sets the motor record's
|
|
position, the previous target and readback positions are read from the controller
|
|
on the next update. This occurs with the previous release (R6-3) because the "stale
|
|
data delay" was changed from 10ms to zero for the drvOms58 driver.
|
|
</p>
|
|
<p>
|
|
With this release the driver searches all VME58 board ID's for either 2.24-8S or
|
|
any 2.35 version. If any board is found with these versions, the "stale data delay"
|
|
is set to a non-zero value for all VME58 boards in the system.
|
|
</p>
|
|
<p>
|
|
<b>"tdir=" error messages</b>
|
|
</p>
|
|
<p>
|
|
A problem was reported by Emma Shepherd (Diamond) with the previous release if the
|
|
"Use RDBL Link" field (URIP) was set to "Yes". The NTM logic was sending stop commands
|
|
and issuing the "tdir=.." message to the console if the RDBL link was used. This
|
|
error was the result of changes to the NTM logic in R6-3.
|
|
</p>
|
|
<p>
|
|
With this release, the NTM logic is restored to using feedback rather than reference
|
|
positions. In addition, an "NTM deadband factor" field (NTMF) is added to allow
|
|
the user to set the NTM deadband as follows;
|
|
</p>
|
|
<p>
|
|
NTM deadband = NTMF * (|BDST| + RDBD)
|
|
</p>
|
|
<p>
|
|
NTMF must be >= 2. If properly configured, the NTM deadband prevents NTM logic from
|
|
issuing a STOP command at the end of a DC motor move that overshoots its' target
|
|
position.
|
|
</p>
|
|
<p>
|
|
<b>Access Security Level changes</b>
|
|
</p>
|
|
<p>
|
|
Major changes have been made to the Access Security Level (ASL) attribute of the
|
|
motor record fields. With previous releases, the following fields were set to ASL=0;
|
|
FOF, VOF, SSET, SUSE, VBAS, VMAX, SBAS, SMAX, UREV and MRES. All other fields were
|
|
set to ASL=1 by default.
|
|
</p>
|
|
<p>
|
|
With this release, the policy is to set all the fields that the user requires to
|
|
do the following to ASL = 0;</p>
|
|
<ul>
|
|
<li>move a motor; (VAL, DVAL, RVAL, TWF, TWR, TWV, RLV, JOGF, JOGR) </li>
|
|
<li>stop a motor; (STOP, SPMG) </li>
|
|
<li>enable/disable motor torque; (CNEN) </li>
|
|
<li>set the position of a motor; (SSET, SUSE, SET) </li>
|
|
<li>set the "user" offset of a motor; (FOF, VOF, FOFF,OFF) </li>
|
|
<li>update the status of a motor; (STUP) </li>
|
|
<li>adjust or turn off backlash; (BDST) </li>
|
|
</ul>
|
|
<p>
|
|
All other fields are set to ASL = 1.
|
|
</p>
|
|
<p>
|
|
This means that out of the list of fields that were previously set to ASL=0; VBAS,
|
|
VMAX, SBAS, SMAX, UREV and MRES are now set to ASL=1.
|
|
</p>
|
|
<p>
|
|
<b>OMS MAXv A24/A32 VMEbus addressing bug fix</b>
|
|
</p>
|
|
<p>
|
|
Previous releases had a problem with the OMS MAXv device driver when it was configured
|
|
for more than one board, and, either A24 or A32 addressing was specified. The driver
|
|
was not sizing the address space occupied by each MAXv correctly.
|
|
</p>
|
|
<p>
|
|
<b>asyn motor archtecture updates</b>
|
|
</p>
|
|
<ul>
|
|
<li>Motor record GET_INFO commands were not supported by the asyn motor archtecture
|
|
in previous releases. </li>
|
|
<li>A motor record bug was fixed that caused unscheduled retries to occur with asyn
|
|
motor. </li>
|
|
</ul>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
New Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Deferred moves for asyn motors</b>
|
|
</p>
|
|
<p>
|
|
The asyn motor framework now supports a flag to indicate that moves should be deferred.
|
|
When at zero, moves proceed as normal. When set to one, moves should be deferred
|
|
and remembered by the controller driver, but not executed immediately. When set
|
|
back to zero, the controller driver should then start all the moves (or at least
|
|
moves to the last requested demand positions) that have been deferred, as near to
|
|
simultaneously as is possible for the particular model of controller. The flag is
|
|
implemented per-controller, so all axes on a particular controller instance are
|
|
affected, but axes on other controllers via the same driver are unaffected.
|
|
</p>
|
|
<p>
|
|
It is the responsibility of the motor controller driver to actually provide such
|
|
functionality, or to give an error if the parameter is not recognised. Currently
|
|
the Newport XPS controller driver and the Delta Tau PMAC driver (in the tpmac module
|
|
available from Diamond) support this.
|
|
</p>
|
|
<p>
|
|
To use the flag, connect to any asyn port/addr combination on the controller, using
|
|
the parameter "DEFER". e.g. for a bo record, use DTYP=asynUInt32Digital, OUT=@asynMask(port,1,1)DEFER,
|
|
ZNAM="Go", ONAM="Defer"
|
|
</p>
|
|
<p>
|
|
<b>64-bit compatiablity</b>
|
|
</p>
|
|
<p>
|
|
Previous releases of the motor record distribution would not compile for 64-bit
|
|
platforms. Numerous minor modifications were made for this release to attain 64-bit
|
|
compatibility. Note that at the time of writing (03/14/08), this release was successfully
|
|
compiled on a Linux Fedora Core 6 x86_64 host using gcc version 4.1.2, but there
|
|
are bugs. Since EPICS base (R3.14.9) has not had all the bugs wrung out (Mantis
|
|
ID's #309, #310), there are no immediate plans to debug 64-bit related problems.
|
|
</p>
|
|
<p>
|
|
<b>attocube systems AG ANC150</b>
|
|
</p>
|
|
<p>
|
|
Ron Sluiter added support for the attocube systems AG ANC150 Piezo Step Controller.
|
|
</p>
|
|
<p>
|
|
<b>Aerotech's Ensemble</b>
|
|
</p>
|
|
<p>
|
|
Chad Weimer (Aerotech) added support for Aerotech's Ensemble family of digital servo
|
|
controllers.
|
|
</p>
|
|
<p>
|
|
<b>Physik Instrumente GmbH & Co. Model E-816</b>
|
|
</p>
|
|
<p>
|
|
John Hammonds added support of the Physik Instrumente (PI) GmbH & Co. E-816
|
|
motor controller.
|
|
</p>
|
|
</div>
|
|
<p>
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 6.3 Release Notice</b></h1>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>save/restore of motor positions</b>
|
|
</p>
|
|
<p>
|
|
Mark Rivers found and fixed a bug in the motor record that resulted in motor positions
|
|
not being initialized from save/restore at boot-up if the retry deadband field (RDBD)
|
|
was not included in a save set.
|
|
</p>
|
|
<p>
|
|
<b>motorUtil error message</b>
|
|
</p>
|
|
<p>
|
|
A bug was introduced into the shell command "motorUtilInit()" affecting these versions
|
|
of the motor distribution; R6-2, R6-2-1 and R6-2-2. This bug resulted in the erroneous
|
|
error message; "motorUtilInit: Prefix %c: has more than 53 characters. Exiting"
|
|
</p>
|
|
<p>
|
|
<b>DC motor support</b>
|
|
</p>
|
|
<p>
|
|
Two changes were made to the motor record to better support DC motors.</p>
|
|
<ul>
|
|
<li>With this release, if retries are disabled (RTRY=0), then all moves are done in
|
|
absolute mode. This allows a DC motor user to have the readback values calculated
|
|
based on either the local encoder (UEIP) or the readback link (URIP), but still
|
|
have all moves commanded in absolute mode. Previous releases the of the motor record
|
|
would use relative moves if either the local or external readbacks were enabled,
|
|
regardless of the state (enable/disable) of the retries. </li>
|
|
<li>The New Target Monitoring (NTM field) logic is changed to use reference rather
|
|
than feedback positions. This eliminates unwanted motor record STOP commands at
|
|
the end of DC motor moves. </li>
|
|
</ul>
|
|
<p>
|
|
<b>Examples renamed</b>
|
|
</p>
|
|
<p>
|
|
The examples iocNoMPF and iocWithMPF were renamed iocNoAsyn and iocWithAsyn, respectively.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
New Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Animatics Corporation SmartMotor</b>
|
|
</p>
|
|
<p>
|
|
Shifu Xu's support for the Animatics Corporation SmartMotor was added.
|
|
</p>
|
|
<p>
|
|
<b>piezosystem jena, Inc. EDS</b>
|
|
</p>
|
|
<p>
|
|
Joe Sullivan added support for the piezosystem jena GmbH EDS data interface module.
|
|
</p>
|
|
<p>
|
|
<b>Kohzu SC-800</b>
|
|
</p>
|
|
<p>
|
|
Ron Sluiter added support for the Kohzu SC-800 stepper motor controller.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 6.2 Release Notice</b></h1>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Newport PM500 Initialization Problem</b>
|
|
</p>
|
|
<p>
|
|
The PM500 driver was not issuing the correct command when it queried for the number
|
|
of axes at boot up. This resulted in a "PM500 system error" message on the 1st axis.
|
|
</p>
|
|
<p>
|
|
<b>Overwritten PID Parameters</b>
|
|
</p>
|
|
<p>
|
|
A bug was introduced with R6-0; the OMS device support was overwriting PID parameter
|
|
fields during its' normalization calculation.
|
|
</p>
|
|
<p>
|
|
<b>Motor Position Initialization</b>
|
|
</p>
|
|
<p>
|
|
There was a bug in the logic that determines the precedence between using the controller's
|
|
or save/restore's motor position at boot-up. Negative controller positions were
|
|
not handled correctly.
|
|
</p>
|
|
<p>
|
|
<b>Newport Build Problem</b>
|
|
</p>
|
|
<p>
|
|
Due to releasing R6-1 during Newport development, R6-1 can result in linker errors
|
|
on the symbol "xpsgathering". Newport users should upgrade to R6-2.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
New Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Thorlabs model MDT695</b>
|
|
</p>
|
|
<p>
|
|
Joe Sullivan added support for Thorlabs Piezo Control Module, model MDT695.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 6.1 Release Notice</b></h1>
|
|
</div>
|
|
<p>
|
|
<br />
|
|
<b>Requirements</b><br />
|
|
<br />
|
|
EPICS base R3.14.8.2 or greater. See the "Required Modules" section of the
|
|
Motor Record web page for details.<br />
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>PI C-862 communiation errors</b>
|
|
</p>
|
|
<p>
|
|
A 17ms "status update delay" was added to the driver to prevent the controller from
|
|
dropping communication characters. This problem resulted in erroneous error responses
|
|
from the controller.
|
|
</p>
|
|
<p>
|
|
<b>motorStatus[xx].adl displays</b>
|
|
</p>
|
|
<p>
|
|
All motorStatus[xx].adl displays were modified to show motor position with text
|
|
rather than with bar graphs.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
New Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Physik Instrumente GmbH & Co. Model E-710</b>
|
|
</p>
|
|
<p>
|
|
Joe Sullivan added support for the Physik Instrumente (PI) GmbH & Co. Model
|
|
E-710 motor controller.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 6.0 Release Notice</b></h1>
|
|
</div>
|
|
<p>
|
|
<br />
|
|
<b>Requirements</b><br />
|
|
<br />
|
|
EPICS base R3.14.8.2 or greater. See the "Required Modules" section of the
|
|
Motor Record web page for details.<br />
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>OMS MAXv Polling Rate</b>
|
|
</p>
|
|
<p>
|
|
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()).
|
|
</p>
|
|
<p>
|
|
<b>Changes to New Focus Device Support</b>
|
|
</p>
|
|
<p>
|
|
The New Focus Model 8750 Network Controller device support ("PMNC8750") has been
|
|
changed to "PMNC87xx". It now supports both the 8750 and 8752 models.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
New Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Physik Instrumente GmbH & Co. Model C-862</b>
|
|
</p>
|
|
<p>
|
|
Mohan Ramanathan and Ron Sluiter added support for the Physik Instrumente (PI) GmbH
|
|
& Co. Model C-862 motor controller.
|
|
</p>
|
|
<p>
|
|
<b>ACS Tech80 SPiiPlus</b>
|
|
</p>
|
|
<p>
|
|
Joe Sullivan added support for the ACS Tech80 SPiiPlus motor controller.
|
|
</p>
|
|
<p>
|
|
<b>Spectra-Physics Encoder Mike</b>
|
|
</p>
|
|
<p>
|
|
Joe Sullivan added support for the Spectra-Physics Encoder Mike Controller (Model:
|
|
18011).
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 5.9 Release Notice</b></h1>
|
|
</div>
|
|
<p>
|
|
<br />
|
|
<b>Requirements</b><br />
|
|
<br />
|
|
EPICS base R3.14.8.2 or greater. See the "Required Modules" section of the
|
|
Motor Record web page for details.<br />
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Soft Motor allocation limit</b>
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
New Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>All motors done/stop/moving utility</b>
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Asyn Motor</b>
|
|
</p>
|
|
<p>
|
|
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 <i>is an attempt to define a clean, extensible API
|
|
for motor controller drivers to support</i>. This is a preliminary release of
|
|
work in progress. Do not use <i>asynMotor</i> device support at this time, except
|
|
for development and testing purposes only.
|
|
</p>
|
|
<p>
|
|
<b>New Focus 8750 Network Controller</b>
|
|
</p>
|
|
<p>
|
|
Joe Sullivan added support for the New Focus Model 8750 Network Controller.
|
|
</p>
|
|
<p>
|
|
<b>Physik Instrumente (PI) E-662 piezo controller</b>
|
|
</p>
|
|
<p>
|
|
Joe Sullivan added support for the Physik Instrumente (PI) GmbH & Co. Model
|
|
E-662 piezo controller.
|
|
</p>
|
|
<p>
|
|
<b>Newport XPS-C8 asyn motor support</b>
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Trajectory Scanning</b>
|
|
</p>
|
|
<p>
|
|
Mark Rivers added the Trajectory Scanning software for both the Newport MM4005 and
|
|
XPS-C8 motor controllers to the motor record distribution.
|
|
</p>
|
|
<p>
|
|
<b>OMS PC68 and PC78 support</b>
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 5.8 Release Notice</b></h1>
|
|
</div>
|
|
<p>
|
|
<br />
|
|
<b>Requirements</b><br />
|
|
<br />
|
|
EPICS base R3.14.7 or greater. See the "Required Modules" section of the Motor
|
|
Record web page for details.<br />
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
New Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Faulhaber MCDC2805</b>
|
|
</p>
|
|
<p>
|
|
Mark Rivers added support for the Faulhaber MCDC2805 servo controller.
|
|
</p>
|
|
<p>
|
|
<b>Parker Hannifin, Compumotor Division, 6K Series</b>
|
|
</p>
|
|
<p>
|
|
Joe Sullivan added support for Parker Hannifin, Compumotor Division, 6K Series controllers.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 5.7 Release Notice</b></h1>
|
|
</div>
|
|
<p>
|
|
<br />
|
|
<b>Requirements</b><br />
|
|
<br />
|
|
EPICS base R3.14.7 or greater. See the "Required Modules" section of the Motor
|
|
Record web page for details.<br />
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<b>Initial Position</b>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
New Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Physik Instrumente (PI) C-630</b>
|
|
</p>
|
|
<p>
|
|
Kurt Goetze added support for the Physik Instrumente (PI) model C-630 motion controller.
|
|
</p>
|
|
<p>
|
|
<b>Physik Instrumente (PI) C-848</b>
|
|
</p>
|
|
<p>
|
|
Support added for the Physik Instrumente (PI) C-848 motor controller.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 5.6 Release Notice</b></h1>
|
|
</div>
|
|
<p>
|
|
<br />
|
|
<b>Requirements</b><br />
|
|
<br />
|
|
EPICS base R3.14.7 or greater. See the "Required Modules" section of the Motor
|
|
Record web page for details.<br />
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<b>IMS MDrive Configuration</b>
|
|
<p>
|
|
IMS MDrive users must make the following configuration changes to their MDrive's
|
|
as described in the distribution document "motorR5-6/motorApp/ImsSrc/README".
|
|
</p>
|
|
<ul>
|
|
<li>Configure the limit and home switches. </li>
|
|
<li>Change the MDrives' Echo Mode Flag to two (EM=2). </li>
|
|
</ul>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 5.5 Release Notice</b></h1>
|
|
</div>
|
|
<p>
|
|
<br />
|
|
<b>Requirements</b><br />
|
|
<br />
|
|
EPICS base R3.14.7 or greater. See the "Required Modules" section of the Motor
|
|
Record web page for details.<br />
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<b>Conversion to ASYN</b>
|
|
<p>
|
|
The motor record distribution has been converted from MPF to ASYN R4.1. All support
|
|
for MPF has been removed.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<b>Acceleration Correction</b>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 5.4 Release Notice</b></h1>
|
|
</div>
|
|
<p>
|
|
<br />
|
|
<b>Requirements</b><br />
|
|
<br />
|
|
EPICS base R3.14.6 or greater. See the "Required Modules" section of the Motor
|
|
Record web page for details.<br />
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<b>Status Updates</b>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
New Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>OMS MAXv device support</b>
|
|
</p>
|
|
Device support for Oregon Micro Systems, Inc. MAXv controller was added.
|
|
<p>
|
|
</p>
|
|
<p>
|
|
<b>Delta Tau PMAC</b>
|
|
</p>
|
|
<p>
|
|
Device support for Delta Tau's PMAC2-VME controller was added.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 5.3 Release Notice</b></h1>
|
|
</div>
|
|
<p>
|
|
<br />
|
|
<b>Requirements</b><br />
|
|
<br />
|
|
EPICS base R3.14.5 or greater. See the "Required Modules" section of the Motor
|
|
Record web page for details.<br />
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<p>
|
|
<b>OMS VME58 Servo Limit Switch Problem</b></p>
|
|
<p>
|
|
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
|
|
</p>
|
|
<p>
|
|
<b>Encoder Resolution (ERES) Polarity</b></p>
|
|
<p>
|
|
Previous releases of the motor record forced the sign of ERES to match the sign
|
|
of MRES. With this release, ERES and MRES may have different signs. This allows
|
|
the user to change the sign of ERES rather than reverse encoder wires when the motor
|
|
and encoder direction are reversed. <b>Warning!</b> 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.
|
|
</p>
|
|
<p>
|
|
<b>PID parameter initialization</b>
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>IMS MDrive Device Driver</b>
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Three Device Drivers New To R3.14.x</b>
|
|
</p>
|
|
<p>
|
|
The following three device drivers have been ported from the R3.13.x compatible
|
|
version of the motor record:</p>
|
|
<ul>
|
|
<li>the Physik Instrumente (PI) GmbH & Co. C-844 motor controller. </li>
|
|
<li>Kevin Peterson's support for the MicroMo MVP 2001 B02 controller. </li>
|
|
<li>Kurt Goetze's support for the Micos MoCo dc controller. </li>
|
|
</ul>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
New Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Status Update (STUP)</b>
|
|
</p>
|
|
<p>
|
|
The STUP field (Status Update) has been modified due to bug fixes. The STUP field
|
|
functions as follows;</p>
|
|
<ul>
|
|
<li>Valid values for STUP are OFF(0), ON(1) and BUSY(2). </li>
|
|
<li>A Channel Access (CA) client writes ON(1) to the STUP field which causes the motor
|
|
record to set STUP to BUSY(2) and request a single controller status update. After
|
|
the status is updated the record sets STUP to OFF(0). </li>
|
|
<li>CA clients are restricted to writing ON(1) to STUP only when STUP is OFF(0).
|
|
</li>
|
|
<li>It is the responsibility of the user to restrict the frequency (and thus the incurred
|
|
overhead) at which the CA client writes ON(1) to STUP. </li>
|
|
</ul>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 5.2 Release Notice</b></h1>
|
|
</div>
|
|
<p>
|
|
<br />
|
|
<b>Requirements</b><br />
|
|
<br />
|
|
EPICS base R3.14.4 or greater. See the "Required Modules" section of the Motor
|
|
Record web page for details.<br />
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<p>
|
|
<b>Newport MM3000 Communication</b>
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>OMS VX2-006 Spurious Interrupts</b>
|
|
</p>
|
|
<p>
|
|
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).
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Backlash Correction Bug Fix</b>
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Newport ESP300 Device Driver Crash</b>
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
In addition, the user is required to set MRES to the resolution of the controller
|
|
as explained in the distribution document <i>motor</i>/motorApp/NewportSrc/README.
|
|
</p>
|
|
<p>
|
|
<b>Update Rate Bug Fix</b>
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
<b>Backlash Correction after Jogging Bug Fix</b>
|
|
</p>
|
|
<p>
|
|
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 <i>Backlash Correction Bug Fix</i> above, backlash correction is always
|
|
done after jogging, regardless of the jog acceleration and speed parameters
|
|
</p>
|
|
<p>
|
|
<b>DLY field</b>
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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).
|
|
</p>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 5.1 Release Notice</b></h1>
|
|
</div>
|
|
<p>
|
|
<b>!WARNING!</b><br />
|
|
</p>
|
|
<div style="text-align: left;">
|
|
This release of the motor record contains major modifications. It has not,
|
|
yet, undergone rigorous testing. I highly recommend that user's test this
|
|
release in a safe, non-critical environment before committing themselves to using
|
|
it with their critical applications.<br />
|
|
<br />
|
|
This is the first R3.14 compatible release of the motor record. All of the
|
|
device drivers, with the exception of OMS, are operating system independent (OSI).
|
|
Thanks to Joe Sullivan for his work with the initial port to R3.14.<br />
|
|
</div>
|
|
<p>
|
|
<br />
|
|
<b>Requirements</b><br />
|
|
<br />
|
|
EPICS base R3.14.2 or greater. See the "Required Modules" section of the Motor
|
|
Record web page for details.<br />
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
New Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<b>MX Device Driver</b><br />
|
|
<br />
|
|
This release includes a device driver for MX. The MX device driver gives EPICS
|
|
user's access to motor controllers that are not currently supported by the motor
|
|
record. An MX example is included with the motor distribution. This device
|
|
driver requires MX release 0.62.0 or greater.<br />
|
|
<br />
|
|
<b>Mclennan PM600</b><br />
|
|
<br />
|
|
Mark Rivers added support for the Mclennan PM600 controller.<br />
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 4.7 Release Notice</b></h1>
|
|
</div>
|
|
<p>
|
|
<b>!WARNING!</b><br />
|
|
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).
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<b>Redundant DMOV Monitor Postings</b><br />
|
|
<br />
|
|
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.<br />
|
|
<br />
|
|
<b>OMS VME58 Intermittent Limit Switch Status Error<br />
|
|
<br />
|
|
</b>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.<br />
|
|
<div style="text-align: center">
|
|
<p>
|
|
<b>New Features</b>
|
|
</p>
|
|
<div style="text-align: left">
|
|
<b>Motor Synchronized DB Puts</b><br />
|
|
<br />
|
|
<i>device directive </i>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:<br />
|
|
PREM - @PUT(<i>pvname</i>, <i>pv-value</i>, <i>delay in
|
|
seconds</i>)@
|
|
<br />
|
|
POST - @PUT(<i>pvname</i>, <i>pv-value</i>)@
|
|
<br />
|
|
Note that the PREM supports a delay argument, but that POST does not. The
|
|
<i>Readback settle time field</i> (DLY) should be used to create a time delay after
|
|
the PV specified in the POST field is written. See the <i>Miscellaneous fields</i>
|
|
section of motorRecord.html for further information on the INIT, PREM and POST fields.<br />
|
|
<br />
|
|
<b>IMS MDrive17 device support</b>
|
|
</div>
|
|
</div>
|
|
<br />
|
|
Device driver support for the Intelligent Motion Systems (IMS) MDrive17 model motor
|
|
controller is available with this release.<br />
|
|
<b>
|
|
<br />
|
|
Home Velocity<br />
|
|
</b>
|
|
<br />
|
|
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.<b></b>
|
|
In addition, if HVEL is not initialized by the user, the motor record sets
|
|
HVEL to VBAS.<br />
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 4.6 Release Notice</b></h1>
|
|
</div>
|
|
<p>
|
|
<b>!WARNING!</b><br />
|
|
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).
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<b>Soft Channel Device Support<br />
|
|
<br />
|
|
</b>
|
|
</div>
|
|
<div style="text-align: left">
|
|
A conflict between the requirements specified under <i>Requirements Clarification
|
|
</i>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.<br />
|
|
</div>
|
|
<div style="text-align: left">
|
|
<br />
|
|
</div>
|
|
<div style="text-align: left">
|
|
A problem occurred with, for example, the SoftMotorEx.db that is distributed with
|
|
the motor record, when backlash was enabled in the <i>hard motor</i>(a motor configured
|
|
without Soft Channel device support). The result was that the <i>soft motor</i>
|
|
(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.<br />
|
|
</div>
|
|
<div style="text-align: left">
|
|
<br />
|
|
</div>
|
|
<div style="text-align: left">
|
|
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).<br />
|
|
</div>
|
|
<div style="text-align: left">
|
|
<blockquote>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</blockquote>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<blockquote>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</blockquote>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<blockquote>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</blockquote>
|
|
</div>
|
|
<div style="text-align: left">
|
|
<br />
|
|
</div>
|
|
<div style="text-align: left">
|
|
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 <i>sees</i> 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.<br />
|
|
</div>
|
|
<p>
|
|
</p>
|
|
<div style="text-align: left">
|
|
With this release, the LOCK field has been added to allow the user to enable/disable
|
|
synchronization due to the readback changing.
|
|
</div>
|
|
<div style="text-align: left">
|
|
<h4>
|
|
Backlash Correction Bug Fixes</h4>
|
|
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;<br />
|
|
<ol>
|
|
<li>motion is in progress (i.e., DMOV is false). </li>
|
|
<li>the new target position is different from the actual position by less than the
|
|
retry deadband (|DIFF| < RDBD). </li>
|
|
<li>backlash correction is enabled (i.e., BDST is non-zero) and the new move is <b>
|
|
not</b> in the "preferred direction" (preferred direction is the direction in which
|
|
the motor moves during the backlash-takeout part of a motor move). </li>
|
|
</ol>
|
|
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.<br />
|
|
<br />
|
|
Thanks to Kevin M. Peterson, James B. Stevens and John Maclean for their help in
|
|
finding and fixing these bugs.
|
|
<br />
|
|
<div style="text-align: center">
|
|
<p>
|
|
<b>New Features</b>
|
|
</p>
|
|
</div>
|
|
<h4>
|
|
Newport ESP300 device support</h4>
|
|
Device support for the Newport ESP300 motor controller is available with this release.<br />
|
|
<h1>
|
|
</h1>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 4.5 Release Notice</b></h1>
|
|
</div>
|
|
<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
|
|
#2 for details).
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<p>
|
|
<b>Communication Retries</b></p>
|
|
<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>
|
|
Requirements Clarification</h4>
|
|
<p>
|
|
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:</p>
|
|
<blockquote>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</blockquote>
|
|
<blockquote>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</blockquote>
|
|
<blockquote>
|
|
<p>
|
|
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.)
|
|
</p>
|
|
</blockquote>
|
|
<h4>
|
|
Bug Fix for Driver Power Monitoring error</h4>
|
|
<p>
|
|
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>
|
|
<p>
|
|
<b>Soft Channel device support modifications</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>
|
|
<p>
|
|
<b>Bug Fix for Array Holes in VMEbus based controllers</b></p>
|
|
<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>RES Field</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>
|
|
Backlash Correction</h4>
|
|
<p>
|
|
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.</p>
|
|
<p>
|
|
With this release, backlash correction commands are not issued to the controller
|
|
until after the slew move is completed.</p>
|
|
<h4>
|
|
Separa<b>te +/- Limit Switch status bits</b></h4>
|
|
<p>
|
|
The MSTA field has been modified by providing separate +/- limit switch status bits.
|
|
The MSTA bits are defined as follows:</p>
|
|
<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>
|
|
<p>
|
|
</p>
|
|
<div style="text-align: center">
|
|
<p>
|
|
<b>New Features</b>
|
|
</p>
|
|
</div>
|
|
<p>
|
|
<b>Advanced Control Systems and Mclennan device driver support</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>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 4.4 Release Notice</b></h1>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<p>
|
|
<b>Disable Travel Limits</b></p>
|
|
<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>RVAL ignored error</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>
|
|
<div style="text-align: center">
|
|
<b>New Features</b>
|
|
</div>
|
|
<p>
|
|
<b>Jog velocity and acceleration parameters</b></p>
|
|
<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>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 4.3 Release Notice</b></h1>
|
|
</div>
|
|
<p>
|
|
This release of the motor record is strictly a bug fix release; no new features
|
|
have been added.</p>
|
|
<p>
|
|
<b>STOP field hangs record</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>HIDEOS support removed</b>
|
|
</p>
|
|
<p>
|
|
HIDEOS is no longer supported. MPF is the only supported alternative to HIDEOS.
|
|
<br />
|
|
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
<b>Motor Record Version 4.2 Release Notice</b></h1>
|
|
</div>
|
|
<p>
|
|
This release of the motor record is compatible with EPICS R3.13.2 and above.</p>
|
|
<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>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<p>
|
|
<b>Precedence between field pairs</b></p>
|
|
<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>Moving Off a Limit Switch with a Oms58 device</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>Separate motion commands for target and backlash moves</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>Errors introduced in V4.0</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>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
<b>New Features</b></h4>
|
|
</div>
|
|
<p>
|
|
<b>Newport PM500 device support</b></p>
|
|
<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>Intelligent Motion Systems, Inc. IM483 device support</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>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
Motor Record Version 4.1 Release Notice</h1>
|
|
</div>
|
|
<p>
|
|
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.</p>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<h4>
|
|
<b>OMS VME58 retry problem</b></h4>
|
|
<p>
|
|
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.</p>
|
|
<h4>
|
|
<b>OMS Stop problem</b></h4>
|
|
<p>
|
|
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 />
|
|
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
Motor Record Version 4.0 Release Notice</h1>
|
|
</div>
|
|
<p>
|
|
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.</p>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<h4>
|
|
<b>GAIN Field Removed</b></h4>
|
|
<p>
|
|
Since the GAIN field is redundant (i.e., PID parameters can be set individually)
|
|
it has been removed.</p>
|
|
<h4>
|
|
<b>HOM[F/R] Bug Fix</b></h4>
|
|
<p>
|
|
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>
|
|
<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>
|
|
Initial Position</h4>
|
|
<p>
|
|
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>
|
|
<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>
|
|
Access Security Level</h4>
|
|
<p>
|
|
In order to support the new VMAX/SMAX fields, the Access Security Level for the
|
|
following fields have been changed from one to zero:</p>
|
|
<blockquote>
|
|
<ul>
|
|
<li>MRES </li>
|
|
<li>UREV </li>
|
|
<li>VBAS </li>
|
|
<li>SBAS </li>
|
|
</ul>
|
|
</blockquote>
|
|
<h4>
|
|
MM4000/5 Device Driver</h4>
|
|
<p>
|
|
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:</p>
|
|
<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.
|
|
<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>
|
|
<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>
|
|
Bug Fix for OMS VME58 running on PowerPC</h4>
|
|
<p>
|
|
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.</p>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
New Features</h4>
|
|
</div>
|
|
<p>
|
|
<b>Newport MM3000 Device Support</b></p>
|
|
<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>
|
|
Uninitialized Oms/Oms58 Driver Error Check</h4>
|
|
<p>
|
|
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.)</p>
|
|
<h4>
|
|
Maximum Velocity Fields (VMAX/SMAX)</h4>
|
|
<p>
|
|
Maximum velocity fields have been added; VMAX in EGU/s units and SMAX in RPS units.</p>
|
|
<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>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
Motor Record Version 3.5 Release Notice</h1>
|
|
</div>
|
|
<p>
|
|
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:</p>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
Modifications to Existing Features</h4>
|
|
</div>
|
|
<h4>
|
|
Command Primitives</h4>
|
|
<p>
|
|
<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:</p>
|
|
<blockquote>
|
|
<p>
|
|
1. INIT - Sent at record initialization.
|
|
</p>
|
|
</blockquote>
|
|
<blockquote>
|
|
<p>
|
|
2. PREM - Sent before every command string that causes motion.
|
|
</p>
|
|
</blockquote>
|
|
<blockquote>
|
|
<p>
|
|
3. POST - Sent after a complete motion is finished or when an overtravel limit switch
|
|
is detected.
|
|
</p>
|
|
</blockquote>
|
|
<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.</p>
|
|
<h4>
|
|
Servo related Fields</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>
|
|
Unused Fields Removed</h4>
|
|
<p>
|
|
The following unused motor record fields were deleted: MODE, TRAK, MDEL, ADEL, CVEL,
|
|
POSM, ALST, MLST</p>
|
|
<div style="text-align: center">
|
|
<h4>
|
|
New Features</h4>
|
|
</div>
|
|
<h4>
|
|
Device Directives</h4>
|
|
<p>
|
|
Device directive definition and processing:</p>
|
|
<ul>
|
|
<li>Valid only in the INIT field. </li>
|
|
<li>Must be identified by the following;
|
|
<ul>
|
|
<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>
|
|
</ul>
|
|
</li>
|
|
<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>
|
|
Driver Power Monitoring</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>
|
|
<p>
|
|
|
|
User I/O #0 <> X axis
|
|
</p>
|
|
<p>
|
|
|
|
" " 1 <> Y "
|
|
</p>
|
|
<p>
|
|
|
|
.....................
|
|
</p>
|
|
<p>
|
|
|
|
" " 7 <> S "</p>
|
|
<ul>
|
|
<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>
|
|
Soft Channel Device Support</h4>
|
|
<p>
|
|
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>
|
|
<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>
|
|
<div style="text-align: center">
|
|
<table border="1">
|
|
<tbody>
|
|
<tr align="center">
|
|
<td>
|
|
Link</td>
|
|
<td>
|
|
Link Type</td>
|
|
<td>
|
|
Associated Field</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
OUT*</td>
|
|
<td>
|
|
DBOUTPUT</td>
|
|
<td>
|
|
<div style="text-align: center">
|
|
DVAL
|
|
</div>
|
|
</td>
|
|
</tr>
|
|
<tr align="center">
|
|
<td>
|
|
STOO</td>
|
|
<td>
|
|
DBOUTPUT</td>
|
|
<td align="center">
|
|
STOP</td>
|
|
</tr>
|
|
<tr align="center">
|
|
<td>
|
|
DINP</td>
|
|
<td>
|
|
DBINPUT</td>
|
|
<td>
|
|
DMOV</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
RDBL*</td>
|
|
<td>
|
|
DBINPUT</td>
|
|
<td>
|
|
<div style="text-align: center">
|
|
DRBV
|
|
</div>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
RINP</td>
|
|
<td>
|
|
DBINPUT</td>
|
|
<td>
|
|
<div style="text-align: center">
|
|
RMP
|
|
</div>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
<div style="text-align: center">
|
|
<p>
|
|
* - Not a new field, but a new function provided only by soft channel device support.
|
|
</p>
|
|
</div>
|
|
<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>
|
|
Newport MM4000 Device Support</h4>
|
|
<p>
|
|
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:</p>
|
|
<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>
|
|
PID Gain Parameters</h4>
|
|
<p>
|
|
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:</p>
|
|
<blockquote>
|
|
<p>
|
|
For the MM4000 For all OMS controllers
|
|
</p>
|
|
</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>
|
|
<p>
|
|
Note that setting any of the individual PID record fields is <b>not</b>reflected
|
|
in the value of the GAIN field.</p>
|
|
<h4>
|
|
Highland V544 Device Support</h4>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<div style="text-align: center">
|
|
<h1>
|
|
Motor Record Version 3.4 Release Notice</h1>
|
|
</div>
|
|
<p>
|
|
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:</p>
|
|
<h3>
|
|
Device driver design error fix
|
|
</h3>
|
|
<p>
|
|
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>
|
|
<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>
|
|
PID Parameter Support for VME58
|
|
</h3>
|
|
<p>
|
|
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>
|
|
<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>
|
|
Command primitives feature
|
|
</h3>
|
|
<p>
|
|
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>
|
|
<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.
|
|
</p>
|
|
</body>
|
|
</html>
|