forked from epics_driver_modules/motorBase
Ron SluiterMotor Record R5-3 Release Notice
===============================================================================
The motor record software in this release is compatible with EPICS base R3.14.4.
Contents
========
This <supporttop> contains the following motor record related items:
- motor record and device driver database definitions.
- the record level support library.
- device/driver libraries for various controllers.
- motor record/device/driver level documentation.
- motor record release documentation.
- two example applications; one without MPF (i.e. motorExApp/NoMPF) and
one with MPF (i.e., motorExApp/WithMPF).
As distributed, this support directory only builds the following:
- motorLib; Record support and common code for all device/drivers.
Optionally, any of the following device/driver libraries can be built by
uncommenting the appropriate line in ./motorApp/Makefile.
Ims - Intelligent Motion Systems (IMS) controllers; ImsSrc directory.
Newport - Newport controllers; NewportSrc directory.
oms - Oregon Micro System (OMS) controllers; OmsSrc directory.
Acs - Advanced Control Systems controllers; AcsSrc directory.
Mclennan - Mclennan controllers; MclennanSrc directory.
softMotor - Soft Channel device support; SoftMotorSrc directory.
motorCOM_mpf - Communication interface between motor device/drivers and
MPF; CommSrc directory.
Configuration
=============
The following files can be edited to tailor this distribution to site specific
needs. See individual files for instructions.
- ./config/RELEASE: Define location of external products.
If only VMEbus based motor controllers (e.g., OMS, Highland
V544) and/or Soft Channel device support is used, then only
EPICS_BASE is required.
For serial and/or GPIB motor controller communication, ALL of
the following support modules are required;
- EPICS base R3.14.2 or above.
- mpf R2-2 or above.
- GPIB is not supported yet.
If any example applications (motorExApp) are to be built, then
TEMPLATE_TOP and MSITOP must be defined.
- ./motorApp/Makefile: Define which device/driver modules to build.
- ./motorExApp/Makefile: Define which, if any, example applications are
to be built.
Known Problems
==============
1) The PAUSE function of the SPMG field only works if the RTRY field is
nonzero. This bug existed as far back as V3.3 of the motor record.
2) MM4005 only. On the first attempt to move off an activated limit switch,
the motor moves to where it was commanded. However, the motor record's
positions (both target and readback) do not reflect the move. This
is because of the following sequence of events:
- a limit (i.e., laser light beam) violation occurs. The Newport
controller turns motor power off.
- the axis stops at position X.
- a move command is issued in the opposite direction.
- after a delay of between 16.67 ms and 33.33 ms, a motor status
(i.e., MS) query is issued to the MM4005.
- the motor status response indicates the axis is NOT in motion
and motor power is OFF (the motor record interprets this as "Done
Moving" true).
- a "read actual positions" command is issued.
- the actual position response indicates the axis is still at
position X.
- the controller turns motor power on and the axis moves to the
requested position.
3) Under certain circumstances the error message "Motor motion timeout ERROR"
can appear erroneously. This occurs if the user repeats 10 consecutive
commands that include a controller update command (i.e., INFO) without
any intervening motor moves. For example, if the UEIP field is
toggled between "Yes" and "No" 10 times, the "Motor motion timeout
ERROR" message will appear.
4) The OMS VME58 servo motor controller board (i.e., model -8S) is unable to
move off an activated limit switch. Users are advised to avoid this
situation.
Modification Log from R5-2 to R5-3
==================================
1) The update (polling) rate for the "OMS VME8/44" device driver was incorrect.
File modified: - omsSetup() in drvOms.cc.
2) When TWV is set to less than MRES, the following scenario would result.
First, tweak forward (TWF). Since DIFF < MRES, the motor is not moved.
Next, tweak reverse (TWR). Next TWF again. The motor record does not
respond; i.e., DVAL and RVAL are not updated; VAL is not posted.
A single tweak, back and forth, confirms that the motor record is not
responding.
The problem was that do_work() in motorRecord.c was performing the "no
move" test before testing for new positions and posting new positions.
File modified: - do_work() in motorRecord.cc
3) 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). See above "Known Problems" item #4.
File modified: - set_status() in drvOms58.cc; had to force CDIR to
match the limit switch polarity for record level code
to see the limit switch error condition.
Modification Log from R5-1 to R5-2
==================================
1) 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.
File modified: - recv_mess() in drvMM3000.cc
2) Spurious interrupts were occurring with OMS VX2-006 ver 1.04 controller
boards. For the sake of throughput, the OMS VME8/44 device driver
enables the done (DON_E) and input buffer full (IBF_E) interrupts, but
disables the transmit buffer empty (TBE_E).
The OMS boards are RORA VME type interrupters. The "release" register
is the status register. It contains information on the status of the
transmit/receive buffer interrupts and the done interrupt. Since the
device driver was not using the transmit buffer empty interrupt, it was
polling the status register when sending a command to the controller.
With the VX2, if the IRQ became active during a status register read
cycle, the IRQ was negated at the end of the cycle and the CPU board
generated a spurious interrupt.
The VME8/44 models somehow prevented the spurious interrupts from
occurring by latching the IRQ, if and when, the IRQ became active
during a status register read.
This problem has been fixed by using all of the OMS board interrupts
(i.e., enable transmit buffer empty). The OMS VME8/44/VX2/VS4 design
is limited with regard to interrupts by an all or none choice.
In addition, the following modifications were made to the OMS8/44
device driver;
- Moved the OMS specific data structure "irqdatastr" from motordrvCom.h
to drvOms.h.
- Changed recv_rng and send_rng in irqdatastr from C to C++ interface.
- Added epicsThreadSleep() calls to omsGet() and omsPut() in drvOms.cc
during delays.
Files modified: - OmsSrc/drvOms.h; enable TBE_E interrupt.
- OmsSrc/drvOms.cc; support TBE_E interrupt.
- MotorSrc/motordrvCom.h
3) With release R4-7, there was a slight (undocumented) modification made to
the way that backlash correction functioned. If a move is in the
preferred direction and the backlash speed and acceleration are the
same as the slew speed and acceleration, then the backlash move is
skipped and the motor moves directly to the target position.
Unfortunately, there was a bug in the logic that appeared only when MRES
< 0. When MRES < 0, and the backlash speed and acceleration were the
same as the slew speed and acceleration, the motor record did the
opposite of the requirements; i.e., it did backlash correction when the
move was in the preferred direction and did not do backlash correction
when the move was not in the preferred direction.
File modified: - do_work() in motorRecord.cc
4) The Newport ESP300 would randomly crash at boot-up because an internal
parameter ("drive_resolution") was not always, under all
configurations, initialized. With this release, the "drive_resolution"
is set based on the response to the ESP300 "SU?" command. In addition,
the user is required to set MRES to the resolution of the controller as
explained in the new document <motor>/motorApp/NewportSrc/README.
Files modified: - NewportSrc/devESP300.c
- NewportSrc/drvESP300.c
File added: - NewportSrc/README (notes on serial communication and
ESP300 configuration).
5) 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 controllers an INFO update
after a LOAD_POS command would, intermittently, yield the previous
position.
File modified: motor_task() and process_messages() in motordrvCom.cc
6) 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 item#3 above, backlash
correction is always done after jogging, regardless of the jog
acceleration and speed parameters.
File modified: Added extra jog backlash states to postProcess() in
motorRecord.cc
7) Although there is no explicit statement in the motor record documentation,
most user's would expect the "Readback settle time" field (DLY) to
update the readback after the delay timeout. It did not do this.
With this release, the readback is updated one time after the timeout.
Since a functioning DLY field performs the same function as the
drv<driver>ReadbackDelay variables, with the added advantage that the
delay can be motor specific, the drv<driver>ReadbackDelay variables
have been deleted (except for the MM4000).
File modified: - callbackFunc() and process() in motorRecord.cc
Modification Log from R4-5 to R5-1
==================================
1) The following scenario would put the motor record into an invalid state.
A new target position (i.e., VAL/DVAL/RVAL) is written to the motor
record under the following conditions,
- motion is in progress (i.e., DMOV is false).
- the new target position is different from the actual position by less
than the retry deadband (|DIFF| < RDBD).
- backlash correction is enabled (i.e., BDST is non-zero) and the new
move is NOT in the "preferred direction" (preferred direction is the
direction in which the motor moves during the backlash-takeout part of
a motor move).
File modified: do_work() in motorRecord.cc. Update last target
positions and set DMOV TRUE, only if the motion in
progress indicator (MIP) is DONE.
2) A bug was introduced in R4-5 when backlash correction was changed per item
#11 below. 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.
This bug was discovered by Kevin M. Peterson.
File modified: process() in motorRecord.cc. Before calling
postProcess() check if the target position has changed.
3) A conflict between the requirements specified in item #2 below and the goal
of having the same record level functionality for all device drivers,
including Soft Channel device support, was found by Tim Graber.
A problem occurred with, for example, the SoftMotorEx.db that is
distributed with the motor record, when backlash was enabled in the
"hard" motor. The result was that the "soft" motor would interpret
the "hard" motor's backlash correction as the motor going in the wrong
direction, and stop the "hard" motor from completing the backlash
correction.
With this release, the requirements on how the motor record processes a
new target position while the motor is in motion have been modified
based on a new field; New Target Monitor (NTM).
Case #1: The motor record is given a new position, which is in the
opposite direction from the current motor motion.
If NTM is YES, the motor is immediately stopped and given a motion
command to the new position.
If NTM is NO, the motor completes the previous move before it is given
a motion command to the new position.
Case #2: The motor record is given a new position, which is in the
same direction as the current motor motion, but the new position is
closer to the motor's current position than the original target
position.
If NTM is YES, the motor is stopped after it has gone past the new
position; then a command is given to return to the new position.
If NTM is NO, the motor completes the previous move before it is given
a motion command to the new position.
Case #3: The motor record is given a new position, which is in the
same direction as the current motor motion, but the new position is
further from the motor's current position than the original position.
After the motor reaches the original target position and stops, a
command is given to the new target position. This case is independent
of NTM.
Files modified: - NTM field added to motorRecord.dbd
- process() in motorRecord.cc checks NTM field before
sending stop motor command.
4) A Soft Channel device support design limitation was discovered by Tim
Mooney. The problem is a result of the modifications made with R4-5,
item #5 below, where the "soft" motor synchronizes it's target position
(i.e., VAL/DVAL/RVAL) with it's readback/raw position (RBV/DRBV/RRBV).
Given an application where there are two or more "soft" motors driving
the system (e.g., slit), when one soft motor is moved, the other soft
motor "sees" it's readback changing and synchronizes it's target position
with it's readback position at the end of the move, thereby losing it's
target position.
With this release, the LOCK field has been added to prevent
synchronization due to the readback changing.
Files modified: - LOCK field added to motorRecord.dbd
- soft_dinp_func() in devSoft.cc checks LOCK field
before putting dinp_value into HARDMOVE state.
5) Device driver support added for the Newport ESP300 motor controller.
Files added: - NewportSrc/devESP300.cc
- NewportSrc/drvESP300.cc
6) An uninitialized pointer error check was omitted from a Newport ESP300
device function. This resulted in a bus error at boot-up if the IOC
failed to connect to the ESP300 controller.
File modified: ESP300_init_record() in the devESP300.cc
7) "device directive" support has been extended to the PREM and POST fields for
OMS devices only. The new device directive supports changing the value
of a database variable. The syntax is as follows:
PREM - @PUT(<pvname>, <pv-value>, <delay in seconds>)@
POST - @PUT(<pvname>, <pv-value>)@
Note that the PREM supports a delay argument, but that POST does not.
The "Readback settle time" field (DLY) should be used to create a time
delay after the PV specified in the POST field is written. See the
"Miscellaneous fields" in motorRecord.html for further information on
the INIT, PREM and POST fields.
Files modified: devOmsCom.cc, drvOms58.cc and drvOms.cc
8) Device driver support added for the Intelligent Motion Systems (IMS)
MDrive17 model motor controller.
Files modified: - [dev/drv]MDrive.cd added to ImsSrc/Makefile.Vx
- "MDrive" device and driver added to devImsMotor.dbd
Files added: - [dev/drv]MDrive.cd added to ImsSrc directory.
9) Eliminated redundant DMOV monitor posting's. For example, with previous
releases the motor record would post DMOV=0 twice if backlash
correction was enabled and the user jogged the motor.
Files modified: modified postProcess(), process() and load_pos()
in motorRecord.cc.
10) A Home Velocity field (HVEL) was added.
Files modified: - HVEL added to motorRecord.dbd
- motorRecord.cc
- op/adl/motorx_setup.adl
11) 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.
File modified: - drvOms58.c; conditional delay added to query_done().
12) With release R4-5, DBE_LOG was omitted from the event select mask of all
db_post_events() calls. This prevented archival clients from being
notified of process variable changes. With this release, DBE_LOG is
on for all calls to db_post_events()
Files modified: - motorRecord.cc, motordevCom.cc and devSoft.cc
13) Mark Rivers added support for the Mclennan PM600 controller.
Files modified: - MclennanSrc/devPM304.cc
- MclennanSrc/drvPM304.cc
- MclennanSrc/drvPM304.h
14) MX device driver support added. MXmotorSrc directory added.
Modification Log from R4-4 to R4-5
==================================
1) The GPIB and RS232 serial communication error detection and reporting
mechanism was unreliable. In addition, once a communication error was
detected, the motor task did endless periodic communication retries.
With this release, 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).
Files modified: motordrvCom.h - added RETRY to CommStatus enumeration.
drvMM4000.c, drvMM3000.c, drvPM500.c, drvIM483PL.c, drvIM483SM.c
- start_status() allows one retry after a communication error.
- set_status() sets RA_PROBLEM along with CNTRL_COMM_ERR to terminate
node.
2) The requirements on how the motor record processes a new target position
while the motor is in motion have never been specified. The
requirements are as follows:
Case #1: The motor record is given a new position, which is in the
opposite direction from the current motor motion. The motor is
immediately stopped and given a motion command to the new position.
Case #2: The motor record is given a new position, which is in the
same direction as the current motor motion, but the new position is
closer to the motor's current position than the original target
position. The motor is stopped after it has gone past the new
position; then a command is given to return to the new position.
Case #3: The motor record is given a new position, which is in the
same direction as the current motor motion, but the new position is
further from the motor's current position than the original position.
After the motor reaches the original target position and stops, a
command is given to the new target position. (Previous motor record
versions ignored the new target position.)
File modified: * process() in motorRecord.c
* motorRecord.dbd - the PP field is initially zero.
- replaced PDIF with CDIR field.
3) For two CPU board configurations only (i.e., EPICS and IP satellite boards),
erroneous timeouts occurred if the EPICS board booted much faster than
the satellite board.
File modified: CommSrc/serialIOMPF.cc; increased timeout from 2 to 10
seconds in call to msgQReceive() from serialIO().
4) The "Driver Power Monitoring" feature (available only with OMS VME58
controllers) was erroneously and randomly being enabled. This
occurred because the internal state indicator (dpm) was never
initialized to OFF at boot-up.
File modified: motor_init_record_com() in motordevCom.c. Explicitly
initialize "dpm" to OFF.
5) The Soft Channel device support modifications:
- Prevent record processing before "interruptAccept" is true. This
helps prevent alarms.
- If the readback is changing, but motion was not initiated by this
record, then reset the motor record's target to actual position (i.e.,
VAL/DVAL/RVAL = RBV/DRBV/RRBV) after the move. As always, the Soft
Channel motor record's DMOV field is guaranteed to execute and post a
1/0/1 pulse, but MOVN remains zero throughout a move that was not
initiated by the Soft Channel record.
- Lowered the priority of the "soft_motor task below the "dbCaLink"
task. This fixes the "DMOV processing before the last DRBV update"
problem.
Files modified: - devSoft.h, devSoft.c, devAuxSoft.c
6) For VMEbus based motor controllers only (i.e., OMS), a "hole" in an array
of VME based motor controller boards caused the system to crash with
a memory "access error" on the address of the missing controller.
For example, if oms58Setup(3, 8, 0x4000, 190, 5, 10) was issued without
a board at 0xFFFF5000, a bus error would occur if the user attempted
to move a motor on the missing board.
Files modified: drvOms58.c - start_status() was not checking for valid
motor_state[card] pointer.
drvOms.c,drvOms58.c - "total_cards" changed from total
detected to total cards that "memory is
allocated for". This allows boards after the
"hole" to work.
7) For OMS motor controllers only, if the PREM field was set without a leading
space character (e.g., "BH8") this resulted in an invalid OMS command
(e.g., "AX VB10 VL1000 AC5000BH1 MA200 GD ID").
File modified: devOmsCom.c - A space character was prefixed to the
PREM field in oms_build_trans().
8) Eliminated support for the "ASCII record separator (IS2) = /x1E".
Files modified:
- MotorSrc/motordrvCom.c: Removed support for splitting and
shuffling concatenated command messages in query_axis().
- ImsSrc/devIM483[SM/PL].c: Moved the calls to
motor_[start/end]_trans_com() into IM483[SM/PL]_build_trans().
Don't call motor_end_trans_com() if motor command is a NOOP.
9) With previous releases of the motor record, the RES field was set to either
ERES or MRES, based on whether or not the following statement was true;
MSTA indicates an encoder is present, AND, UEIP is set to YES. This
state (i.e., MSTA indicates an encoder is present, AND, UEIP is set to
YES) resulted in the record converting all position and velocity
related values from EGU's to raw encoder counts before sending them to
the motor controller. This is the manner in which the OMS controllers
work (see OMS User's Manual, ER# command).
With this release, all raw positions, velocity and acceleration are
in terms of motor steps.
- RES always equal to MRES. RES preserved for backward compatibility
only. All instances of RES have been replaced with MRES.
Files modified: - MotorSrc/motor.h
- MotorSrc/motorRecord.c
- MotorSrc/motordevCom.c
- OmsSrc/devOmsCom.c
- NewportSrc/devMM3000.c
- NewportSrc/devMM4000.c
- NewportSrc/devPM500.c
- ImsSrc/devIM483PL.c
- ImsSrc/devIM483SM.c
- V544Src/devV544.c
10) Jog velocity was not checked for validity when VMAX or VBAS was changed.
Files modified: MotorSrc/motorRecord.c, added JVEL error check in
special().
11) Previous motor record releases put both the "slew" and backlash correction
moves on the same motor controller command line. Some controllers
(i.e., OMS) handled this correctly by processing the slew move followed
by the backlash correction move. Other controllers (i.e, Newport) did
not handle this correctly and processed the commands immediately,
resulting in the controller moving to the target position without
backlash correction, but at the backlash correction velocity.
With this release, backlash correction commands are not issued to the
controller until after the slew move is completed.
File modified: MotorSrc/motorRecord.c
- Moved the backlash commands from do_work() to postProcess().
- Added a MIP_MOVE_BL state indicator.
- Eliminated redundant MARK(M_MIP)'s.
- Combined MIP_MOVE with MIP_JOG_STOP logic in postProcess().
12) Mark Rivers has added device driver support for the following motor
controllers:
- Advanced Control Systems, Corp. model MCB-4B.
- Mclennan model PM304.
13) motor_callback() in motordevCom.c calls dbProcess(), rather than calling
motor record process() directly. This supports standard database
processing functions like TPRO and breakpoints.
14) Update <motor>/config files to synApps R4.4 and epics base 3.13.5:
Files modified:
RULES.Db - added "depends::"
makeConfigAppInclude.pl - updated to synApps R4.4 version.
makeIocCdCommands.pl - updated to synApps R4.4 version
15) Some databases where converted to VDCT; i.e., motor.db, SoftMotorEx.db.
16) Added separate +/- limit switch status bits in the MSTA field. There are
two types of motor controllers. The first type provides a limit switch
error and a direction indicator, the second type provides the state of
both limit switches, but no direction indicator. In the first case,
the device driver knows that an error has occurred, that motion has
stopped, and that based on the direction indicator, which limit switch
was activated. In the second case the device driver must determine,
based on the limit switch states and an internally generated direction
indicator, whether or not a limit switch error has occurred. The OMS
controllers are an example of the first type of controller and the
IM483 is an example of the second type of controller.
Files modified: - MotorSrc/motor.h
- MotorSrc/motorRecord.c
- MotorSrc/motordrvCom.c
- All drivers; i.e., */drv*.c
17) Post all fields when recGblResetAlarms() returns an alarm.
Modification Log from R4-3 to R4-4
==================================
1) config/RELEASE: - Changed comments to indicate that MPF_SERIAL must be
defined if either serial or GPIB communication is
required.
- Updated support modules to latest releases;
mpfSerial R1-2, MPF R1-6, EPICS base R3-13-4.
2) Examples: - iocBoot/iocNoMPF/st.cmd; added GDCT compatible Soft Channel
device driver example.
- iocBoot/iocWithMPF/[st.cmd and st_mpfserver.cmd]; for 1 CPU
configuration, both initGpibGsTi9914() and
HiDEOSGpibLinkConfig() must have the same GPIB server name.
- motorExApp/Db/[SoftMotorEx.db andSoftMotorEx] ; added a GDCT
compatible Soft channel device driver database example.
3) Jog Velocity and Acceleration. Two new fields (JVEL and JAR) were added to
support jog velocity and acceleration parameters. Only the OMS and IMS
device drivers support changing the Jog Velocity while jogging.
Files modified: motorRecord.dbd - Jog specific fields (JVEL and JAR).
motorRecord.c - Process JVEL in special().
devIM483[PL/SM].c, devMM[3/4]000.c,
devPM500.c, - Added Jog Velocity motor command.
devOmsCom.c - Added clear axis done flag command (CA)
to home and jog commands. This is
needed so that JVEL does not see
done from previous command.
4) Travel limits can be disabled by setting both the dial high and low limits
equal to zero; i.e., DHLM = DLLM = 0.
File modified: motorRecord.c
5) 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.
File modified: motorRecord.c - Root cause in do_work() was that under
the above conditions, LVAL was not updated.
6) The following scenario would put the motor record into an invalid state.
First, start the motor moving by giving it a new target position.
Next, while the motor is still moving, enter a new target position that
is beyond the software travel limit (HLM/LLM) . The invalid target
position is rejected (as it should be), but when the first target
position is reached the MIP field is left in the MOVE state, rather
than the DONE state.
File modified: motorRecord.c - Modified do_work() LVIO logic to set
DMOV true only if MIP is DONE.
7) Removed Hideos file motorApp/CommSrc/serialIO.cc from distribution.
8) The following scenario would put the motor record into an invalid state.
At the end of a move a "retry" is requested. The MIP field is set to
RETRY in maybeRetry(), but before the retry request can be processed
in do_work() the STOP field is set TRUE. This results in a STOP
command being issued, but no subsequent processing callbacks, which
leaves the record's MIP in the STOP state and DMOV false.
File modified: motorRecord.c - Modified do_work() STOP and SPMG
processing to set MIP <- DONE and DMOV <- TRUE when MIP == RETRY.
9) As suggested by Brian McAllister, type specifications for all bit-fields
found within unions have been changed to "int". This modification
elminates the ANSI warning messages and has no effect on the machine
code generated.
Files modified: motorRecord.c - mmap_field and nmap_field unions.
drvOms58.h - all control/status registers.
Modification Log from R4-2 to R4-3
==================================
1) An error was introduced into the motor record when item #14 under R4-2 was
implemented. 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 MIP 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.
File modified: motorRecord.c - Changed logic in do_work() so that the
stop command is always sent to the controller when the STOP
field is activated; but, the MIP field in only set to the
"stop" state if the current state is not STOP or DONE.
2) Due to ambiguous and conflicting Newport PM500 documentation, the velocity
and acceleration values for the PM500 controller were off by a factor of 1,000.
File modified: devPM500.c - Scaled velocity, acceleration and jogging
command parameters by 1,000.
3) HIDEOS is no longer supported.
Files modified: config/RELEASE - Removed HIDEOS path.
motorApp/CommSrc/Makefile.Vx - Removed HIDEOS.
4) Added Mark Rivers soft channel modifications as a conditional compilation
option (i.e., DMR_SOFTMOTOR_MODS).
Files modified: motorApp/MotorSrc/Makefile.Vx
motorApp/MotorSrc/motorRecord.c
motorApp/SoftMotorSrc/Makefile.Vx
motorApp/SoftMotorSrc/devSoft.h
motorApp/SoftMotorSrc/devSoft.c
5) The Soft Channel device driver example, softex.db, was removed from
motorExApp/Db and replaced with a GDCT compatible copy, SoftMotorEx.db. The
corresponding GDCT data file is SoftMotorEx.
Modification Log from R4-1 to R4-2
==================================
1) The following requirement was lost with release V4.0. 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.
File modified: motorRecord.c - Changed logic in
check_speed_and_resolution().
2) An error was introduced into the Oms device support with V4.0. The 1st
argument of the omsSetup(nCards, ...) function in the st.cmd file is for the
maximum number of VME8 and/or VME44 cards to be supported in a specific IOC
crate. If the "nCards" argument was set to anything other than the actual
number of cards in the IOC crate, the "dbior" function would result in
erroneous information or a bus error.
File modified: drvOms.c - Restored statement in motor_init() that sets
motor_state[] to NULL when card not found.
3) 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.
File modified: devOmsCom.c - Changed logic in oms_build_trans() to
prefix MP or MM command to any move when overtravel
status indicator is ON.
4) Added support for EPICS GPIB Module Version 0-0 from Benjamin Franksen.
Warning! Neither GPIB 0-0 are my usage of it has been throughly tested yet.
Files modified: config/RELEASE - Configuration instructions added.
CommSrc/Makefile.Vx - Conditional compilation label.
CommSrc/gpibIO.c - Conditional compilation for
unbundled GPIB module.
5) All motorApp/*/Makefile.Vx files were modified to take advantage of the
macro found in Benjamin Franksen's makefiles; i.e.,
LIBOBJS = $(SRCS.c:../%.c=%.o)
6) Replaced all occurrences of "include <stdioLib.h>" with "include <stdio.h>.
Wind River has labeled stdioLib.h as "obsolete vxWorks 5.0 header file".
Files modified: drvOms.c, drvOms58.c, devMM3000.c, devMM4000.c,
drvMM3000.c, drvMM4000.c
7) Added support for the Newport PM500 motion controller. This device/driver
is based on Mark River's PM500 V2.0 release.
Files added: devPM500.c and drvPM500.c
8) Removed QUERY from the list of valid "command types". It was unused.
Enumerated message types.
File modified: motordrvCom.h and motordrvCom.c
9) Some motor controllers (e.g., PM500) unconditionally respond when motor
commands are sent. Although these communication responses are not needed
(they are in fact a nuisance), they must be received so that later communication
transactions are kept in synchronization. To this end, a flag was added to the
"controller" structure to indicate where or not the associated motor controller
responds to all commands.
Files modified: motordrvCom.h - Added "cmnd_response" member to
"controller".
motordrvCom.c - Get controller response if
"cmnd_response" is set ON.
drvMM3000.c, drvMM400.c, drvOms.c drvOms58.c - Initialize "cmnd_response".
10) Modifications were made to the following files to adopt Mark River's
method of command line termination; i.e., the send_mess() function appends
the command line termination character to the string.
Files modified:
motordrvCom.h
motordrvCom.c - Removed command line terminator argument from
motor_send() and driver_table member, send().
motordevCom.h - Function declaration changes.
motordevCom.c - Removed command line terminator argument from
motor_end_trans_com().
11) Added support for the Intelligent Motion Systems, Inc. IM483 controller.
Two device/driver versions are available; IM483PL for "party line" and IM483SM
for "single" communication mode. See the IMS "Software Reference manual
Revision 051794 for detail.
Directory added: motorApp/ImsSrc
Files added: drvIM483.h, devImsMotor.dbd
devIM483SM.c, drvIM483SM.c
devIM483PL.c, drvIM483PL.c
Files modified: motorApp/Makefile - Added ImsSrc directory.
12) 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] 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.
Files modified:
motordrvCom.c - process_messages() searches for a record
separator. If found, it splits the message,
outputs the 1st part and stores the 2nd part
back into the front of the message buffer.
- query_axis() detects 2nd part of messages,
outputs it and clears the message buffer.
13) For those controllers whose command lines require an alphabetic character
for the axis name identifier (e.g. OMS, Oms58, IMS483PL), support has been
added for driver specific axis names. An axis name array pointer was added to
the driver_table structure.
Files modified:
motordrvCom.h - Moved mess_card_query member axis_names to
driver_table.
motordrvCom.c - The global oms_trans_axis[] was removed.
motordevCom.h - Removed axis "name" member from axis_stat.
motordevCom.c - Removed initial string function argument from
motor_start_trans_com().
All drv{driver}.c files were modified to add an axis name
array point to their driver_table; (NULL for
device/drivers that do not use axis names;
e.g., MM3000, MM4000/5).
14) An error was introduced in V4.0 which prevented the record from processing
a jog request if the UEIP field was changed. Issuing a STOP or SPMG/STOP,
cleared the error.
Files modified: motorRecord.c - Activate DMOV when loading a position
(i.e., load_pos() called).
15) Removed unused C macros from driver level files.
Files modified: - devMM3000.c,
16) Records were stuck with DMOV = 0 if the user requested a move and there
was no underlying controller. No error message, besides the "card does not
exist" message at boot-up, would appear. With this release, the COMM_ALARM is
set and DMOV is reset if the controller does not exist.
File modified: - motor_end_trans_com() in motordevCom.c
17) An error was introduced in V4.0 which prevented backlash correction from
occurring after a JOG.
Files modified: postProcess() in motorRecord.c
18) Divide-by-zero errors were occurring in do_work() of motorRecord.c.
File modified: Added various error checks in motorRecord.c against
ERES becoming zero
19) Two motion commands were being sent by do_work() if the record was
processed twice before a callback was processed. This could occur under
various scenarios
- banging on the tweak button with a low frequency update rate.
- the motor record was (accidentally) processed from a periodic scan
with a higher frequency than the update rate.
File modified: In motorRecord.c, do_work(), changed the "motor moving"
test from the "movn" to the "mip" field.
20) An error was introduced into the motor record with V4.0. This error
occurred 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). The motor record would 'hang'
under these circumstances with DMOV set FALSE and RCNT set to one.
Files modified: motorRecord.dbd - erroneous retries were a result of
round-off error. Changed RES from a 'float'
to a 'double'.
motorRecord.c - Prior to V4.0, do_work() handled
retry request to the same position by setting
DMOV true and exiting (see code;
(npos == rpos)). Broke this logic in V4.0
because of item #13. Fixed, by testing for
MIP_RETRY, and clearing MIP.
21) Moved device specific structure "encoder_status" from motordrvCom.h to
drvOmsCom.h.
Files modified: motordrvCom.h and drvOmsCom.h
Modification Log from R4-0 to R4-1
==================================
1) Three 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 interrupts were enabled.
File modified: drvOms58.c
Function modifications:
start_status() - Wait forever for control register update bit
to clear before setting.
set_status() - Request Data Area Update after DONE detected
so that both ASCII command data and
shared memory data match.
motorIsr() - Only write to control register if update bit
is off (the ISR was clearing the
update bit rather than the VME58 board.
2) Moved the Serial/GPIB communication label definitions from Newport specific
drvMMCom.h to the more general motordrvCom.h. New motor controllers will
require these labels.
Files modified: drvMMCom.h, motordrvCom.h, drvMM4000.c, drvMM3000.c
3) With previous releases, when using the motor record with soft channel
device support, the DMOV field would become stuck on if the user put the motor
in SET mode and entered a new DVAL or RVAL. With this release, the above user
action (i.e., "setting" a soft motor) results in the record being processed;
which, in most cases, will clear DMOV.
Files modified: devSoft.h, devSoft.c, devSoftAux.c
4) A problem with issuing a stop command (via either the STOP or SPMG field)
was found with ALL OMS boards and ALL versions of the OMS device drivers. The
root cause of this problem is a statement in the OMS manual that is not
entirely correct; i.e., the AC and VL commands are not completely queued.
The motor record issues both the target move and the backlash move on the same
command line to the motor controller. Each move (target and backlash) has its'
own acceleration rate. The problem was that when a STOP command was issued
during the target move, the backlash acceleration would go into effect. This
could result in a prolonged deceleration if the backlash acceleration rate
(BACC) is much smaller than the target acceleration rate (ACCL).
With this release both the devOms and the devOms58 device support issue the
target acceleration rate (ACCL) with the STOP command.
File modified: devOmsCom.c
Modification Log from V3-5 to R4-0
==================================
1) EPICS base 3.13.1 compatibility.
- Changed dev{Connect/Disconnect}Interrupt() to
dev{Connect/Disconnect}InterruptVME()
Files modified: drvOms.c, drvOms58.c
2) Newport MM3000 Device Support.
- Renamed drvMM400.h -> drvMMCom.h
- Added device and driver support in source code files "devMM3000.c"
and "drvMM3000.c".
- Modified MM3000_build_trans() in "devMM3000.c" and
motor_end_trans_com() in "motordevCom.c" to prevent motor
commands from being sent if card does not exists. Bus error
occurred with MM3000 device/driver when card did not exists
and motion was commanded from medm display.
3) Eliminated the GAIN field and the associated SET_CGAIN command;
Files modified: motorRecord.dbd, motor.h, devMM3000.c, devMM4000.c,
devOmsCom.c, and motorRecord.c
4) Previous releases of the motor record had a potential problem associated
with the homing function. The motorx_all.adl MEDM display set the
HOM[F/R] fields on and off. Depending on the pollRate defined in the
st.cmd Setup command and the speed at which the user toggled the
HOM[F/R] buttons; the record level software would turn off the DMOV
field when the HOM[F/R] button was turned off and a motor status update
had not yet been received. As a result, when the motor completed it's
homing function the command positions (i.e., VAL, DVAL, RVAL) were not
updated.
All previous motor record releases contained the DMOV problem; the
commanded position update problem was limited to the previous release
(V3.5). With this release, a dbPutField to either HOMF or HOMR is
valid on a FALSE to TRUE transition (i.e., 0 to 1), but a TRUE to FALSE
transition (i.e., 1 to 0) will result in an error.
- Modified motorRecord.dbd; added HOM[F/R] "special" processing.
- Modified motorRecord.c; since OPI can't reset HOM[F/R], postProcess()
does it; return error from special() if OPI tries to write to
HOM[F/R] when MIP indicates homing active.
5) Previous releases of the motor record allowed the auto restore to take
precedence over the controller when initializing the target position
(i.e., DVAL). With this release, 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.
- Modified motor_init_record_com() in motordevCom.c so that a "Load
Pos" command is issued only if the position from the
controller is zero.
6) Consolidated common driver local variables in the motordrvComCode.h file.
- Created motordrvComCode.h
- Moved common local variables from drvOms.c, drvOms58.c, drvMM3000.c,
drvMM4000.c
7) Uninitialized Oms/Oms58 Driver Error Check. With previous release, if the
Oms or Oms58 driver was some how omitted from the database, a "... card
does not exist" error message would result. With this release, an
explicit error check and corresponding error message (i.e., "Oms[58]
driver uninitialized.") results 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.)
- Added pointer to initialized indicator to driver table structure in
motordrvCom.h
- Added error checks in oms_init() and oms_end_trans() in both devOms.c
and devOms58.c
- For drvOms.c, drvOms58.c, drvMM3000.c and drvMM4000.c
- initialized pointer to local initialized indicator in driver
table.
- set initialized indicator ON in init().
8) Both the MM3000 and MM4000 device driver support could generate a bus error
under the following conditions:
1) The user selected GPIB communication mode.
2) At boot-up, the driver could not communicate with the device,
resulting in a "... card does not exist!" error.
3) Motor motion is commanded.
- Modified MM3000_build_trans() and MM4000_build_trans() in devMM3000.c
and devMM4000.c, respectively, to test for NULL board pointer.
9) Eliminated MM3000 and MM4000 device driver "internal" offset.
- Removed "offset" from MM3000_build_trans() and MM4000_build_trans()
in devMM3000.c and devMM4000.c, respectively.
- Read controller's home preset position at boot-up; save and restore
save home preset position when "setting" DVAL or RVAL.
10) For MM4000/40005 only, the controller's position resolution (TU controller
command) is read and saved so that the device driver can convert
between motor record "raw" positions and controller egu's.
11) Modified report() in drvMM4000.c by adding message; "MM4000 controller #
connection failed."
12) For the MM3000 when the GPIB communication interface is selected; sometimes
the MM3000 returns a NULL communication response. Hence, set_status()
in drvMM3000.c was modified to detect a NULL response and resend the
status query.
13) A jog request occurring during a jog induced backlash correction would,
intermittently, cause the MM4000 to go into an uncontrolled jog; i.e.,
the user would set JOG[F/R] false, but the jogging would not stop.
This occurred because the sequence of events were as follows:
<- mip = 0
JOGF=1 ->
<- mip = 1; Jog command
JOGF=0 ->
<- Stop command
<- Done
<- mip = 4; backlash command
JOGF=1 ->
<- Done
<- mip = 1; Jog command
<- mip = 4; backlash command
JOGF=0 ->
In the above event sequence, since mip=4 when JOGF is set to zero, no
stop command is sent. The MM4000 only accepts one motion command at
a time. Therefore, the last backlash command is ignored in the above
event sequence. The end result is an uncontrolled jog operation.
Modifications were made to motorRecord.c to fix this; in general, a
finite state machine was strictly enforced on jog request, jogging,
stopping a jog and the backlash after jogging. Jog processing is
isolated from the JOG[F/R] fields. Specifically,
- Added two new state indicators to MIP; MIP_JOG_REQ and MIP_JOG_STOP.
The jog states now consist of the following; Start (mip=0),
Request, Jogging, Stopping and Backlash.
- In postProcess();
- replaced (MIP_JOGF | MIP_JOGR) with (MIP_JOG_STOP)
when testing for done stopping after jogging.
- replaced (pmr->jogf || pmr->jogr) with MIP_JOG_REQ
when testing for done stopping after jog.
- "Queued" jog request (stop and jog buttons both on)
processing has been moved from postProcess() to do_work().
- Skip backlash operation if backlash distance is zero.
- In maybeRetry();
- Clear MIP if Max retry count (RTRY) set to zero.
- When clearing MIP, don't clear MIP_JOG_REQ.
- In do_work();
- Detect and process "Queued" jog request.
- Use MIP state indicators rather than JOG[F/R] fields to
process jog function.
- Don't want "DVAL has changed..." logic to get processed when
doing jog stop or backlash. Detect and do Normal Return.
- In special(); Set MIP_JOG_REQ on only if MIP=0 and the corresponding
hardware limit switch is not active.
14) Eliminated device dependent code from process_messages() in motordrvCom.c;
specifically, removed concatenating a carriage return to end of
controller message. The new method is to pass a pointer to the
command line terminator string in function arguments; beginning with
<device>_end_trans(), through motor_end_trans_com() in motordevCom.c,
to the "send()" function specified in the driver table.
Files modified: motordevCom.h, motordrvCom.h, devMM3000.c, devMM4000.c,
devOms.c, devOms58.c
15) In motordrvCom.h, changed "controller" structure member "MMptr" to
"DevicePrivate".
Files modified: devMM3000.c, devMM4000.c
16) All files were modified as follows:
- standard headers were added.
- original headers and modification history's were restored.
- all instances of #include <motorRecord.h> have been changed to
#include "motorRecord.h". As Mark Rivers explained, 'Include files
which are in <> are not included in dependencies by GCC. Thus, if
motorRecord.dbd is changed, devMM4000.c will not be recompiled unless
the <> are changed to "".'
17) The task name associated with each device driver has been given a unique
name; i.e. "<device>_motor". Previously, all the motor tasks were
given the same task name, "tmotor". This prevents using some of the
Tornado tools (Browser, CrossWind, etc.).
Files modified: drvMM3000.c, drvMM4000.c, drvOms.c, drvOms58.c
18) Removed my_strtok() from and replace with VxWorks library function
strtok_r().
Files modified: drvMM3000.c, drvMM4000.c, drvOms.c, drvOms58.c
19) Added record report function for Oms driver. File modified: drvOms.c
20) Added maximum allowable velocity fields; VMAX and SMAX.
- VMAX/SMAX added to motorRecord.dbd with Access Security Limit = 0.
- changed the Access Security Level for MRES, UREV, VBAS and SBAS from
one to zero.
- see motorRecord.html for valid velocity range limits.
- optimized calls to fabs(pmr->urev).
- added range_check() for validity checking bounded fields.
- In order to support backup and restore functions, the range checking
is done in such a way that the last minimum (i.e., VBAS/SBAS) or
maximum (i.e., VMAX/SMAX) value entered is always valid. For example,
if the minimum is entered and it exceeds the maximum, then the maximum
is set to the new minimum value.
Files modified: motorRecord.dbd, motorRecord.c
21) With MM4000 device support, a tweak request (TWF/TWR) occurring during the
processing of a previous tweak request, would intermittently leave the
MIP field in a nonzero state (i.e., mip = 0x20). A nonzero MIP field
prevents processing a jog request.
File modified: motorRecord.c
Removed code that set DMOV TRUE. See do_work() under the following
logic;
IF DVAL field has changed
IF the SET position field is OFF
IF last dial commanded position = current dial feedback
position.
22) An infinite home velocity was being issued if the MSTA "encoder present"
bit was on, ERES=0 and UEIP=NO.
File modified: init_record() in motorRecord.c;
if ERES = 0, set ERES <- MRES.
23) Setting MRES negative could invalidated comparisons between BDST and RES.
File modified: motorRecord.c
- in postProcess(), (pmr->bdst != 0.0) to (|BDST| < |RES|).
- in do_work(), (|BDST| < RES) to (|BDST| < |RES|).
24) Moved OMS device specific code that enforced VELO > VBAS from do_work() in
motorRecord.c to oms_build_trans() in devOmsCom.c
25) No longer put MM4000 in "remote mode". User can do this by putting "MR;"
in the INIT field. File modified: drvMM4000.c
26) MM4000_build_trans() in devMM4000.c was overflowing its character buffer
(i.e., buff) when processing a LOAD_POS command. Increased buffer
size to controller maximum (110) and added buffer overflow detection
for both the local buffer and the "mess_node" message buffer.
27) Added model detection to MM4000/5 device driver. The long term plan
is to have the same source code support both MM4000 and MM4005
controllers and use the "model" indicator to tailor the device
driver support to either controller at run time. With this release
the "model" variable is used to ignore (i.e. NO-OP) the LOAD_POS motor
command for the MM4005. This is an interim solution until Newport
releases controller firmware that explicitly supports a LOAD_POS
command.
Files modified: drvMMCom.h, drvMM4000.c and devMM4000.c
28) When a MM4000's motor resolution is small, the MM4000 communicates the
motor's resolution in scientific notation. The MM4000 driver was not
processing the number of significant decimal points correctly when the
controller used scientific notation for the motor resolution.
Files modified: motor_init() in drvMM400.c
29) 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.
Files modified: start_status() in drvOms58.c
for (index = 0; index < total_cards; index++)
{
if((pmotor=(struct vmex_motor *) motor_state[card]->localaddr)!=0)
^
wrong | index
30) A "Controller communication error" bit was allocated in the MSTA field.
Currently, only the MM4000/5 device driver sets this error indicator.
Files modified: motor.h, drvMMCom.h, motorRecord.c, drvMM4000.c
31) The "soft_motor" task (i.e., Soft channel device driver support task) was
nearly running out of stack space. Increased stack allocation from
1,000 to 5,000 bytes.
Files modified: devSoftAux.c