forked from epics_driver_modules/motorBase
Ron Sluiter
675 lines
31 KiB
Plaintext
675 lines
31 KiB
Plaintext
Motor Record V4.4 Release Notice
|
|
================================
|
|
|
|
The motor record software in this release is compatible with EPICS base
|
|
R3.13.2, R3.13.3 and R3.13.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.
|
|
ImsLib - Intelligent Motion Systems controllers; ImsSrc directory.
|
|
newportLib - Newport controllers; NewportSrc directory.
|
|
omsLib - Oregon Micro System controllers; OmsSrc directory.
|
|
softMotorLib - 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.13.2 or above.
|
|
- MPF V1.5 or above.
|
|
- MPF_SERIAL V1.1 or above
|
|
- either MPF_GPIB V1.3 or GPIB V0.1 or above.
|
|
|
|
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) With the exception of jogging, motor record controlled backlash correction
|
|
does not work with the Newport MM4000. Since the MM4000 controller
|
|
has its' own backlash compensation feature, there are no plans to fix
|
|
this in future releases. Users of the MM4000 who need backlash
|
|
compensation should set the motor record's backlash distance to zero
|
|
and program the MM4000 controller's backlash compensation parameters.
|
|
|
|
2) 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.
|
|
|
|
|
|
|
|
Modification Log from V4.3 to V4.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 V4.2 to V4.3
|
|
==================================
|
|
|
|
1) An error was introduced into the motor record when item #14 under V4.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 V4.1 to V4.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 V4.0 to V4.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 V4.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
|
|
|
|
|