From dcf70e804f9b1a15bd609d793fd577ea7fc61482 Mon Sep 17 00:00:00 2001 From: Ron Sluiter Date: Thu, 18 Jul 2002 19:14:13 +0000 Subject: [PATCH] R4.5 updates. --- README | 257 +- documentation/motorRecord.html | 8076 +++++++++++++----------------- documentation/motor_release.html | 1344 ++--- 3 files changed, 4396 insertions(+), 5281 deletions(-) diff --git a/README b/README index 0fe39a58..d6519cbd 100644 --- a/README +++ b/README @@ -1,8 +1,8 @@ -Motor Record V4.4 Release Notice -================================ +Motor Record R4-5 Release Notice +=============================================================================== The motor record software in this release is compatible with EPICS base -R3.13.2, R3.13.3 and R3.13.4. +R3.13.3, R3.13.4 and R3.13.5. Contents @@ -22,9 +22,12 @@ As distributed, this support directory only builds the following: 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. + ImsLib - Intelligent Motion Systems (IMS) controllers; ImsSrc + directory. newportLib - Newport controllers; NewportSrc directory. - omsLib - Oregon Micro System controllers; OmsSrc directory. + omsLib - Oregon Micro System (OMS) controllers; OmsSrc directory. + AcsLib - Advanced Control Systems controllers; AcsSrc directory. + MclennanLib - Mclennan controllers; MclennanSrc directory. softMotorLib - Soft Channel device support; SoftMotorSrc directory. motorCOM_mpf - Communication interface between motor device/drivers and MPF; CommSrc directory. @@ -53,24 +56,234 @@ needs. See individual files for instructions. - ./motorApp/Makefile: Define which device/driver modules to build. - ./motorExApp/Makefile: Define which, if any, example applications are to be built. + +Newport - Newport device drivers require both MPF_SERIAL and MPF_GPIB support. 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 +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. -Modification Log from V4.3 to V4.4 +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 /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 @@ -141,10 +354,10 @@ Modification Log from V4.3 to V4.4 -Modification Log from V4.2 to V4.3 +Modification Log from R4-2 to R4-3 ================================== -1) An error was introduced into the motor record when item #14 under V4.2 was +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 @@ -178,7 +391,7 @@ corresponding GDCT data file is SoftMotorEx. -Modification Log from V4.1 to V4.2 +Modification Log from R4-1 to R4-2 ================================== 1) The following requirement was lost with release V4.0. At boot-up, if one @@ -279,6 +492,7 @@ record separator is allowed in a command line. - 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 @@ -347,7 +561,7 @@ drvOmsCom.h. Files modified: motordrvCom.h and drvOmsCom.h -Modification Log from V4.0 to V4.1 +Modification Log from R4-0 to R4-1 ================================== 1) Three errors in the OMS VME58 driver were found. All the errors caused the @@ -397,7 +611,7 @@ target acceleration rate (ACCL) with the STOP command. File modified: devOmsCom.c -Modification Log from V3.5 to V4.0 +Modification Log from V3-5 to R4-0 ================================== 1) EPICS base 3.13.1 compatibility. @@ -611,7 +825,8 @@ Modification Log from V3.5 to V4.0 logic; IF DVAL field has changed IF the SET position field is OFF - IF last dial commanded position = current dial feedback position. + 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. @@ -658,7 +873,7 @@ Modification Log from V3.5 to V4.0 Files modified: start_status() in drvOms58.c for (index = 0; index < total_cards; index++) { - if ((pmotor = (struct vmex_motor *) motor_state[card]->localaddr) != 0) + if((pmotor=(struct vmex_motor *) motor_state[card]->localaddr)!=0) ^ wrong | index diff --git a/documentation/motorRecord.html b/documentation/motorRecord.html index ec451c05..a56bb35b 100644 --- a/documentation/motorRecord.html +++ b/documentation/motorRecord.html @@ -1,4718 +1,3556 @@ - + - - - Motor Record and related software + + + + + Motor Record and related software - - -

-Motor Record and related software

- -
-Tim Mooney, Joe Sullivan, Ron Sluiter
- -
-
-

-Contents

- + + +

Motor Record and related software

+ +
Tim Mooney, Joe Sullivan, Ron Sluiter
+
+ +
+

Contents

+ - -

-Overview

-This documentation describes version 4.4 of the EPICS motor record, and -related EPICS software required to build and use it.  Version 4.4 -of the motor record is compatible with EPICS baseR3.13.2 and above. + + +

Overview

+ This documentation describes version 4.5 of the EPICS motor record, and +related EPICS software required to build and use it.  Version 4.5 of +the motor record is compatible with EPICS base R3.13.6 and above.

The motor record is intended to support motors of all kinds, but currently -supports only the following variety of motor controllers (in addition to -Soft Channel support): + supports only the following variety of motor controllers (in addition to +Soft Channel support):

+ -The record maintains two coordinate systems for motor position ("user" + The record maintains two coordinate systems for motor position ("user" and "dial" coordinates); displays drive and readback values; enforces limits -to motor motion and maintains those limits in both coordinate systems; -displays the states of limit switches; can use a home switch; optionally -takes out backlash in a user-defined direction; and provides a mechanism -by which the user and other EPICS records can recalibrate the motor position -in either coordinate system. The record also supports "tweak", "jog", and -"home" motions, and supports both absolute and relative motions in user -coordinates. Two "stop" switches are provided: a simple one for use by -other records and by channel-access clients, and a more versatile one for -interactive use. +to motor motion and maintains those limits in both coordinate systems; displays +the states of limit switches; can use a home switch; optionally takes out +backlash in a user-defined direction; and provides a mechanism by which the +user and other EPICS records can recalibrate the motor position in either +coordinate system. The record also supports "tweak", "jog", and "home" motions, +and supports both absolute and relative motions in user coordinates. Two "stop" +switches are provided: a simple one for use by other records and by channel-access +clients, and a more versatile one for interactive use.

Except where specified otherwise, fields associated with the motor position -and its derivatives take values in user-specified "engineering units", -such as degrees; the engineering unit name is contained in the field EGU. -Thus, generally, speeds are expressed in EGU's per second. Accelerations, -however, are expressed as the number of seconds taken to accelerate to -full speed. However, additional fields are provided so that the motor position -can be specified in steps and the speed in revolutions per second, and -so that the step size can be set by specifying the number of steps per -revolution and the number of EGU's per revolution. + and its derivatives take values in user-specified "engineering units", such +as degrees; the engineering unit name is contained in the field EGU. Thus, +generally, speeds are expressed in EGU's per second. Accelerations, however, +are expressed as the number of seconds taken to accelerate to full speed. +However, additional fields are provided so that the motor position can be +specified in steps and the speed in revolutions per second, and so that the +step size can be set by specifying the number of steps per revolution and +the number of EGU's per revolution.

+

The motor record can read motor position from the controller's readback -register or encoder register, or from any other EPICS record, via an EPICS -input link. While the motor is moving, the record can trigger an output -link periodically, to send readback information to other EPICS records. -When a complete motion (possibly including backlash takeout) is finished, -the record can trigger a forward link to process other EPICS records. + register or encoder register, or from any other EPICS record, via an EPICS + input link. While the motor is moving, the record can trigger an output +link periodically, to send readback information to other EPICS records. When +a complete motion (possibly including backlash takeout) is finished, the +record can trigger a forward link to process other EPICS records.

+

The motor record can force its drive fields to agree with its readback -fields, and it does so in a variety of circumstances (e.g., when the user -tells a motor to stop, and when a limit switch is hit). Therefore, if you -are driving the motor record's VAL or DVAL field with the output of another -record, and you want that record always to contain the same value as the -motor record, you must handle this behavior in the database. One way to -do this is to forward link the motor record to a soft analog output record, + fields, and it does so in a variety of circumstances (e.g., when the user + tells a motor to stop, and when a limit switch is hit). Therefore, if you + are driving the motor record's VAL or DVAL field with the output of another + record, and you want that record always to contain the same value as the +motor record, you must handle this behavior in the database. One way to do +this is to forward link the motor record to a soft analog output record, and to cause that AO record to grab the motor record's VAL or DVAL field -and poke it into your record. +and poke it into your record.

+

The motor record is unlike most other EPICS records in that its processing -is neither "synchronous" nor "asynchronous", as these terms are used in -the EPICS Record Reference Manual. Currently, the PACT field is always -FALSE after record processing has completed, even though a motor motion -may be in progress. This means the record always responds to channel-access -puts, and can be stopped or retargeted at any time. The record's forward -link is not executed until the motor has stopped and no motion requests -are pending.  -

-Field Descriptions

-In addition to fields common to all record types (see the EPICS -Record Reference Manual for these) the motor record has the fields -described below. + is neither "synchronous" nor "asynchronous", as these terms are used in +the EPICS Record Reference Manual. Currently, the PACT field is always FALSE +after record processing has completed, even though a motor motion may be in +progress. This means the record always responds to channel-access puts, and +can be stopped or retargeted at any time. The record's forward link is not +executed until the motor has stopped and no motion requests are pending.  +

+ +

Field Descriptions

+ In addition to fields common to all record types (see the + EPICS Record Reference Manual + for these) the motor record has the fields described below. - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

-Alphabetical list of record-specific fields

-NOTE: Hot links in this table take you only to the section in which -the linked item is described in detail. You'll probably have to scroll -down to find the actual item.
Name Access Prompt Data type Comment
ACCLR/W Seconds to Velocity FLOAT acceleration time
ATHMR At HOME SHORT uses the HOME switch
BACCR/W BL Seconds to Veloc. FLOAT backlash acceleration time
BDSTR/W BL Distance (EGU) FLOAT backlash distance
BVELR/W BL Velocity (EGU/s) FLOAT backlash speed
CARDR Card Number SHORT EPICS card #
CBAKNoneCallback structureNOACCESS
CNENR/WEnable controlRECCHOICE(0:"Disable", 1:"Enable")
DCOFR/WDerivative GainFLOAT
DHLMR/W* Dial High Limit FLOAT 
DIFFR Difference dval-drbv DOUBLE 
DINPR/WDMOV Input LinkINLINK
DIRR/W* User Direction RECCHOICE (0:"Pos", 1:"Neg")
DLLMR/W* Dial Low Limit FLOAT 
DLYR/WReadback settle time (s)FLOAT
DMOVR Done moving to value SHORT The "done" flag
DOLR Desired Output LocINLINK only for closed-loop mode
DRBVR Dial Readback Value DOUBLE 
DVALR/W* Dial Desired Value DOUBLE 
EGUR/W Engineering Units STRING 
ERESR/W* Encoder Step Size (EGU) FLOAT 
FOFR/W Freeze Offset SHORT 
FOFFR/W Offset-Freeze Switch RECCHOICE (0:"Variable", 1:"Frozen")
FRACR/W Move Fraction FLOAT 
HHSVR/W* Hihi Severity GBLCHOICE
HIGHR/W* High Alarm Limit FLOAT 
HIHIR/W* Hihi Alarm Limit FLOAT 
HLMR/W* User High Limit FLOAT 
HLSR At High Limit Switch SHORT 
HLSVR/W* HW Lim. Violation Svr GBLCHOICE 
HOMFR/W* Home Forward SHORT 
HOMRR/W* Home Reverse SHORT 
HOPRR/W High Operating Range FLOAT 
HSVR/W* High Severity GBLCHOICE 
ICOFR/WIntegral GainFLOAT
INITR/WStartup commandsSTRING
JARR/WJog Acceleration (EGU/s^2)FLOAT
JOGFR/W* Jog motor Forward SHORT careful!
JOGRR/W* Jog motor Reverse SHORT careful!
JVELR/WJog VelocityFLOAT
LDVLR Last Dial Des Val DOUBLE 
LLMR/W* User Low Limit FLOAT 
LLSR At Low Limit Switch SHORT 
LLSVR/W* Lolo Severity GBLCHOICE 
LOLOR/W* Lolo Alarm Limit FLOAT 
LOPRR/W Low Operating Range FLOAT 
LOWR/W* Low Alarm Limit FLOAT 
LRLVR Last Rel Value DOUBLE 
LRVLR Last Raw Des Val DOUBLE 
LSPGRLast SPMG RECCHOICE (See SPMG)
LSVR/W* Low Severity GBLCHOICE 
LVALR Last User Des Val DOUBLE 
LVIOR Limit violation SHORT 
MIPR Motion In Progress SHORT 
MISSR Ran out of retries SHORT 
MMAPR Monitor Mask ULONG 
MOVNR Motor is moving SHORT Don't confuse with DMOV
MRESR/W* Motor Step Size (EGU) FLOAT 
MSTAR Motor Status ULONG 
NMAPR Monitor Mask ULONG 
OFFR/W User Offset (EGU) DOUBLE 
OMSLR/W Output Mode Select GBLCHOICE 
OUTR/WOutput Specification OUTLINK 
PCOFR/WProportional GainFLOAT
PERLR/W Periodic Limits RECCHOICE (0:"No", 1:"Yes")
PDIFRPrevious RDIFLONG
POSTR/WPost-move commandsSTRING
PPR Post process command SHORT 
PRECR/W Display Precision SHORT 
PREMR/WPre-move commandsSTRING
RBVR User Readback Value DOUBLE 
RCNTR Retry count SHORT 
RDBDR/W Retry Deadband (EGU) FLOAT 
RDBLR Readback Location INLINK 
RDIFR Difference rval-rrbv LONG 
REPR Raw Encoder Position DOUBLE 
RESR Step Size (EGU) DOUBLE
RHLSR Raw High Limit Switch SHORT 
RINPR/WRMP Input LinkINLINK
RLLSR Raw Low Limit Switch SHORT 
RLNKR Readback OutLink OUTLINK 
RLVR/W* Relative ValueDOUBLE 
RMPR Raw Motor Position DOUBLE 
RRBVR Raw Readback Value DOUBLE 
RRESR/W Readback Step Size (EGU)FLOAT 
RTRYR/W Max retry count SHORT 
RVALR/W* Raw Desired Value DOUBLE 
RVELRRaw Velocity LONG 
SR/W Speed (RPS)FLOAT 
SBAKR/W BL Speed (RPS) FLOAT 
SBASR/W Base Speed (RPS) FLOAT 
SETR/W Set/Use Switch RECCHOICE (0:"Use", 1:"Set")
SMAXR/WMax Velocity (RPS)FLOAT
SPMGR/W* Stop/Pause/Move/Go RECCHOICE (0:"Stop", 1:"Pause", 2:"Move", 3:"Go")
SREVR/W* Steps per Revolution LONG 
SSETR/W Set SET Mode SHORT 
STOOR/WSTOP OutLinkOUTLINK
STOPR/W* Stop SHORT 
SUSER/W Set USE Mode SHORT 
TDIRR Direction of Travel SHORT 
TWFR/W* Tweak motor Forward SHORT 
TWRR/W* Tweak motor Reverse SHORT 
TWVR/W* Tweak Step Size (EGU) FLOAT 
UEIPR/W* Use Encoder If Present RECCHOICE (0:"No", 1:"Yes")
UREVR/W* EGU's per Revolution FLOAT 
URIPR/W* Use RDBL Link If PresentRECCHOICE (0:"No", 1:"Yes")
VALR/W* User Desired ValueDOUBLE 
VBASR/W Base Velocity (EGU/s) FLOAT 
VELOR/W Velocity (EGU/s) FLOAT 
VERSR Code Version FLOAT e.g., "1.95"
VMAXR/WMax Velocity (EGU/s)FLOAT
VOFR/W Variable Offset SHORT 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +
+
Note: In the Access column above: 
RRead only
R/WRead and write are allowed
R/W*Read and write are allowed; write triggers record processing if the -record's SCAN field is set to "Passive."
NNo access allowed
Note: In the Prompt column above:
EGUEngineering Units
RPSRevolutions Per Second
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +

Alphabetical list of record-specific fields

+ NOTE: Hot links in this table take you only to the section in which + the linked item is described in detail. You'll probably have to scroll down +to find the actual item.
Name Access Prompt Data type Comment
ACCL + R/W Seconds to Velocity FLOAT acceleration time
ATHM + R At HOME SHORT uses the HOME switch
BACC + R/W BL Seconds to Veloc. FLOAT backlash acceleration time
BDST + R/W BL Distance (EGU) FLOAT backlash distance
BVEL + R/W BL Velocity (EGU/s) FLOAT backlash speed
CARD + R Card Number SHORT EPICS card #
CBAK + NoneCallback structureNOACCESS
+
CDIR +
+ 		R
+ 		Command direction
+ 		SHORT
+
+
CNEN + R/WEnable controlRECCHOICE(0:"Disable", 1:"Enable")
DCOF + R/WDerivative GainFLOAT
+
DHLM + R/W* Dial High Limit FLOAT 
+
DIFF + R Difference dval-drbv DOUBLE 
+
DINP + R/WDMOV Input LinkINLINK
+
DIR + R/W* User Direction RECCHOICE (0:"Pos", 1:"Neg")
DLLM + R/W* Dial Low Limit FLOAT 
+
DLY + R/WReadback settle time (s)FLOAT
+
DMOV + R Done moving to value SHORT The "done" flag
DOL + R Desired Output LocINLINK only for closed-loop mode
DRBV + R Dial Readback Value DOUBLE 
+
DVAL + R/W* Dial Desired Value DOUBLE 
+
EGU + R/W Engineering Units STRING 
+
ERES + R/W* Encoder Step Size (EGU) FLOAT 
+
FOF + R/W Freeze Offset SHORT 
+
FOFF + R/W Offset-Freeze Switch RECCHOICE (0:"Variable", 1:"Frozen")
FRAC + R/W Move Fraction FLOAT 
+
HHSV + R/W* Hihi Severity GBLCHOICE
HIGH + R/W* High Alarm Limit FLOAT 
+
HIHI + R/W* Hihi Alarm Limit FLOAT 
+
HLM + R/W* User High Limit FLOAT 
+
HLS + R At High Limit Switch SHORT 
+
HLSV + R/W* HW Lim. Violation Svr GBLCHOICE 
+
HOMF + R/W* Home Forward SHORT 
+
HOMR + R/W* Home Reverse SHORT 
+
HOPR + R/W High Operating Range FLOAT 
+
HSV + R/W* High Severity GBLCHOICE 
+
ICOF + R/WIntegral GainFLOAT
+
INIT + R/WStartup commandsSTRING
+
JAR + R/WJog Acceleration (EGU/s^2)FLOAT
+
JOGF + R/W* Jog motor Forward SHORT careful!
JOGR + R/W* Jog motor Reverse SHORT careful!
JVEL + R/WJog VelocityFLOAT
+
LDVL + R Last Dial Des Val DOUBLE 
+
LLM + R/W* User Low Limit FLOAT 
+
LLS + R At Low Limit Switch SHORT 
+
LLSV + R/W* Lolo Severity GBLCHOICE 
+
LOLO + R/W* Lolo Alarm Limit FLOAT 
+
LOPR + R/W Low Operating Range FLOAT 
+
LOW + R/W* Low Alarm Limit FLOAT 
+
LRLV + R Last Rel Value DOUBLE 
+
LRVL + R Last Raw Des Val DOUBLE 
+
LSPG + RLast SPMG RECCHOICE (See SPMG)
LSV + R/W* Low Severity GBLCHOICE 
+
LVAL + R Last User Des Val DOUBLE 
+
LVIO + R Limit violation SHORT 
+
MIP + R Motion In Progress SHORT 
+
MISS + R Ran out of retries SHORT 
+
MMAP + R Monitor Mask ULONG 
+
MOVN + R Motor is moving SHORT Don't confuse with DMOV
MRES + R/W* Motor Step Size (EGU) FLOAT 
+
MSTA + R Motor Status ULONG 
+
NMAP + R Monitor Mask ULONG 
+
OFF + R/W User Offset (EGU) DOUBLE 
+
OMSL + R/W Output Mode Select GBLCHOICE 
+
OUT + R/WOutput Specification OUTLINK 
+
PCOF + R/WProportional GainFLOAT
+
PERL + R/W Periodic Limits RECCHOICE (0:"No", 1:"Yes")
POST + R/WPost-move commandsSTRING
+
PP + R Post process command SHORT 
+
PREC + R/W Display Precision SHORT 
+
PREM + R/WPre-move commandsSTRING
+
RBV + R User Readback Value DOUBLE 
+
RCNT + R Retry count SHORT 
+
RDBD + R/W Retry Deadband (EGU) FLOAT 
+
RDBL + R Readback Location INLINK 
+
RDIF + R Difference rval-rrbv LONG 
+
REP + R Raw Encoder Position DOUBLE 
+
RHLS + R Raw High Limit Switch SHORT 
+
RINP + R/WRMP Input LinkINLINK
+
RLLS + R Raw Low Limit Switch SHORT 
+
RLNK + R Readback OutLink OUTLINK 
+
RLV + R/W* Relative ValueDOUBLE 
+
RMP + R Raw Motor Position DOUBLE 
+
RRBV + R Raw Readback Value DOUBLE 
+
RRES + R/W Readback Step Size (EGU)FLOAT 
+
RTRY + R/W Max retry count SHORT 
+
RVAL + R/W* Raw Desired Value DOUBLE 
+
RVEL + RRaw Velocity LONG 
+
S + R/W Speed (RPS)FLOAT 
+
SBAK + R/W BL Speed (RPS) FLOAT 
+
SBAS + R/W Base Speed (RPS) FLOAT 
+
SET + R/W Set/Use Switch RECCHOICE (0:"Use", 1:"Set")
SMAX + R/WMax Velocity (RPS)FLOAT
+
SPMG + R/W* Stop/Pause/Move/Go RECCHOICE (0:"Stop", 1:"Pause", 2:"Move", 3:"Go")
SREV + R/W* Steps per Revolution LONG 
+
SSET + R/W Set SET Mode SHORT 
+
STOO + R/WSTOP OutLinkOUTLINK
+
STOP + R/W* Stop SHORT 
+
SUSE + R/W Set USE Mode SHORT 
+
TDIR + R Direction of Travel SHORT 
+
TWF + R/W* Tweak motor Forward SHORT 
+
TWR + R/W* Tweak motor Reverse SHORT 
+
TWV + R/W* Tweak Step Size (EGU) FLOAT 
+
UEIP + R/W*Use Encoder If Present RECCHOICE (0:"No", 1:"Yes")
UREV + R/W* EGU's per Revolution FLOAT 
+
URIP + R/W* Use RDBL Link If PresentRECCHOICE (0:"No", 1:"Yes")
VAL + R/W* User Desired ValueDOUBLE 
+
VBAS + R/W Base Velocity (EGU/s) FLOAT 
+
VELO + R/W Velocity (EGU/s) FLOAT 
+
VERS + R Code Version FLOAT e.g., "1.95"
VMAX + R/WMax Velocity (EGU/s)FLOAT
+
VOF + R/W Variable Offset SHORT 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Note: In the Access column above: 
RRead only
+
R/WRead and write are allowed
R/W*Read and write are allowed; write triggers record processing if the + record's SCAN field is set to "Passive."
NNo access allowed
Note: In the Prompt column above:
EGUEngineering Units
RPSRevolutions Per Second
+
-
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

-Calibration-related fields

-
Name Access Prompt Data type Comments 
DIR R/W* User Direction RECCHOICE (0:"Pos", 1:"Neg") 
User and dial values are related by the equation  -
userVAL = DialVAL * DIR + OFFset -
This field is the "DIR" in the above equation. 
OFF R/W User Offset (EGU) DOUBLE User and dial coordinates can differ by a sign (the DIR field) and -an offset (OFF), according to the following equation:  -
userVAL = DialVAL * DIR + OFFset -
This field is "OFFset" in the above equation. It is not normally written + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - + drive field (VAL) to change, and the motor to move.

+ +

When SET = 1 ("Set"), writes to the dial-coordinate drive field (DVAL) +and to the raw drive field (RVAL) cause a new raw motor position to be loaded +into the hardware without any change to the user-coordinate drive field +(VAL). Writes to other fields that would normally move the motor, change the +user-coordinate drive field (VAL), and the offset between user and dial coordinates +(the OFF field), with corresponding changes in the user-coordinate limit +fields (HLM and LLM). When the offset is frozen (FOFF=1), writes to any drive +field affect both user and dial values, and also load the hardware position +register.

+ + + + + + + + + + +
+ +

Calibration-related fields

+
Name Access Prompt Data type Comments 
DIR R/W* User Direction RECCHOICE (0:"Pos", 1:"Neg") 
User and dial values are related by the equation  +
+ userVAL = DialVAL * DIR + OFFset
+ This field is the "DIR" in the above equation. 

+
+
+
+
+
OFF R/W User Offset (EGU) DOUBLE User and dial coordinates can differ by a sign (the DIR field) and +an offset (OFF), according to the following equation: 
+ userVAL = DialVAL * DIR + OFFset
+ This field is "OFFset" in the above equation. It is not normally written to directly by the user. 
FOFF R/W Offset-Freeze Switch RECCHOICE (0:"Variable", 1:"Frozen")
VOF R/W Variable Offset SHORT Set Offset switch (FOFF) to "Variable".
FOF R/W Freeze Offset SHORT Set Offset switch (FOFF) to "Frozen".
The user can cause the difference between user and dial +
FOFF R/W Offset-Freeze Switch RECCHOICE (0:"Variable", 1:"Frozen")
VOF R/W Variable Offset SHORT Set Offset switch (FOFF) to "Variable".
FOF R/W Freeze Offset SHORT Set Offset switch (FOFF) to "Frozen".
The user can cause the difference between user and dial coordinates to remain fixed (i.e., the record will not change it, although the user may) by setting FOFF to "Frozen." The fields VOF and FOF are intended -for use in backup/restore operations; any write to them will drive the -FOFF field to "Variable" (VOF) or "Frozen" (FOF). 
SET R/W Set/Use Switch RECCHOICE(0:"Use", 1:"Set")
SSET R/W Set SET Mode SHORT Set Set/Use switch to "Set".
SUSE R/W Set USE Mode SHORT Set Set/Use switch to "Use".
SET is a toggle switch used in calibrating the motor's -user and dial positions:  -

When SET = 0 ("Use"), writes to the user-coordinate drive field (VAL) +for use in backup/restore operations; any write to them will drive the FOFF +field to "Variable" (VOF) or "Frozen" (FOF). 


+
+
+
+
+
SET R/W Set/Use SwitchRECCHOICE(0:"Use", 1:"Set")
SSET R/W Set SET Mode SHORT Set Set/Use switch to "Set".
SUSE R/W Set USE Mode SHORT Set Set/Use switch to "Use".
SET is a toggle switch used in calibrating the motor's +user and dial positions:  +

When SET = 0 ("Use"), writes to the user-coordinate drive field (VAL) cause the dial-coordinate drive field (DVAL) to change, and the motor to move. Writes to the dial-coordinate drive field (DVAL) cause the user-coordinate -drive field (VAL) to change, and the motor to move. -

When SET = 1 ("Set"), writes to the dial-coordinate drive field (DVAL) -and to the raw drive field (RVAL) cause a new raw motor position to be -loaded into the hardware without any change to the user-coordinate drive -field (VAL). Writes to other fields that would normally move the motor, -change the user-coordinate drive field (VAL), and the offset between user -and dial coordinates (the OFF field), with corresponding changes in the -user-coordinate limit fields (HLM and LLM). When the offset is frozen (FOFF=1), -writes to any drive field affect both user and dial values, and also load -the hardware position register.


+
+
+
+
+
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

-Motor-resolution fields

-
Name Access Prompt Data type Comments 
MRES R/W* Motor Step Size (EGU) FLOAT May be positive or negative
SREV R/W* Steps per Revolution LONG Must be strictly positive
UREV R/W* EGU's per Revolution FLOAT May be positive or negative 
MRES, and (SREV,UREV) represent two ways of specifying + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - + + +
+ +

Motor-resolution fields

+
Name Access Prompt Data type Comments 
MRES R/W* Motor Step Size (EGU) FLOAT May be positive or negative
SREV R/W* Steps per Revolution LONG Must be strictly positive
UREV R/W* EGU's per Revolution FLOAT May be positive or negative 
MRES, and (SREV,UREV) represent two ways of specifying the motor resolution--the distance or angle, in engineering units (EGU's), associated with a single motor step. The equation relating these quantities -is "MRES = UREV/SREV". Initially, SREV has the value 200, the number of -full steps per revolution for most stepper motors, and the record never -changes this field. Only the user can change it.  -

When MRES is changed, the motor record sets UREV = MRES*SREV. When UREV -or SREV is changed, the motor sets MRES = UREV/SREV. In all cases, the -effect of a motor resolution change on the reported motor position depends -in a simple way on the value of the SET field: -
If (SET = 1), new user and dial values (VAL, DVAL) are calculated from -the existing raw value (RVAL). -
If (SET = 0), a new raw value is calculated from the existing dial -value. -
The motor doesn't move in either case; neither does the actual motor -speed (in revolutions per second) change.  -

If either MRES or UREV is changed, motor speeds that are expressed in -engineering units per second (i.e., those whose names contain the letter -'V': VELO, BVEL, VMAX and VBAS) are automatically adjusted by the motor +is "MRES = UREV/SREV". Initially, SREV has the value 200, the number of full +steps per revolution for most stepper motors, and the record never changes +this field. Only the user can change it.  +

When MRES is changed, the motor record sets UREV = MRES*SREV. When +UREV or SREV is changed, the motor sets MRES = UREV/SREV. In all cases, the + effect of a motor resolution change on the reported motor position depends + in a simple way on the value of the SET field:
+ If (SET = 1), new user and dial values (VAL, DVAL) are calculated from the +existing raw value (RVAL).
+ If (SET = 0), a new raw value is calculated from the existing dial value. +
+ The motor doesn't move in either case; neither does the actual motor speed +(in revolutions per second) change. 

+ +

If either MRES or UREV is changed, motor speeds that are expressed +in engineering units per second (i.e., those whose names contain the letter + 'V': VELO, BVEL, VMAX and VBAS) are automatically adjusted by the motor record according to the following equations: VELO = UREV * S; BVEL = UREV -* SBAK; VMAX = UREV * SMAX; VBAS = UREV * SBAS.  Motor speeds that -are expressed in revolutions per second (S, SBAK, and SBAS) are independent -of changes to MRES or UREV.  In contrast, when SREV is changed, only -MRES is adjusted by the motor record, thus allowing all other fields to -remain unaffected. -

Currently, changes to motor-resolution fields have no effect on the -values of limit fields (although they should).  -

MRES or UREV allow negative values so that the user/dial coordinate -systems can be configured to the opposite polarity of the motor controller's.

ERES R/W* Encoder Step Size (EGU) FLOAT Encoder resolution: the distance or angle, in engineering units, associated -with a single encoder step. ERES may be positive or negative; it must have -the same sign as MRES; and it must be nonzero.  If the user sets ERES -to zero, the record will overwrite it with MRES. 
RRES R/W Readback Step Size (EGU) FLOAT Readback-device resolution: the distance or angle, in engineering units, -associated with a unit change of the number retrieved via the readback- +* SBAK; VMAX = UREV * SMAX; VBAS = UREV * SBAS.  Motor speeds that are +expressed in revolutions per second (S, SBAK, and SBAS) are independent of +changes to MRES or UREV.  In contrast, when SREV is changed, only MRES +is adjusted by the motor record, thus allowing all other fields to remain +unaffected.

+ +

Currently, changes to motor-resolution fields have no effect on the +values of limit fields (although they should). 

+ +

MRES or UREV allow negative values so that the user/dial coordinate + systems can be configured to the opposite polarity of the motor controller's.

+

+
+
+
+
+
ERES R/W* Encoder Step Size (EGU) FLOAT Encoder resolution: the distance or angle, in engineering units, associated + with a single encoder step. ERES may be positive or negative; it must have + the same sign as MRES; and it must be nonzero.  If the user sets ERES + to zero, the record will overwrite it with MRES. 
RRES R/W Readback Step Size (EGU) FLOAT Readback-device resolution: the distance or angle, in engineering +units, associated with a unit change of the number retrieved via the readback- location input link (RDBL). RRES may be either positive or negative. 
RES R Step Size (EGU) FLOAT The motor or encoder resolution, in engineering units, as selected -by the presence of an encoder supported by the hardware and by the switch -UEIP ("Use Encoder If Present"). If an encoder is present, and UEIP=1, -then RES will be set equal to ERES, otherwise RES will be set equal to -MRES. 
UEIP R/W* Use Encoder If Present RECCHOICE (0:"No", 1:"Yes") Switch: nonzero value tells the record to read the encoder (if the -hardware indicates an encoder is present) and to ignore the value read -back from the hardware's step-count register.  -

The state of the UEIP, together with the MSTA encoder indicator, determine: -

    -
  1. -if the RRBV is set to either the feedback (REP) or the command (RMP) position.
    2. - -
  2. -if the RES is set to either the feedback (ERES) or the command (MRES) resolution.
    3. - -
  3. -whether absolute or relative position commands are used.
    4. -
-
URIP R/W* Use RDBL Link If Present RECCHOICE (0:"No", 1:"Yes") Switch: nonzero value tells the record to get the motor position from -the readback-location link (RDBL) (if it contains valid EPICS link information, -and if no error occurs in the attempt to read from the link) and to ignore -values read back from the hardware's step-count and encoder registers.
These switches also direct the record to calculate destinations -in relative, rather than absolute, terms, since the ratio of encoder and +

+
+
+
+
+
UEIP R/W* Use Encoder If Present RECCHOICE (0:"No", 1:"Yes") Switch: nonzero value tells the record to read the encoder (if the +hardware indicates an encoder is present) and to ignore the value read back +from the hardware's step-count register.  +

The state of the UEIP, together with the MSTA encoder indicator, +determine:

+ +
    +
  1. if the RRBV is set to either the feedback (REP) or the command (RMP) +position.
    2. +
  2. whether absolute or relative position commands are used.
    3. + +
+
URIP R/W* Use RDBL Link If Present RECCHOICE (0:"No", 1:"Yes") Switch: nonzero value tells the record to get the motor position from + the readback-location link (RDBL) (if it contains valid EPICS link information, + and if no error occurs in the attempt to read from the link) and to ignore + values read back from the hardware's step-count and encoder registers.
These switches also direct the record to calculate destinations + in relative, rather than absolute, terms, since the ratio of encoder and readback units to motor steps may not actually be constant.
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

-Motion-related fields

-
Name Access Prompt Data type Comments 
VMAXR/WMax Velocity (EGU/s)FLOATValid range; 0 <= VMAX.  VMAX=0 disables maximum velocity range -checking.
SMAXR/WMax Velocity (RPS)FLOATValid range; 0 <= SMAX
VBASR/WBase Velocity (EGU/s) FLOATValid range; 0 <= VBAS
SBASR/WBase Speed (RPS) FLOATValid range; 0 <= SBAS
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.  A VMAX value of zero -disables maximum velocity range checking. -

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. -

Slew (VELO/S) and backup (BVEL/SBAK) velocity fields are silently forced -by the motor record to be within the range set by VMAX/SMAX and VBAS/SBAS, -inclusively. -

Those who use both BURT and VMAX (i.e., nonzero VMAX) should insure -that VMAX and VBAS are placed before VELO and BVEL in their BURT request -files. -

The intent of VBAS/SBAS is to prevent the motor from moving at speeds -slow enough to excite its resonance, which can cause the motor to miss -steps. The motor is expected to accelerate from a stand-still to VBAS in -one motor pulse. 

VELO R/W Velocity (EGU/s) FLOATValid range; VBAS <= VELO <= VMAX
S R/WSpeed (RPS) FLOAT Valid range;  SBAS <=      S      -<= SMAX
VELO is the speed, in engineering units per second, at + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +motion is finished. SBAK is the same speed expressed in revolutions per second. +Neither BVEL nor SBAK may be negative or zero.  + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +

Motion-related fields

+
Name Access Prompt Data type Comments 
VMAXR/WMax Velocity (EGU/s)FLOATValid range; 0 <= VMAX.  VMAX=0 disables maximum velocity +range checking.
SMAXR/WMax Velocity (RPS)FLOATValid range; 0 <= SMAX
VBASR/WBase Velocity (EGU/s) FLOATValid range; 0 <= VBAS
SBASR/WBase Speed (RPS) FLOATValid range; 0 <= SBAS
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.  A VMAX value of zero disables +maximum velocity range checking. +

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. +

+ +

Slew (VELO/S) and backup (BVEL/SBAK) velocity fields are silently +forced by the motor record to be within the range set by VMAX/SMAX and VBAS/SBAS, + inclusively.

+ +

Those who use both BURT and VMAX (i.e., nonzero VMAX) should insure + that VMAX and VBAS are placed before VELO and BVEL in their BURT request +files.

+ +

The intent of VBAS/SBAS is to prevent the motor from moving at speeds + slow enough to excite its resonance, which can cause the motor to miss steps. +The motor is expected to accelerate from a stand-still to VBAS in one motor +pulse. 

+
VELO R/W Velocity (EGU/s) FLOATValid range; VBAS <= VELO <= VMAX
S R/WSpeed (RPS) FLOAT Valid range;  SBAS <=      S      + <= SMAX
VELO is the speed, in engineering units per second, at which the motor is move after the acceleration phase of a motion is finished. S is the same speed expressed in revolutions per second. The record makes sure that VELO and S are consistent, using the equation S = VELO/UREV.
ACCL R/W Seconds to Velocity FLOAT The length, in seconds, of the acceleration and deceleration phases -of a motor motion. 
The motor record expects the hardware to produce a trapezoidal -speed profile. That is, the motor speed is expected to increase linearly +
ACCL R/W Seconds to Velocity FLOAT The length, in seconds, of the acceleration and deceleration phases + of a motor motion. 
The motor record expects the hardware to produce a trapezoidal + speed profile. That is, the motor speed is expected to increase linearly with time from the base speed, VBAS, to the full speed, VELO, in ACCL seconds. -At the end of a motion, the speed is expected to decrease similarly to -VBAS. 
JVELR/WJog Velocity (EGU/s)FLOATValid range; VBAS <= VELO <= VMAX
JARR/WJog  Acceleraton (EGU/s^2)FLOATDefault value: VELO / ACCL
With the OMS and IMS device drivers, jog velocity -can be changed on-the-fly.  The velocity will accelerate to the new + At the end of a motion, the speed is expected to decrease similarly to VBAS. 
JVELR/WJog Velocity (EGU/s)FLOATValid range; VBAS <= VELO <= VMAX
JARR/WJog  Acceleraton (EGU/s^2)FLOATDefault value: VELO / ACCL
With the OMS and IMS device drivers, jog velocity + can be changed on-the-fly.  The velocity will accelerate to the new velocity based on the JAR field.
BDST R/W BL Distance (EGU) FLOATThe signed distance, in dial coordinates, used for backlash takeout. 
The algorithm used in moves to a (dial-coordinate) position -called "TARGET" follows:  -

1) If the motor is to move a distance greater than the magnitude of -BDST, or if the motor is to move in a direction opposite to the sign of -BDST, then the motor will move first to position (TARGET-BDST), at an acceleration -specified by ACCL and speed VELO, and then to position TARGET, at an acceleration -specified by BACC and speed BVEL.  -

2) If the motor is to move a distance smaller than the magnitude of -BDST, and if the motor is to move in the same direction as the sign of -BDST, then backlash is assumed already to have been taken out, and the -motor will move to position TARGET at an acceleration specified by BACC -and speed BVEL. 

BVEL R/WBL Velocity (EGU/s) FLOAT
SBAK R/W BL Speed (RPS) FLOAT 
BVEL is the speed, in engineering units per second, at +
BDST R/W BL Distance (EGU) FLOATThe signed distance, in dial coordinates, used for backlash takeout. 
The algorithm used in moves to a (dial-coordinate) position + called "TARGET" follows:  +

1) If the motor is to move a distance greater than the magnitude +of BDST, or if the motor is to move in a direction opposite to the sign of + BDST, then the motor will move first to position (TARGET-BDST), at an acceleration + specified by ACCL and speed VELO, and then to position TARGET, at an acceleration + specified by BACC and speed BVEL. 

+ +

2) If the motor is to move a distance smaller than the magnitude +of BDST, and if the motor is to move in the same direction as the sign of + BDST, then backlash is assumed already to have been taken out, and the motor +will move to position TARGET at an acceleration specified by BACC and speed +BVEL. 

+

+
+
+
+
+
BVEL R/WBL Velocity (EGU/s) FLOAT
SBAK R/W BL Speed (RPS) FLOAT 
BVEL is the speed, in engineering units per second, at which the motor is move after the acceleration phase of a backlash-takeout -motion is finished. SBAK is the same speed expressed in revolutions per -second. Neither BVEL nor SBAK may be negative or zero. 
BACC R/W BL Seconds to Veloc. FLOAT The length, in seconds, of the acceleration and deceleration phases -of a backlash-takeout motion. See discussion of the acceleration field -ACCL for more specific information. 
FRACR/W Move Fraction FLOAT 
This field supports closed-loop control of pathological -devices for which drive values are not expected to compare reproducibly -with readback values. (Inchworms and other friction-driven devices are -good examples: the number of steps taken by an inchworm motor is a very -poor indicator of the distance it has traveled.)  -

In a move from position CURRENT to position TARGET, the motor record -will ask hardware to move a distance FRAC*(TARGET-CURRENT). When that motion -is complete, the record will request a motion of FRAC*(remaining distance), -and so on until the target position has been reached. 

RDBD R/W Retry Deadband (EGU) FLOAT When the motor has finished a complete motion, possibly including backlash -takeout, the motor record will compare its current position with the desired -position. If the magnitude of the difference is greater than RDBD, the -motor will try again, as if the user had requested a move from the now -current position to the desired position. Only a limited number of retries -will be performed (see RTRY). 
RTRY R/W Max retry count SHORT The maximum number of times the motor record will try again to move -to the desired position. When the retry limit is reached, the motor record -will declare the motion finished. If the desired position was not reached, -the field MISS will be set to 1.

+
+
+
+
+
BACC R/W BL Seconds to Veloc. FLOAT The length, in seconds, of the acceleration and deceleration phases + of a backlash-takeout motion. See discussion of the acceleration field ACCL +for more specific information. 

+
+
+
+
+
FRACR/W Move Fraction FLOAT 
This field supports closed-loop control of pathological +devices for which drive values are not expected to compare reproducibly with +readback values. (Inchworms and other friction-driven devices are good examples: +the number of steps taken by an inchworm motor is a very poor indicator of +the distance it has traveled.)  +

In a move from position CURRENT to position TARGET, the motor record + will ask hardware to move a distance FRAC*(TARGET-CURRENT). When that motion + is complete, the record will request a motion of FRAC*(remaining distance), + and so on until the target position has been reached. 

+

+
+
+
+
+
RDBD R/W Retry Deadband (EGU) FLOAT When the motor has finished a complete motion, possibly including +backlash takeout, the motor record will compare its current position with +the desired position. If the magnitude of the difference is greater than +RDBD, the motor will try again, as if the user had requested a move from +the now current position to the desired position. Only a limited number of +retries will be performed (see RTRY). 
RTRY R/W Max retry count SHORT The maximum number of times the motor record will try again to move + to the desired position. When the retry limit is reached, the motor record + will declare the motion finished. If the desired position was not reached, + the field MISS will be set to 1.
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

-Link-related fields

-
Name Access Prompt Data type Comments 
OUT R/W Output Specification OUTLINK If Soft Channel device support is specified, this field is an EPICS -link; each time DVAL is changed, device support puts DVAL to this link.  -Otherwise, this field specifies the hardware to be controlled.
RDBL R Readback Location INLINK This field specifies the field (of this or any other EPICS record) + +
+ + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +

Link-related fields

+
Name Access Prompt Data type Comments 
OUT R/W Output Specification OUTLINK If Soft Channel device support is specified, this field is an EPICS + link; each time DVAL is changed, device support puts DVAL to this link.  + Otherwise, this field specifies the hardware to be controlled.
RDBL R Readback Location INLINK This field specifies the field (of this or any other EPICS record) from which the motor's current position is to be read when the field URIP (Use Readback If Present) has the value "Yes" (1). If this field does not contain a valid EPICS link, the URIP may as well have the value "No" (0).  If Soft Channel device support is specified, this field is monitored for value changes by a CA event task. 
DOL R Desired Output Loc INLINK If this field contains a valid EPICS link, and the OMSL field has the -value "closed_loop" (1), then every time the the motor record is processed, -it will get a value for the VAL field from the link and move to that location, -ignoring all other drive fields. Closed-loop mode has not been tested extensively. 
OMSL R/W Output Mode Select GBLCHOICE (0:"supervisory", 1:"closed_loop")  -
If this field has the value "closed_loop" (1), and the field DOL contains -a valid EPICS link, then every time the the motor record is processed, -it will get a value for the VAL field from the link and move to that location, -ignoring all other drive fields. Closed-loop mode has not been tested extensively. 
RLNK R Readback OutLink OUTLINK If this field contains a valid EPICS link, then every time the motor -record is processed, it will put the (engineering-unit) readback value -RBV to that link. 
DINPR/WDMOV Input LinkINLINKIf Soft Channel device support is specified, the value specified by -this link is used to set the DONE bit in the MSTA field; which in turn -sets the DMOV field.
RINPR/WRMP Input LinkINLINKIf Soft Channel device support is specified, the value specified by -this link is used to set the RMP field.
STOOR/WSTOP OutLinkOUTLINKIf Soft Channel device support is specified, a one is written to the  -specified link each time the STOP_AXIS motor command is issued.
-

-Soft Channel Device Driver

-The Soft Channel database links (i.e., DINP, RINP and STOO) are only processed -when the Soft Channel device driver is selected.  These links are -ignored when using any other Motor Record device driver. -
The input links (i.e., DINP, RDBL and RINP) are monitored for value -changes by a CA event task.  Users must choose either a dial input -link (RDBL) or a raw input link (RINP), but not both. At this time, the -above links are not dynamically retargetable.  -
Note that JOG[F/R] does not work with the Soft Channel device driver.
DOL R Desired Output Loc INLINK If this field contains a valid EPICS link, and the OMSL field has +the value "closed_loop" (1), then every time the the motor record is processed, + it will get a value for the VAL field from the link and move to that location, + ignoring all other drive fields. Closed-loop mode has not been tested extensively. 
OMSL R/W Output Mode Select GBLCHOICE (0:"supervisory", 1:"closed_loop") 
+ If this field has the value "closed_loop" (1), and the field DOL contains + a valid EPICS link, then every time the the motor record is processed, it +will get a value for the VAL field from the link and move to that location, + ignoring all other drive fields. Closed-loop mode has not been tested extensively. 
RLNK R Readback OutLink OUTLINK If this field contains a valid EPICS link, then every time the motor + record is processed, it will put the (engineering-unit) readback value RBV +to that link. 
DINPR/WDMOV Input LinkINLINKIf Soft Channel device support is specified, the value specified by + this link is used to set the DONE bit in the MSTA field; which in turn sets +the DMOV field.
RINPR/WRMP Input LinkINLINKIf Soft Channel device support is specified, the value specified by + this link is used to set the RMP field.
STOOR/WSTOP OutLinkOUTLINKIf Soft Channel device support is specified, a one is written to the  + specified link each time the STOP_AXIS motor command is issued.
+

Soft Channel Device Driver

+ The Soft Channel database links (i.e., DINP, RINP and STOO) are only processed + when the Soft Channel device driver is selected.  These links are ignored +when using any other Motor Record device driver.
+ The input links (i.e., DINP, RDBL and RINP) are monitored for value changes +by a CA event task.  Users must choose either a dial input link (RDBL) +or a raw input link (RINP), but not both. At this time, the above links are + not dynamically retargetable. 
+ Note that JOG[F/R] does not work with the Soft Channel device driver.
- -
- - - - - - - - - - - - - - - - - - - - - - - - -
-

-Limit-related fields

-
Name AccessPrompt Data type Comments
HLM R/W* User High LimitFLOAT The maximum allowed value of the VAL field. If HLM changes so that -VAL is no longer less than HLM, then the record will set the field LVIO -to 1. If the DIR field has the value "Pos", then HLM will always be consistent + +
+ + + + + + + + + + + + + + + - - - - - - - - - - - - + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - + + + + + + + + + +
+ +

Limit-related fields

+
Name AccessPrompt Data type Comments
HLM R/W* User High LimitFLOAT The maximum allowed value of the VAL field. If HLM changes so that +VAL is no longer less than HLM, then the record will set the field LVIO to +1. If the DIR field has the value "Pos", then HLM will always be consistent with DHLM, otherwise HLM will always be consistent with DLLM.
LLM R/W* User Low Limit FLOAT The minimum allowed value of the VAL field. If LLM changes so that +
LLM R/W* User Low Limit FLOAT The minimum allowed value of the VAL field. If LLM changes so that VAL is no longer greater than LLM, then the record will set the field LVIO to 1. If the DIR field has the value "Pos", then LLM will always be consistent -with DLLM, otherwise LLM will always be consistent with DHLM. 
DHLM R/W* Dial High Limit FLOAT The maximum allowed value of the DVAL field. If DHLM changes so that -DVAL is no longer less than DHLM, then the record will set the field LVIO -to 1.. If the DIR field has the value "Pos", then DHLM will always be consistent -with HLM, otherwise DHLM will always be consistent with LLM. 
DLLM R/W* Dial Low Limit FLOAT The minimum allowed value of the DVAL field. If DLLM changes so that -DVAL is no longer greater than DLLM, then the record will set the field -LVIO to 1. If the DIR field has the value "Pos", then DLLM will always -be consistent with LLM, otherwise DLLM will always be consistent with HLM. 
LVIO R Limit violation SHORT A value of 1 indicates that the dial-value drive field, DVAL, or the -dial-value readback field, DRBV, is outside of the limits (DHLM, DLLM), + with DLLM, otherwise LLM will always be consistent with DHLM. 
DHLM R/W* Dial High Limit FLOAT The maximum allowed value of the DVAL field. If DHLM changes so that + DVAL is no longer less than DHLM, then the record will set the field LVIO + to 1.. If the DIR field has the value "Pos", then DHLM will always be consistent + with HLM, otherwise DHLM will always be consistent with LLM. 
DLLM R/W* Dial Low Limit FLOAT The minimum allowed value of the DVAL field. If DLLM changes so that + DVAL is no longer greater than DLLM, then the record will set the field +LVIO to 1. If the DIR field has the value "Pos", then DLLM will always be +consistent with LLM, otherwise DLLM will always be consistent with HLM. 
LVIO R Limit violation SHORT A value of 1 indicates that the dial-value drive field, DVAL, or the + dial-value readback field, DRBV, is outside of the limits (DHLM, DLLM), and this prevents the motor from moving. If the backlash distance, BDST, is non-zero, it further restricts the allowable range of DVAL. When a JOG -button is hit, LVIO goes to 1 and stops the motor if/when DVAL gets to -within one second's travel time of either limit. 
PERL R/W Periodic Limits RECCHOICE (0:"No", 1:"Yes")  -
Not implemented. Originally intended to support periodic "limits" on -the VAL field (such as those associated with a rotation stage--e.g., [0...360] -or [-180...180]) independently of the actual soft limits HLM and LLM. 
HOPR R/W High Operating Range FLOAT Not used. See HLM and DHLM. 
LOPR R/W Low Operating Range FLOAT Not used. See LLM and DLLM. 
HLS R At High Limit Switch SHORT
RHLS R Raw High Limit SwitchSHORT 
If either of these fields is nonzero, then the motor is +button is hit, LVIO goes to 1 and stops the motor if/when DVAL gets to within +one second's travel time of either limit. 
PERL R/W Periodic Limits RECCHOICE (0:"No", 1:"Yes") 
+ Not implemented. Originally intended to support periodic "limits" on the +VAL field (such as those associated with a rotation stage--e.g., [0...360] + or [-180...180]) independently of the actual soft limits HLM and LLM. 
HOPR R/W High Operating Range FLOAT Not used. See HLM and DHLM. 
LOPR R/W Low Operating Range FLOAT Not used. See LLM and DLLM. 

+
+
+
+
+
HLS R At High Limit Switch SHORT
RHLS R Raw High Limit SwitchSHORT 
If either of these fields is nonzero, then the motor is at the positive-limit switch, where the positive sense is that of the user-coordinate -system for HLS, and that of the raw (step-number) coordinate system for + system for HLS, and that of the raw (step-number) coordinate system for RHLS. 
LLS RAt Low Limit SwitchSHORT
RLLS R Raw Low Limit SwitchSHORT 
If either of these fields is nonzero, then the motor is +

+
+
+
+
+

+
+
+
+
+
LLS RAt Low Limit SwitchSHORT
RLLS R Raw Low Limit SwitchSHORT 
If either of these fields is nonzero, then the motor is at the negative-limit switch, where the positive sense is that of the user-coordinate -system for LLS, and that of the raw (step-number) coordinate system for + system for LLS, and that of the raw (step-number) coordinate system for RLLS.

+
+
+
+
+
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

-Command-button fields

-
Name Access PromptData type Comments 
SPMG R/W* Stop/Pause/Move/Go RECCHOICE (0:"Stop", 1:"Pause", 2:"Move", 3:"Go") 
This field is intended primarily for interactive use, and -normally has the value "Go."  -

If the user sets this field to "Stop," the motor will decelerate to -a stop, the VAL field will be set equal to the RBV field, and the DVAL -field will be set equal to the DRBV field. (These actions ensure that the -motor will not start moving again until a drive field is changed.) In any -case, the motor will not move while SPMG has the value "Stop" or "Pause."  -

If "SPMG" has the value "Move," the motor record will reset SPMG to -"Pause" when a motion completes. This behavior supports users who want -a motor to sit still until they say "Move", no matter what changes occur -in the drive fields. 

STOP R/W* Stop SHORT 
When this field is set to 1, the record will immediately -reset it to 0, and the motor will decelerate to a stop. When the motor -has stopped, VAL will be set equal to RBV, and DVAL will be set equal to -DRBV. (This ensures that the motor will not start moving the next time -the record is processed, unless a drive field is explicitly changed. If -you want the motor to pause, use the SPMG field.) 
HOMF R/W* Home Forward SHORT
HOMR R/W* Home Reverse SHORT 
When one of these fields is set to 1, the motor will decelerate -to a stop if already moving, move in the indicated direction (in dial -coordinates) at the acceleration specified by ACCL and a speed of 1000 + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - + + + + + + + + + +
+ +

Command-button fields

+
Name Access PromptData type Comments 
SPMG R/W* Stop/Pause/Move/Go RECCHOICE (0:"Stop", 1:"Pause", 2:"Move", 3:"Go") 
This field is intended primarily for interactive use, and + normally has the value "Go."  +

If the user sets this field to "Stop," the motor will decelerate +to a stop, the VAL field will be set equal to the RBV field, and the DVAL + field will be set equal to the DRBV field. (These actions ensure that the + motor will not start moving again until a drive field is changed.) In any + case, the motor will not move while SPMG has the value "Stop" or "Pause."  +

+ +

If "SPMG" has the value "Move," the motor record will reset SPMG +to "Pause" when a motion completes. This behavior supports users who want + a motor to sit still until they say "Move", no matter what changes occur +in the drive fields. 

+

+
+
+
+
+
STOP R/W* Stop SHORT 
When this field is set to 1, the record will immediately + reset it to 0, and the motor will decelerate to a stop. When the motor has +stopped, VAL will be set equal to RBV, and DVAL will be set equal to DRBV. +(This ensures that the motor will not start moving the next time the record +is processed, unless a drive field is explicitly changed. If you want the +motor to pause, use the SPMG field.) 

+
+
+
+
+
HOMF R/W* Home Forward SHORT
HOMR R/W* Home Reverse SHORT 
When one of these fields is set to 1, the motor will decelerate + to a stop if already moving, move in the indicated direction (in dial + coordinates) at the acceleration specified by ACCL and a speed of 1000 motor pulses per second, until the hardware detects the "home" switch has become active. Then the hardware will do something hardware dependent in response to its "home" command, if any. (The OMS hardware causes the motor to decelerate to a stop.) When the motor stops, the VAL field will be set equal to the RBV field, and the DVAL field will be set equal to the DRBV -field.  These fields can be set to 1, but setting either field to -0 results in an error.  The record sets HOM[F/R] to zero when the -homing procedure is either completed or aborted.
JOGF R/W* Jog motor Forward SHORT
JOGR R/W* Jog motor Reverse SHORT 
When one of these fields is set to 1, the motor will decelerate -to a stop if already moving, and move in the indicated direction (in user -coordinates) at an acceleration specified by ACCL and speed VELO, until +field.  These fields can be set to 1, but setting either field to 0 +results in an error.  The record sets HOM[F/R] to zero when the homing +procedure is either completed or aborted.

+
+
+
+
+
JOGF R/W* Jog motor Forward SHORT
JOGR R/W* Jog motor Reverse SHORT 
When one of these fields is set to 1, the motor will decelerate + to a stop if already moving, and move in the indicated direction (in user + coordinates) at an acceleration specified by ACCL and speed VELO, until the field goes to 0. Then the motor will set VAL to RBV and DVAL to DRBV, decelerate to a stop, and execute a (backlash-corrected, if BDST is nonzero) -move to the position at which the field went to 0.  -

These fields are dangerous when used over channel access, because the -motor does not stop moving until a second message is received. If a very -busy network should cause that second message to be lost, the motor will -travel to its limit switch or hard stop. 

TWF R/W* Tweak motor Forward SHORT
TWR R/W* Tweak motor Reverse SHORT 
When one of these fields is set to 1, the record will immediately -reset it to 0, and the motor will move (with backlash takeout if BDST is +move to the position at which the field went to 0.  +

These fields are dangerous when used over channel access, because +the motor does not stop moving until a second message is received. If a very + busy network should cause that second message to be lost, the motor will +travel to its limit switch or hard stop. 

+

+
+
+
+
+
TWF R/W* Tweak motor Forward SHORT
TWR R/W* Tweak motor Reverse SHORT 
When one of these fields is set to 1, the record will immediately + reset it to 0, and the motor will move (with backlash takeout if BDST is nonzero) by a distance TWV (in user coordinates) at the acceleration specified by ACCL and at speed VELO.
TWV R/W* Tweak Step Size (EGU) FLOAT This field contains the distance the motor is to move in response to -the TWF and TWR buttons. 
TWV R/W* Tweak Step Size (EGU) FLOAT This field contains the distance the motor is to move in response +to the TWF and TWR buttons. 
- -
- - - - - - - - - - - - - - - - - - - - - - - - -
-

-Drive fields

-
Name Access Prompt Data type Comments
VAL R/W*User Desired Value DOUBLEThis is the desired position in user coordinates. When this field is -written to, DVAL and RVAL will be changed correspondingly, and the motor + +
+ + + + + + + + + + + + + + + - - - - - - - - - - - - + + + + + + - - - - - - - - - - - - + + + + + + - - - - - - - - - - - - + + + + + + - + + +
+ +

Drive fields

+
Name Access Prompt Data type Comments
VAL R/W*User Desired Value DOUBLEThis is the desired position in user coordinates. When this field +is written to, DVAL and RVAL will be changed correspondingly, and the motor will move (with backlash takeout if BDST is nonzero) to the newly written position. 
DVAL R/W* Dial Desired Value DOUBLE This is the desired position in dial coordinates. When this field is -written to, VAL and RVAL will be changed correspondingly, and the motor +
DVAL R/W* Dial Desired Value DOUBLE This is the desired position in dial coordinates. When this field +is written to, VAL and RVAL will be changed correspondingly, and the motor will move (with backlash takeout if BDST is nonzero) to the newly written position. 
RVAL R/W* Raw Desired Value DOUBLE This is the desired position in raw coordinates. When this field is -written to, VAL and DVAL will be changed correspondingly, and the motor +
RVAL R/W* Raw Desired Value DOUBLE This is the desired position in raw coordinates. When this field is + written to, VAL and DVAL will be changed correspondingly, and the motor will move (with backlash takeout if BDST is nonzero) to the newly written position. 
RLV R/W* Relative Value DOUBLE When this field is changed, its value will be added to VAL, the field -itself will immediately be reset to 0, and the motor record will behave +
RLV R/W* Relative Value DOUBLEWhen this field is changed, its value will be added to VAL, the field + itself will immediately be reset to 0, and the motor record will behave as though the VAL field had been changed directly. 
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + +
-

-Status/readback fields

-
Name Access Prompt Data type Comments 
RBV R User Readback Value DOUBLEThe current motor position, in user coordinates, from the motor hardware -(default), or from the encoder supported by the motor-controller hardware -(if UEIP is nonzero), or from the readback link RDBL (if URIP is nonzero). 
DRBV R Dial Readback Value DOUBLE The current motor position, in dial coordinates, from the motor hardware -(default), or from the encoder supported by the motor-controller hardware -(if UEIP is nonzero), or from the readback link RDBL (if URIP is nonzero). 
DMOV RDone moving to value SHORT 
This field is set to 0 when the motor record begins a motion, -and remains 0 through any retries and backlash corrections that may be -required until the motor record has completely finished that motion, whereupon -the field is set to 1. DMOV is guaranteed to execute and post a 1/0/1 pulse -when the motor is commanded to move--even if no motion actually occurs -because the motor was commanded to move to its current position. 
MOVN R Motor is moving SHORT This field is set to 1 while the record believes that the motor actually -is moving. This field is not the inverse of DMOV, since it may go to zero -during a complex motion, if that motion includes a momentary stop. 
DLYR/WReadback settle time (s)FLOATDelay (in seconds) the time between motor controller done and motor -record done (i.e., DMOV).
DIFF R Difference dval-drbv DOUBLE DIFF is the difference, in engineering units, between the -desired motor position, and the readback device's report of the current + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + - - - - - - - - - - - - - -
+ +

Status/readback fields

+
Name Access Prompt Data type Comments 
RBV R User Readback Value DOUBLEThe current motor position, in user coordinates, from the motor hardware + (default), or from the encoder supported by the motor-controller hardware + (if UEIP is nonzero), or from the readback link RDBL (if URIP is nonzero). 
DRBV R Dial Readback Value DOUBLE The current motor position, in dial coordinates, from the motor hardware + (default), or from the encoder supported by the motor-controller hardware + (if UEIP is nonzero), or from the readback link RDBL (if URIP is nonzero). 
DMOV RDone moving to value SHORT 
This field is set to 0 when the motor record begins a motion, + and remains 0 through any retries and backlash corrections that may be required +until the motor record has completely finished that motion, whereupon the +field is set to 1. DMOV is guaranteed to execute and post a 1/0/1 pulse when +the motor is commanded to move--even if no motion actually occurs because +the motor was commanded to move to its current position. 
MOVN R Motor is moving SHORT This field is set to 1 while the record believes that the motor actually + is moving. This field is not the inverse of DMOV, since it may go to zero + during a complex motion, if that motion includes a momentary stop. 
DLYR/WReadback settle time (s)FLOATDelay (in seconds) the time between motor controller done and motor + record done (i.e., DMOV).
DIFF R Difference dval-drbv DOUBLE DIFF is the difference, in engineering units, between +the desired motor position, and the readback device's report of the current position. RDIF is the same difference in "raw" units (normally, steps). 
RDIF R Difference rval-rrbv LONG 
RRBV R Raw Readback Value DOUBLE The current position of the motor, encoder, or readback link, as received -from whatever source has been selected to provide position information. +
RDIF R Difference rval-rrbv LONG 
RRBV R Raw Readback Value DOUBLE The current position of the motor, encoder, or readback link, as received + from whatever source has been selected to provide position information. The units associated with this field depend on the source. 
RMP R Raw Motor Position DOUBLE The contents of the hardware's step-count register. This field contains -the same information as the dial value, but in steps, rather than in engineering -units. 
REP R Raw Encoder Position DOUBLE The contents of the hardware's encoder-count register. Ideally, this -field contains the same information as the dial value, but in encoder counts, -rather than in engineering units. 
MSTA R Motor Status ULONG The motor status as received from the hardware.  The MSTA bits -are defined as follows: -
-
    -
  1. -DIRECTION: (0:Negative, 1:Positive)
    2. - -
  2. -DONE: motion is complete.
    3. - -
  3. -OVERTRAVEL: a limit switch has been hit.
    4. - -
  4. -HOMELS: state of the home limit switch.
    5. - -
  5. -Unused
    6. - -
  6. -POSITION: closed-loop position control is enabled.
    7. - -
  7. -Unused
    8. - -
  8. -HOME: if at home position.
    9. - -
  9. -PRESENT: encoder is present.
    10. - -
  10. -PROBLEM: driver stopped polling.
    11. - -
  11. -MOVING: non-zero velocity present.
    12. - -
  12. -GAIN_SUPPORT: motor supports closed-loop position control.
    13. -
-
-
TDIR R Direction of Travel SHORT The direction in which the motor is currently traveling (or was most -recently traveling), as received from the hardware. If 0, the raw readback -value should be decreasing. 
ATHM R At HOME SHORT The state of the hardware's "home" switch. If 1, the motor has hit +
RMP R Raw Motor Position DOUBLE The contents of the hardware's step-count register. This field contains + the same information as the dial value, but in steps, rather than in engineering + units. 
REP R Raw Encoder Position DOUBLE The contents of the hardware's encoder-count register. Ideally, this + field contains the same information as the dial value, but in encoder counts, + rather than in engineering units. 
MSTA R Motor Status ULONG The motor status as received from the hardware.  The MSTA bits + are defined as follows: +
+
    +
  1. DIRECTION: (0:Negative, 1:Positive)
    2. +
  2. DONE: motion is complete.
    3. +
  3. PLUS_LS: plus limit switch has been hit.
    4. +
  4. HOMELS: state of the home limit switch.
    5. +
  5. Unused
    6. +
  6. POSITION: closed-loop position control is enabled.
    7. +
  7. Unused
    8. +
  8. HOME: if at home position.
    9. +
  9. PRESENT: encoder is present.
    10. +
  10. PROBLEM: driver stopped polling.
    11. +
  11. MOVING: non-zero velocity present.
    12. +
  12. GAIN_SUPPORT: motor supports closed-loop position control.
    13. +
  13. COMM_ERR: Controller communication error.
    14. +
  14. MINUS_LS: minus limit switch has been hit.
    +
    15. + +
+
+
TDIR R Direction of Travel SHORT The direction in which the motor is currently traveling (or was most + recently traveling), as received from the hardware. If 0, the raw readback + value should be decreasing. 
ATHM R At HOME SHORT The state of the hardware's "home" switch. If 1, the motor has hit the switch. 
RCNT R Retry count SHORT The number of times the motor record has detected failure of the motor -to land within the retry-deadband distance of the desired position. 
MISS R Ran out of retries SHORT If 1, the motor has failed to land on the desired position more than -the allowed number of times. This field will be reset the next time the +
RCNT R Retry count SHORT The number of times the motor record has detected failure of the motor + to land within the retry-deadband distance of the desired position. 
MISS R Ran out of retries SHORT If 1, the motor has failed to land on the desired position more than + the allowed number of times. This field will be reset the next time the motor succeeds in reaching the desired position. 
RVEL R Raw Velocity LONG Speed in steps per second that the motor actually is moving. 
- -
-
- -
-

-Servo fields

- - - - - - + + + + + + + + + +
 
PID related record fields accept only normalized -values (i.e., 0.0 <= value <= 1.0).  Before sending them to -the motor controller, device support scales the record fields to valid -motor controller parameters,.  Let the motor controller PID parameters -be represented by CKP, CKI and CKD; then the PID coefficients are converted -from motor record fields to controller parameters as follows: -

For the MM4000;  CKP = PCOF, CKI = ICOF and CKD = DCOF. -
For all OMS controllers;  CKP = 1999.9 * PCOF, CKI = 1999.9 * -ICOF, CKD = 1999.9 * DCOF. -

Note the following: -

    -
  • -When commanded to move the OMS control law is a PD loop, when it is holding -a position it is a PID loop.
    • - -
  • -The Proportional Gain cannot be turned off (i.e., set to zero) in an OMS -controller.  The minimum value is PCOF = 0.00005 (CKP = 0.1).  -If the user sets PCOF < 0.00005 for an OMS controller, device support +
RVEL R Raw Velocity LONG Speed in steps per second that the motor actually is moving. 
+ +
+
+
+ +
+

Servo fields

+
+ + + + + - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 
PID related record fields accept only normalized + values (i.e., 0.0 <= value <= 1.0).  Before sending them to the +motor controller, device support scales the record fields to valid motor controller +parameters,.  Let the motor controller PID parameters be represented +by CKP, CKI and CKD; then the PID coefficients are converted from motor record +fields to controller parameters as follows: +

For the MM4000;  CKP = PCOF, CKI = ICOF and CKD = DCOF.
+ For all OMS controllers;  CKP = 1999.9 * PCOF, CKI = 1999.9 * ICOF, +CKD = 1999.9 * DCOF.

+ +

Note the following:

+ +
    +
  • When commanded to move the OMS control law is a PD loop, when it is +holding a position it is a PID loop.
    • +
  • The Proportional Gain cannot be turned off (i.e., set to zero) in +an OMS controller.  The minimum value is PCOF = 0.00005 (CKP = 0.1).  + If the user sets PCOF < 0.00005 for an OMS controller, device support silently resets it to it's minimum value of 0.00005.
    • -
-
-
Name
-		 -
Access
-		 -
Prompt
-		 -
Data type
-		 -
Comments
-
CNENR/WEnable controlRECCHOICE (0:"Disable", 1:"Enable")  Enable/Disable closed-loop position -control.  This field is active only if the GAIN_SUPPORT bit in the + + +
+
Name
+ 		+
Access
+ 		+
Prompt
+ 		+
Data type
+ 		+
Comments
+
CNENR/WEnable controlRECCHOICE (0:"Disable", 1:"Enable")  Enable/Disable closed-loop position + control.  This field is active only if the GAIN_SUPPORT bit in the MSTA is true.  This field is set by both the user and device support.  -CNEN is set to Disable by device support when it detects a motion + CNEN is set to Disable by device support when it detects a motion controller error; e.g. maximum following error exceeded.
PCOFR/WProportional GainFLOATValid range; 0.0 <= PCOF <= 1.0
 ICOFR/WIntegral GainFLOATValid range; 0.0 <= ICOF <= 1.0
 DCOFR/WDerivative GainFLOATValid range; 0.0 <= DCOF <= 1.0
- -
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
- -
-

-Alarm fields

-
Name Access Prompt Data typeComments 
HIHI R/W* Hihi Alarm Limit FLOAT
LOLO R/W* Lolo Alarm Limit FLOAT
HIGH R/W* High Alarm Limit FLOAT
LOW R/W* Low Alarm Limit FLOAT
HHSV R/W* Hihi Severity GBLCHOICENot used.
LLSV R/W* Lolo Severity GBLCHOICENot used.
HSV R/W* High Severity GBLCHOICENot used.
LSV R/W* Low Severity GBLCHOICENot used.
HLSV R/W* HW Limit Switch Violation SeverityGBLCHOICE 
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + +
-

-Miscellaneous fields

-
Name Access Prompt Data type Comments 
PREC R/WDisplay Precision SHORT The number of digits to the right of the decimal that are to be displayed -by MEDM and other channel-access clients. 
EGU R/W Engineering Units STRINGString sent to channel-access clients who ask for engineering units. 
VERS R Code Version FLOAT Version number of the recMotor.c code. 
CARD R Card Number SHORT For VME based devices (i.e., OMS VME8/44, OMS VME58 and V544) this +
PCOFR/WProportional GainFLOATValid range; 0.0 <= PCOF <= 1.0
 ICOFR/WIntegral GainFLOATValid range; 0.0 <= ICOF <= 1.0
 DCOFR/WDerivative GainFLOATValid range; 0.0 <= DCOF <= 1.0
+
+   + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+
+ +
+

Alarm fields

+
+
Name Access Prompt Data typeComments 
HIHI R/W* Hihi Alarm Limit FLOAT
LOLO R/W* Lolo Alarm Limit FLOAT
HIGH R/W* High Alarm Limit FLOAT
LOW R/W* Low Alarm Limit FLOAT
HHSV R/W* Hihi Severity GBLCHOICENot used.
LLSV R/W* Lolo Severity GBLCHOICENot used.
HSV R/W* High Severity GBLCHOICENot used.
LSV R/W* Low Severity GBLCHOICENot used.
HLSV R/W* HW Limit Switch Violation SeverityGBLCHOICE 
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+ +

Miscellaneous fields

+
Name Access Prompt Data type Comments 
PREC R/WDisplay Precision SHORT The number of digits to the right of the decimal that are to be displayed + by MEDM and other channel-access clients. 
EGU R/W Engineering Units STRINGString sent to channel-access clients who ask for engineering units. 
VERS R Code Version FLOAT Version number of the recMotor.c code. 
CARD R Card Number SHORT For VME based devices (i.e., OMS VME8/44, OMS VME58 and V544) this is the VME card number, derived from the output link. Cards are numbered -from zero according to their VME addresses.  Oregon Micro Systems -series VME8 and VME44 cards occur in the same series, since they are handled -by the same driver.  Oregon Micro Systems VME58 cards are numbered -separately, as are Highland Technology V540 cards.  This field is -set to -1 for non-VME based device/drivers.
-

-Command Primitives

-The following three fields comprise the Command Primitives feature.  -The command primitive record fields are available to the user to send ASCII -command primitives to the motor control board at fixed, predefined, times.  -Each of the fields is defined as a character string.  Consult the -motor controller manual for command protocols.  No error checking -is done by the motor record or the device driver to insure that the command -strings are valid.  Each field is terminated by the device -driver according to the command protocol.  Command primitives that -result in a response from the motion control board are valid, but the response -is not processed.  This feature is currently only available with OMS -VME8/44/58 or Newport MM4000 device support. -

Device Directives -

    -
  • -Valid only in the INIT field.
    • - -
  • -Must be identified by the following;
    • - -
    -
  • -First character of INIT string must be a '@'.
    • - -
  • -One or more characters followed by a terminating '@'; i.e., device directives -must have nonzero length.
    • - -
  • -A valid device directive; currently, only "DPM_ON".
    • -
    - -
  • -INIT strings are stripped of valid device directives (including @'s) and -tested for nonzero length before being sent to the controller.  For +from zero according to their VME addresses.  Oregon Micro Systems series +VME8 and VME44 cards occur in the same series, since they are handled by the +same driver.  Oregon Micro Systems VME58 cards are numbered separately, +as are Highland Technology V540 cards.  This field is set to -1 for non-VME +based device/drivers.
+

Command Primitives

+ The following three fields comprise the Command Primitives feature.  + The command primitive record fields are available to the user to send ASCII + command primitives to the motor control board at fixed, predefined, times.  + Each of the fields is defined as a character string.  Consult the motor +controller manual for command protocols.  No error checking is done by +the motor record or the device driver to insure that the command strings are +valid.  Each field is terminated by the device driver according +to the command protocol.  Command primitives that result in a response +from the motion control board are valid, but the response is not processed.  +This feature is currently only available with OMS VME8/44/58 or Newport MM4000 +device support. +

Device Directives

+ +
    +
  • Valid only in the INIT field.
    • +
  • Must be identified by the following;
    • + +
  • First character of INIT string must be a '@'.
    • +
  • One or more characters followed by a terminating '@'; i.e., device +directives must have nonzero length.
    • +
  • A valid device directive; currently, only "DPM_ON".
    • +
    +
  • INIT strings are stripped of valid device directives (including @'s) +and tested for nonzero length before being sent to the controller.  For example, given the INIT string, "@DPM_ON@HE", the device directive @DPM_ON@ -is stripped out before HE is sent to the controller.
    • -
-Driver Power Monitoring -
    -
  • -This feature is only available with the OMS VME58 device support.
    • - -
  • -The 8 User I/O signals are assigned to the 8 possible VME58 axes as follows:
    • - -
      User I/O #0 <> X axis -
       "   "    1 <> Y  -" -
      ........................................ -
      "    "    7 <> S  -"
    - -
  • -Drive-power monitoring defaults to disabled at boot-up.  Request enabling -drive-power monitoring by entering the device directive "@DPM_ON@" command -into the motor record initialization field (i.e., INIT).  The INIT -field is processed at record initialization (i.e., bootup), hence if there -are no errors, drive-power monitoring will be enabled after the next bootup.
    • - -
  • -Whenever a request is made to enable drive-power status monitoring, an -error check is made (using the VME58 "RB" command) to verify that the User + is stripped out before HE is sent to the controller.
    • + +
+ Driver Power Monitoring +
    +
  • This feature is only available with the OMS VME58 device support.
    • +
  • The 8 User I/O signals are assigned to the 8 possible VME58 axes +as follows:
    • + +
      + User I/O #0 <> X axis +
      +  "   "    +1 <> Y  "
      + ........................................ +
      + "    "    +7 <> S  " +
    +
  • Drive-power monitoring defaults to disabled at boot-up.  Request +enabling drive-power monitoring by entering the device directive "@DPM_ON@" +command into the motor record initialization field (i.e., INIT).  The +INIT field is processed at record initialization (i.e., bootup), hence if +there are no errors, drive-power monitoring will be enabled after the next +bootup.
    • +
  • Whenever a request is made to enable drive-power status monitoring, +an error check is made (using the VME58 "RB" command) to verify that the User I/O has been configured as an input.  The following message will appear in the error log if a configuration error is detected; "Invalid VME58 configuration; RB = 0x####", where "####" is the VME58's response to the RB command.
    • - -
  • -When drive-power status monitoring is enabled and a power failure is detected, -the device driver will respond by activating the the RA_OVERTRAVEL bit -in the MSTA.  This results in either HLS or LLS being activated depending -on the DIR field. In addition, the following message will appear in the -error log; "Drive power failure at VME58 card#?? motor#??".
    • -
-
INITR/WStartup commandsSTRINGSent at record initialization.
PREMR/WPre-move commandsSTRINGSent before every command string that causes motion.
POSTR/WPost-move commandsSTRINGSent after a complete motion is finished or when an overtravel limit -switch is detected.
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

-Private fields

-
Name Access Prompt Data type Comments 
CBAKNoneCallback structureNOACCESS 
LVAL R Last User Des Val DOUBLE
LDVL R Last Dial Des Val DOUBLE
LRVL R Last Raw Des Val DOUBLE
LRLV R Last Rel Value DOUBLE
PDIFRPrevious RDIFLONG
PP R Post process command SHORT
MIP R Motion In Progress SHORT
MMAP R Monitor Mask ULONG
NMAP R Monitor Mask ULONG
LSPG R Last SPMG RECCHOICE (see SPMG)
- -
-

-

-Files, device support

-The following table briefly describes all of the files required to implement -and use the motor record. The reader is assumed to be familiar with the -EPICS -Application Source/Release Control document which describes how to -build an EPICS application tree into which these files are to be placed, -and how to run "makesdr" and "gnumake" to build the record support. These -files can all be obtained from the EPICS -Software Distribution (in the custom-software -section). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + +
SOURCE CODE -
files to be placed in &lttop>/&ltapp&gtApp/src/
motorRecord.dbdDatabase Definition file for motor record.
motorRecord.c Record support for the motor record
motor.h Header included by all .c files
motordevCom.cDevice support common to all motor Record device drivers.
motordevCom.hDevice support header file.
motordrvCom.cDriver support common to all motor Record device drivers.
motordrvCom.hDriver support header file.
motordrvComCode.hLocal variables common to all motor Record drivers.
NOTE: All of the above files are required for any and all motor Record -device drivers.
devOmsCom.cDevice support common to all Oregon Micro Systems device drivers.
devOmsCom.h Device support header file common to all Oregon Micro Systems device -drivers.
drvOmsCom.hDriver support header file common to all Oregon Micro Systems device -drivers.
NOTE: The above files are required for any and all Oregon Micro Systems -device drivers.
devOms.c Device support for Oregon Micro Systems VME8 and VME44 series boards
drvOms.cDriver for Oregon Micro Systems VME8 and VME44 series boards
drvOms.h Header included by devOms.c and drvOms.c
devOms58.c Device support for Oregon Micro Systems VME58 series boards
drvOms58.c Driver for Oregon Micro Systems VME58 series boards
drvOms58.h Header included by devOms58.c and drvOms58.c
devV544.c Device support for Highland Technology boards.
drvV544.cDriver for Highland Technology boards.
drvV544.h Header included by devV544.c and drvV544.c
drvMMCom.hCommon header included by all Newport Motion Master device drivers.
NOTE: The above files are required for any and all Newport Motion Master -device drivers.
devMM3000.cDevice support for Newport MM3000.
drvMM3000.cDriver for Newport MM3000.
devMM4000.cDevice support for Newport MM4000.
drvMM4000.cDriver for Newport MM4000.
devPM500.cDevice support for Newport PM500.
drvPM500.cDriver for Newport PM500.
devSoft.cSoft Channel device support.
devSoftAux.cSoft Channel device support (Note: CA and record access code cannot -both reside in the same file; each defines (redefines) the DBR's.  +
  • 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#??".
    • + + +
    INITR/WStartup commandsSTRINGSent at record initialization.
    PREMR/WPre-move commandsSTRINGSent before every command string that causes motion.
    POSTR/WPost-move commandsSTRINGSent after a complete motion is finished or when an overtravel limit + switch is detected.
    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + +

    Private fields

    +
    Name Access Prompt Data type Comments 
    CBAKNoneCallback structureNOACCESS 
    +
    LVAL R Last User Des Val DOUBLE
    LDVL R Last Dial Des Val DOUBLE
    LRVL R Last Raw Des Val DOUBLE
    LRLV R Last Rel Value DOUBLE
    CDIR
    +     		RCommand direction
    +     		SHORT
    +
    PP R Post process command SHORT
    MIP R Motion In Progress SHORT
    MMAP R Monitor Mask ULONG
    NMAP R Monitor Mask ULONG
    LSPG R Last SPMG RECCHOICE (see SPMG)
    + +
    +

    +

    + +

    Files, device support

    + The following table briefly describes all of the files required to implement + and use the motor record. The reader is assumed to be familiar with the + + EPICS Application Source/Release Control document + which describes how to build an EPICS application tree into which these +files are to be placed, and how to run "makesdr" and "gnumake" to build the +record support. These files can all be obtained from the + EPICS Software Distribution + (in the + custom-software section + ). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    SOURCE CODE
    + files to be placed in &lttop>/&ltapp&gtApp/src/
    motorRecord.dbdDatabase Definition file for motor record.
    motorRecord.c Record support for the motor record
    motor.h Header included by all .c files

    +
    +
    motordevCom.cDevice support common to all motor Record device drivers.
    motordevCom.hDevice support header file.
    motordrvCom.cDriver support common to all motor Record device drivers.
    motordrvCom.hDriver support header file.
    motordrvComCode.hLocal variables common to all motor Record drivers.

    +     		NOTE: All of the above files are required for any and all motor Record + device drivers.

    +
    +
    devOmsCom.cDevice support common to all Oregon Micro Systems device drivers.
    devOmsCom.h Device support header file common to all Oregon Micro Systems device + drivers.
    drvOmsCom.hDriver support header file common to all Oregon Micro Systems device + drivers.

    +     		NOTE: The above files are required for any and all Oregon Micro Systems + device drivers.

    +
    +
    devOms.c Device support for Oregon Micro Systems VME8 and VME44 series boards
    drvOms.cDriver for Oregon Micro Systems VME8 and VME44 series boards
    drvOms.h Header included by devOms.c and drvOms.c

    +
    +
    devOms58.c Device support for Oregon Micro Systems VME58 series boards
    drvOms58.c Driver for Oregon Micro Systems VME58 series boards
    drvOms58.h Header included by devOms58.c and drvOms58.c

    +
    +
    devV544.c Device support for Highland Technology boards.
    drvV544.cDriver for Highland Technology boards.
    drvV544.h Header included by devV544.c and drvV544.c

    +
    +
    drvMMCom.hCommon header included by all Newport Motion Master device drivers.

    +     		NOTE: The above files are required for any and all Newport Motion +Master device drivers.
    devMM3000.cDevice support for Newport MM3000.
    drvMM3000.cDriver for Newport MM3000.
    devMM4000.cDevice support for Newport MM4000.
    drvMM4000.cDriver for Newport MM4000.
    devPM500.cDevice support for Newport PM500.
    drvPM500.cDriver for Newport PM500.

    +
    +
    devSoft.cSoft Channel device support.
    devSoftAux.cSoft Channel device support (Note: CA and record access code cannot + both reside in the same file; each defines (redefines) the DBR's.  Hence, functions are split between this and the above file base on whether they are record oriented (devSoft.c) or CA oriented (devSoftAux.c).
    devSoft.hHeader included by devSoft.c and devSoftAux.c
    gpibIO.hGPIB communication include file.
    gpibIO.cGPIB interface via Hideos.
    serialIO.h Serial communication include file.
    serialIOMPF.ccSerial communication interface via MPF.
    drvIM483.hCommon header included by all IMS device drivers.
    dev483PL.cDevice support for IM483 in party line communication mode.
    dev483SM.cDevice support for IM483 in single mode communication mode.
    drv483PL.cDriver for IM483 in party line communication mode.
    drv483SM.cDriver for IM483 in single mode communication mode.
    Makefile.VxThis file is not included in the distribution. However, the user must -edit this file and add lines similar to the following: -
    MOTOR_OBJS       = motorRecord.o devOms.o drvOms.o devOms58.o drvOms58.o
-LIBNAME = mylib.o
-LIBOBJS = $(MOTOR_OBJS) $(other objects here)
-
-
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ASCII FILES -
    files to be placed in &lttop>/cat_ascii/
    motorRecord.asciiThis file defines all of the fields for the motor record.
    choiceRecMotor.asciiThis file defines all of the choice values for the motor record.
    choiceMotor.hThis file is included by choiceRecMotor.ascii and by recMotor.c.
    choiceRec.asciiThis file is not included in the distribution. However, the user must -edit this file and add the line: -
    #include &ltchoiceRecMotor.ascii>
    -
    dbRecType.asciiThis file is not included in the distribution. However, the user must -edit this file and add the line: -
    "motor"
    -
    devSup.asciiThis file is not included in the distribution. However, the user must -edit this file and add the following lines: -
    ! Device Support for motor record
-"motor"    VME_IO    "devOMS"     "OMS VME8, VME44" 
-"motor"    VME_IO    "devOms58"   "OMS VME58" 
-"motor"    VME_IO    "devV544"    "Highland V544" 
    -
    drvSup.asciiThis file is not included in the distribution. However, the user must -edit or create this file and add the following lines: -
    ! Driver support for the OME VME58 motor controller
-"drvOms58"
-
-
-
-
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    MEDM DISPLAY SCREENS -
    files to be placed in &lttop>/&ltapp&gtApp/op/adl/
    motorx.adlSmall motor-control screen
    motorx_tiny.adl Tiny motor-control screen
    motorx_more.adl Medium motor-control screen
    motorx_setup.adlSetup screen for a single motor
    motorx_all.adl Debug screen for a single motor
    These files build medm screens to access the motor -record. To use one of them from the command line, type, for example -
    medm -x -macro "P=XXX:,M=m1" motorx.adl
    -where XXX:m1 is the name of a motor record in an IOC. -

    These files can also be used as related displays from other medm -screens by passing the argument "P=XXX:,M=m1".

    - - - - - - - - - - - - - - + + + +
    -
    EPICS STARTUP FILES -
    files to be placed in &lttop>/ioc/ioc&ltname>/
    st.cmdmv167 Startup script
    A sample startup script, containing excerpts relevant to -motors, is included in the distribution. Here is an annotated copy: -
    #######################################################################
-# vxWorks startup script to load and execute system (iocCore) software.
    -Load standard EPICS software -
    # the following should be loaded first - BEGIN
-ld < targetmv167/iocCore
-ld < targetmv167/drvSup
-ld < targetmv167/devSup
-ld < targetmv167/recSup
-# the following should be loaded first - END
    -Load custom EPICS software (including motor support) -
    ld < ../../stdApp/src/O.mv167/stdlib.o
    -Motor-related debug switches  -
    recMotordebug = 0
-
-#OMS vme8/vme44 debug switches
-devOMSdebug = 0
-drvOMSdebug = 0
-
-#OMS vme58 debug switches
-devOms58debug = 0
-drvOms58debug = 0
-
-#Highland Technology V544 debug switches
-devV544ebug = 0
-drvV544debug = 0
    -Motor-related databases  -
    # load this before loading any databases
-dbLoad "../../default.dctsdr"
-
-#allstop
-dbLoadRecords("../../stdApp/gDb/allstop.db","P=tmm:")
-#motors
-dbLoadRecords("../../stdApp/gDb/m16.db","P=tmm:")
    -Specify motor-controller board address, interrupt -vector, etc. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
       omsSetup(nCards, Unused, baseAddress, -intVectBase, intLevel, pollRate) -
     oms58Setup(nCards, Unused, baseAddress, intVectBase, intLevel, -pollRate) -
      v544Setup(nCards, nAxes,  baseAddress, intVectBase, -intLevel, pollRate) -

    MM3000Setup(nCards, Unused,                                     -pollRate) -
    MM3000Config(card#, portType, GPIB link or hideos_card#, GPIB address -or hideos_task name) -

    MM4000Setup(nCards, Unused,                                     -pollRate) -
    MM4000Config(card#, portType, GPIB link or hideos_card#, GPIB address -or hideos_task name) -

    IM483SMSetup(nCards, Unused,                                    -pollRate)  -
    IM483SMConfig(card#, portType, GPIB link or hideos_card#, GPIB -address or hideos_task name)  -

    IM483[PL/SM]Setup(nCommNet, Unused,                             -pollRate)  -
    IM483[PL/sm]Config(CommNet#, portType, GPIB link or hideos_card#, -GPIB address or hideos_task name)  -
     

    nCardsthe actual number of cards may be less, but not greater than this
    nCommNetthe number of Communication networks  (e.g., the number of RS-422 -networks for a IM483PL device).
    nAxesthe maximum number of motor axes controlled by any one card
    baseAddressthe base address of the first card of a series. This must agree with -address jumpers on the actual card(s). -

    OMS VME8, VME44, and VMEX cards are all of one series, with a base address -in the short address space, on a 16-byte (0x10) boundary. (I.e., these -cards require 16 bytes each, and must all be addressed contiguously as, -e.g., 0xFC00, 0xFC10). -

    OMS VME58-x cards are in their own series, also in the short address -space, on a 4k-byte (0x1000) boundary. -

    Highland Technology V544 cards are in their own series, in the short -address space, on a 128-byte (0x80) boundary.

    intVectBasethe interrupt vector that will be loaded into the first card of a series. -Succeeding cards will be loaded with intVectBase+1, intVectBase+2, etc. -Set to "0" to disable interrupt generation; otherwise, stay in the range +
    devSoft.hHeader included by devSoft.c and devSoftAux.c

    +
    +
    gpibIO.hGPIB communication include file.
    gpibIO.cGPIB interface via Hideos.
    serialIO.h Serial communication include file.
    serialIOMPF.ccSerial communication interface via MPF.

    +
    +
    drvIM483.hCommon header included by all IMS device drivers.
    dev483PL.cDevice support for IM483 in party line communication mode.
    dev483SM.cDevice support for IM483 in single mode communication mode.
    drv483PL.cDriver for IM483 in party line communication mode.
    drv483SM.cDriver for IM483 in single mode communication mode.

    +
    +

    +
    +
    Makefile.VxThis file is not included in the distribution. However, the user must + edit this file and add lines similar to the following: + 
    MOTOR_OBJS       = motorRecord.o devOms.o drvOms.o devOms58.o drvOms58.o
    LIBNAME = mylib.o
    LIBOBJS = $(MOTOR_OBJS) $(other objects here)

    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ASCII FILES
    + files to be placed in &lttop>/cat_ascii/
    motorRecord.asciiThis file defines all of the fields for the motor record.
    choiceRecMotor.asciiThis file defines all of the choice values for the motor record.
    choiceMotor.hThis file is included by choiceRecMotor.ascii and by recMotor.c.
    choiceRec.asciiThis file is not included in the distribution. However, the user must + edit this file and add the line: + 
    #include &ltchoiceRecMotor.ascii>
    +
    dbRecType.asciiThis file is not included in the distribution. However, the user must + edit this file and add the line: + 
    "motor"
    +
    devSup.asciiThis file is not included in the distribution. However, the user must + edit this file and add the following lines: + 
    ! Device Support for motor record
    "motor"    VME_IO    "devOMS"     "OMS VME8, VME44" 
    "motor"    VME_IO    "devOms58"   "OMS VME58" 
    "motor"    VME_IO    "devV544"    "Highland V544" 
    +
    drvSup.asciiThis file is not included in the distribution. However, the user must + edit or create this file and add the following lines: + 
    ! Driver support for the OME VME58 motor controller
    "drvOms58"



    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    MEDM DISPLAY SCREENS
    + files to be placed in &lttop>/&ltapp&gtApp/op/adl/
    motorx.adlSmall motor-control screen
    motorx_tiny.adl Tiny motor-control screen
    motorx_more.adl Medium motor-control screen
    motorx_setup.adlSetup screen for a single motor
    motorx_all.adl Debug screen for a single motor
    These files build medm screens to access the motor + record. To use one of them from the command line, type, for example + + 
    medm -x -macro "P=XXX:,M=m1" motorx.adl
    + where XXX:m1 is the name of a motor record in an IOC. + +

    These files can also be used as related displays from other + medm screens by passing the argument "P=XXX:,M=m1" + .

    +
    + + + + + + + + + + + + - -

    + EPICS STARTUP FILES
    + files to be placed in &lttop>/ioc/ioc&ltname>/
    st.cmdmv167 Startup script
    A sample startup script, containing excerpts relevant to + motors, is included in the distribution. Here is an annotated copy: + + 
    #######################################################################
    # vxWorks startup script to load and execute system (iocCore) software.
    + Load standard EPICS software + + 
    # the following should be loaded first - BEGIN
    ld < targetmv167/iocCore
    ld < targetmv167/drvSup
    ld < targetmv167/devSup
    ld < targetmv167/recSup
    # the following should be loaded first - END
    + Load custom EPICS software (including motor support) + + 
    ld < ../../stdApp/src/O.mv167/stdlib.o
    + Motor-related debug switches  + + 
    recMotordebug = 0

    #OMS vme8/vme44 debug switches
    devOMSdebug = 0
    drvOMSdebug = 0

    #OMS vme58 debug switches
    devOms58debug = 0
    drvOms58debug = 0

    #Highland Technology V544 debug switches
    devV544ebug = 0
    drvV544debug = 0
    + Motor-related databases  + + 
    # load this before loading any databases
    dbLoad "../../default.dctsdr"

    #allstop
    dbLoadRecords("../../stdApp/gDb/allstop.db","P=tmm:")
    #motors
    dbLoadRecords("../../stdApp/gDb/m16.db","P=tmm:")
    + Specify motor-controller board address, interrupt + vector, etc. + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - + + + + + + + - - - - - - - -
       omsSetup(nCards, Unused, baseAddress, +intVectBase, intLevel, pollRate)
    +  oms58Setup(nCards, Unused, baseAddress, intVectBase, +intLevel, pollRate)
    +   v544Setup(nCards, nAxes,  baseAddress, intVectBase, + intLevel, pollRate) +

    MM3000Setup(nCards, Unused,                                     + pollRate)
    + MM3000Config(card#, portType, GPIB link or hideos_card#, +GPIB address or hideos_task name)

    + +

    MM4000Setup(nCards, Unused,                                     + pollRate)
    + MM4000Config(card#, portType, GPIB link or hideos_card#, +GPIB address or hideos_task name)

    + +

    IM483SMSetup(nCards, Unused,                                    + pollRate) 
    + IM483SMConfig(card#, portType, GPIB link or hideos_card#, +GPIB address or hideos_task name) 

    + +

    IM483[PL/SM]Setup(nCommNet, Unused,                             + pollRate) 
    + IM483[PL/sm]Config(CommNet#, portType, GPIB link or +hideos_card#, GPIB address or hideos_task name) 
    +  

    +
    nCardsthe actual number of cards may be less, but not greater than this
    nCommNetthe number of Communication networks  (e.g., the number of RS-422 + networks for a IM483PL device).
    nAxesthe maximum number of motor axes controlled by any one card
    baseAddressthe base address of the first card of a series. This must agree with + address jumpers on the actual card(s). +

    OMS VME8, VME44, and VMEX cards are all of one series, +with a base address in the short address space, on a 16-byte (0x10) boundary. +(I.e., these cards require 16 bytes each, and must all be addressed contiguously +as, e.g., 0xFC00, 0xFC10).

    + +

    OMS VME58-x cards are in their own series, also in the +short address space, on a 4k-byte (0x1000) boundary.

    + +

    Highland Technology V544 cards are in their own series, +in the short address space, on a 128-byte (0x80) boundary.

    +
    intVectBasethe interrupt vector that will be loaded into the first card of a +series. Succeeding cards will be loaded with intVectBase+1, intVectBase+2, +etc. Set to "0" to disable interrupt generation; otherwise, stay in the range [64..255].
    intLevelthe VME-interrupt level (in [1..6]) the cards will use. This must agree -with jumper settings on the cards.
    pollRatethe rate (in Hz.) at which the driver will interrogate a card when +
    intLevelthe VME-interrupt level (in [1..6]) the cards will use. This must +agree with jumper settings on the cards.
    pollRatethe rate (in Hz.) at which the driver will interrogate a card when one of its motors is moving. This is also the rate at which channel-access monitors will be posted; to avoid saturating the network with motor-readback information, don't set pollRate much higher than 10 Hz. pollRate must be in the range [1..60].
    portType0 - GPIB_PORT or 1 - RS232_PORT
    - -
    # OMS VME8, VME44, VMEX driver setup parameters:
-omsSetup(5, 8, 0xFC00, 180, 5, 10)
-
-# OMS VME58 driver setup parameters:
-oms58Setup(5, 8, 0x2000, 190, 5, 10)
-
-# Highland Technology V544 driver setup parameters:
-v544Setup(5, 4, 0xDD00, 200, 5, 10)
    -Start EPICS -
    iocInit
    -
    - - - - - - - - - - + + + + + + +
    BACKUP/RESTORE (BURT) REQUEST FILES -
    files to be placed in &lttop>/&ltapp&gtApp/op/burt/
    settings.reqsample request file to save settings of all motors. Edit this file, -supplying names of the motor records whose settings you want saved. (The +
    portType0 - GPIB_PORT or 1 - RS232_PORT
    + + 
    # OMS VME8, VME44, VMEX driver setup parameters:
    omsSetup(5, 8, 0xFC00, 180, 5, 10)

    # OMS VME58 driver setup parameters:
    oms58Setup(5, 8, 0x2000, 190, 5, 10)

    # Highland Technology V544 driver setup parameters:
    v544Setup(5, 4, 0xDD00, 200, 5, 10)
    + Start EPICS + 
    iocInit
    +
    + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - -
    BACKUP/RESTORE (BURT) REQUEST FILES
    + files to be placed in &lttop>/&ltapp&gtApp/op/burt/
    settings.reqsample request file to save settings of all motors. Edit this file, + supplying names of the motor records whose settings you want saved. (The sample file also saves the states of other records in the sample database, m16.db, that enable or disable the motor records.)
    yyMotorSettings.req save settings of a specified motor. This file is #include'd -(once for each motor) by settings.req.
    positions.req sample request file to save positions of all motors. Edit this file, -supplying names of the motor records whose positions you want saved.
    yyMotorPositions.req save position of a specified motor, This file is #include'd -(once for each motor) by positions.req.
    These files tell the backup/restore tool how to save motor -settings and positions. To use them from the command line, type, for example -
    burtrb -f settings.req -o myMotorSettings.snap
-
-burtrb -f positions.req -o myMotorPositions.snap
-
-
    -To restore the motor settings and positions saved by the above commands, -type -
    burtwb -f myMotorSettings.snap
-
-burtwb -f myMotorPositions.snap
-
-
    -
    - -
    -

    -Restrictions

    -You must not change the motor resolution while the motor is moving, -but the record currently does not defend itself against this. -

    There is no way to ask for a reading of the motor's position register, -encoder, or limit switches. These are read only while the motor is moving. -

    Because of the way limit-switch information is conveyed by the OMS hardware, -the motor record cannot know the states of both limit switches at the same -time. It only knows the state of the switch toward which the motor is moving. -

    If a move is requested while the motor already is in motion, the original -move will still receive a (useless) backlash correction. -

    Changing MRES (the motor resolution) should change VELO (the speed in -engineering units per second), and leave S (the speed in revolutions per -second) unchanged. Currently, neither VELO nor S appears to change, but +

    yyMotorSettings.req save settings of a specified motor. This file is #include +'d (once for each motor) by settings.req.
    positions.req sample request file to save positions of all motors. Edit this file, + supplying names of the motor records whose positions you want saved.
    yyMotorPositions.req save position of a specified motor, This file is #include +'d (once for each motor) by positions.req.
    These files tell the backup/restore tool how to save motor + settings and positions. To use them from the command line, type, for example + + 
    burtrb -f settings.req -o myMotorSettings.snap

    burtrb -f positions.req -o myMotorPositions.snap

    + To restore the motor settings and positions saved by the above commands, + type + 
    burtwb -f myMotorSettings.snap

    burtwb -f myMotorPositions.snap

    +
    + +
    + +

    Restrictions

    + You must not change the motor resolution while the motor is moving, + but the record currently does not defend itself against this. +

    There is no way to ask for a reading of the motor's position register, + encoder, or limit switches. These are read only while the motor is moving. +

    + +

    Because of the way limit-switch information is conveyed by the OMS +hardware, the motor record cannot know the states of both limit switches at +the same time. It only knows the state of the switch toward which the motor +is moving.

    + +

    If a move is requested while the motor already is in motion, the original + move will still receive a (useless) backlash correction.

    + +

    Changing MRES (the motor resolution) should change VELO (the speed +in engineering units per second), and leave S (the speed in revolutions per + second) unchanged. Currently, neither VELO nor S appears to change, but the record behaves as though S had been changed to agree with VELO. A similar -thing happens with SBAK and SBAS. -
    -

    -
    -

    -Examples

    - -

    -Command Primitives

    -This example assumes the controller is an MM4000 and that only one motor -in the controller is moved at a time (MM4000 power on/off effects all motors).  -If the user wishes the system to perform as follows: -
      -
    1. -Boot-up with motor power off.
      2. - -
    2. -Turn motor power on before motor motion.
      3. - -
    3. -Turn motor power off after motor motion.
      4. -
    -Then set fields as follows: -
      -
    • -INIT = "MF"
      • - -
    • -PREM = "MO"
      • - -
    • -POST = "MF"
      • -
    - -

    -Soft Channel

    -The following is a simple example of using soft channel device support + thing happens with SBAK and SBAS.
    +

    + +

    + + +

    Examples

    + +

    Command Primitives

    + This example assumes the controller is an MM4000 and that only one motor + in the controller is moved at a time (MM4000 power on/off effects all motors).  + If the user wishes the system to perform as follows: +
      +
    1. Boot-up with motor power off.
      2. +
    2. Turn motor power on before motor motion.
      3. +
    3. Turn motor power off after motor motion.
      4. + +
    + Then set fields as follows: +
      +
    • INIT = "MF"
      • +
    • PREM = "MO"
      • +
    • POST = "MF"
      • + +
    + +

    Soft Channel

    + The following is a simple example of using soft channel device support to allow the user to transform rotary position commands into linear moves.  -This example assumes the system consist of a linear stage driving a tangent -arm.  The user commands the system in terms of the angle the arm makes -with the vertical.  The database converts this angle into a linear -position along an axis that is one meter perpendicular to the center of -rotation. -

    The following database implements the system described above.  -The database consist of four records: -

      -
    • -rotary - a soft motor record where the user issues angular -position commands in degrees.
      • - -
    • -convertDriveValue - a calcout record that converts the commanded -position from degrees to mm.
      • - -
    • -linear -  a hard motor record using Oms58 device support -that accepts linear position commands in mm.
      • - -
    • -convertReadbackValue - calcout record that converts the feedback -position from mm -to -degrees.
      • -
    -Note the following concerning the example database and Soft Channel device -support: -
      -
    • -Jogging a soft channel motor record is not supported.
      • - -
    • -In the convertReadbackValue record, CP is required in the INPA field -to get continuous readback updates to the rotary record.  Otherwise, -the rotary record will only update at the end of a move.
      • - -
    • -The convertDriveValue record converts rotary's DVAL field -from degrees to radians, takes the tangent, converts from meters to millimeters -and finally, sends this value to linear's DVAL field.
      • - -
    • -The convertReadbackValue record converts linear's DRBV field -from millimeters to meters, takes the inverse tangent and finally, converts + This example assumes the system consist of a linear stage driving a tangent + arm.  The user commands the system in terms of the angle the arm makes + with the vertical.  The database converts this angle into a linear +position along an axis that is one meter perpendicular to the center of rotation. + +

      The following database implements the system described above.  + The database consist of four records:

      + +
        +
      • rotary - a soft motor record where the user issues angular + position commands in degrees.
        • +
      • convertDriveValue - a calcout record that converts +the commanded position from degrees to mm.
        • +
      • linear -  a hard motor record using Oms58 device +support that accepts linear position commands in mm.
        • +
      • convertReadbackValue - calcout record that converts +the feedback position from mm to degrees.
        • + +
      + Note the following concerning the example database and Soft Channel device + support: +
        +
      • Jogging a soft channel motor record is not supported.
        • +
      • In the convertReadbackValue record, CP is required in the +INPA field to get continuous readback updates to the rotary record.  +Otherwise, the rotary record will only update at the end of a move.
        • +
      • The convertDriveValue record converts rotary's DVAL +field from degrees to radians, takes the tangent, converts from meters to +millimeters and finally, sends this value to linear's DVAL field + .
        • +
      • The convertReadbackValue record converts linear's DRBV +field from millimeters to meters, takes the inverse tangent and finally, converts from radians to degrees.
        • -
      - - - - - - - - - - - - - -
      grecord(motor,"$(user):rotary") -
      { -
          field(DTYP,"Soft Channel") -
          field(OUT,"$(user):convertDriveValue.A  PP -MS") -
          field(RDBL,"$(user):convertReadbackValue.VAL  -NPP MS") -
          field(URIP,"Yes") -
          field(STOO,"$(user):linear.STOP  PP MS") -
          field(DINP,"$(user):linear.DMOV  NPP MS") -
          field(MRES,"0.001") -
          field(RRES,"1.000") -
          field(PREC,"3") -
          field(DHLM,"45") -
          field(DLLM,"-45") -
          field(TWV,"5") -
          field(RTRY,"0") -
          field(EGU,"deg.") -
      }      		grecord(motor,"$(user):linear") -
      { -
          field(DTYP,"OMS VME58") -
          field(VBAS,"1.0") -
          field(VELO,"25.0") -
          field(OUT,"#C0 S0 @") -
          field(MRES,"0.001") -
          field(PREC,"3") -
          field(DHLM,"1000") -
          field(DLLM,"-1000") -
          field(RTRY,"0") -
          field(TWV,"1") -
          field(EGU,"mm.") -
      }
      grecord(calcout,"$(user):convertDriveValue") -
      { -
          field(DESC,"Convert rotary to linear") -
          field(CALC,"TAN(A / 57.296) * 1000") -
          field(OUT,"$(user):linear.DVAL  PP MS") -
      }      		grecord(calcout,"$(user):convertReadbackValue") -
      { -
          field(DESC,"Convert linear to rotary") -
          field(CALC,"ATAN(A / 1000) * 57.296") -
          field(INPA,"$(user):linear.DRBV  CP MS") -
      }
      - -

      -

      -Design Decisions

      -This section of the document is an attempt to record the reasoning behind -recent motor record design decisions. -

      -Motor Controller Travel Limits

      -For those motor controllers that provide their own internal software travel -limits (e.g., MM4000), the motor record will only allow the user to set + +
    + + + + + + + + + + + + + +
    grecord(motor,"$(user):rotary")
    + {
    +     field(DTYP,"Soft Channel")
    +     field(OUT,"$(user):convertDriveValue.A  PP MS") +
    +     field(RDBL,"$(user):convertReadbackValue.VAL  NPP +MS")
    +     field(URIP,"Yes")
    +     field(STOO,"$(user):linear.STOP  PP MS")
    +     field(DINP,"$(user):linear.DMOV  NPP MS")
    +     field(MRES,"0.001")
    +     field(RRES,"1.000")
    +     field(PREC,"3")
    +     field(DHLM,"45")
    +     field(DLLM,"-45")
    +     field(TWV,"5")
    +     field(RTRY,"0")
    +     field(EGU,"deg.")
    + }    		grecord(motor,"$(user):linear")
    + {
    +     field(DTYP,"OMS VME58")
    +     field(VBAS,"1.0")
    +     field(VELO,"25.0")
    +     field(OUT,"#C0 S0 @")
    +     field(MRES,"0.001")
    +     field(PREC,"3")
    +     field(DHLM,"1000")
    +     field(DLLM,"-1000")
    +     field(RTRY,"0")
    +     field(TWV,"1")
    +     field(EGU,"mm.")
    + }
    grecord(calcout,"$(user):convertDriveValue")
    + {
    +     field(DESC,"Convert rotary to linear")
    +     field(CALC,"TAN(A / 57.296) * 1000")
    +     field(OUT,"$(user):linear.DVAL  PP MS")
    + }    		grecord(calcout,"$(user):convertReadbackValue")
    + {
    +     field(DESC,"Convert linear to rotary")
    +     field(CALC,"ATAN(A / 1000) * 57.296")
    +     field(INPA,"$(user):linear.DRBV  CP MS")
    + }
    + +

    +

    + +

    Design Decisions

    + This section of the document is an attempt to record the reasoning behind + recent motor record design decisions. +

    Motor Controller Travel Limits

    + For those motor controllers that provide their own internal software travel + limits (e.g., MM4000), the motor record will only allow the user to set dial travel limits (i.e., D[H/L]LM) that are within the controller's travel limit range, inclusively.  In making this design decision it was assumed that an expert user would enter the controller travel limits (possibly, -through a front panel user interface) that would protect other users from -reaching the hard travel limits.  Controllers with their own travel + through a front panel user interface) that would protect other users from + reaching the hard travel limits.  Controllers with their own travel limits that are commanded to move outside their valid range respond with -an error.  Hence, there is no utility in allowing the dial travel -limits outside the controller's range. -

    -Separate EGU's and MRES's between Controller and Motor Record

    -Device driver support for controllers that have characteristics different -from the OMS controllers, such as the Newport MM4000, has raised new issues.  -One of these issues is whether or not the motor record should set it's -EGU and MRES fields from the controller's values.  We think it should -not. -

    Background: The MM4000 is a stand-alone controller with it's own front -panel, non-volatile memory and power supply.  The user can configure -the MM4000 entirely from the front panel; including which engineering units -will be displayed on the front panel.  Once engineering units are -selected, these same units will be used by the MM4000 when communicating -with a host system (i.e., EPICS).  Since a host can query the MM4000 -for both the controller's engineering units and it's positioning resolution, -it is possible to have the motor record's EGU and MRES fields automatically -set based on values stored in the MM4000 controller, but we decided not -to do this. -

    To maximize flexibility, we decided to keep these characteristics separate -between the motor record and the controller.  This decision allows -the motor record EGU field (and consequently, MRES) to be set to an application +an error.  Hence, there is no utility in allowing the dial travel limits +outside the controller's range. +

    Separate EGU's and MRES's between Controller and Motor Record

    + Device driver support for controllers that have characteristics different + from the OMS controllers, such as the Newport MM4000, has raised new issues.  + One of these issues is whether or not the motor record should set it's EGU +and MRES fields from the controller's values.  We think it should not. + +

    Background: The MM4000 is a stand-alone controller with it's own front + panel, non-volatile memory and power supply.  The user can configure + the MM4000 entirely from the front panel; including which engineering units + will be displayed on the front panel.  Once engineering units are selected, +these same units will be used by the MM4000 when communicating with a host +system (i.e., EPICS).  Since a host can query the MM4000 for both the +controller's engineering units and it's positioning resolution, it is possible +to have the motor record's EGU and MRES fields automatically set based on +values stored in the MM4000 controller, but we decided not to do this.

    + +

    To maximize flexibility, we decided to keep these characteristics separate +between the motor record and the controller.  This decision allows the +motor record EGU field (and consequently, MRES) to be set to an application specific value (e.g., kV) that is not supported by the motor controller. -
      -
      -

    -

    -
    -Suggestions and comments to:
    - -
    Ron Sluiter : (sluiter@aps.anl.gov) -
    Tim Mooney : (mooney@aps.anl.gov) -
    Joe Sullivan : (sullivan@aps.anl.gov) -
    Last modified: July 12, 1999 - - +
    +  
    +  

    + +

    + +
    +
    Suggestions and comments to:
    +
    + Ron Sluiter + : (sluiter@aps.anl.gov)
    + Tim Mooney + : (mooney@aps.anl.gov)
    + Joe Sullivan + : (sullivan@aps.anl.gov)
    + Last modified: July 12, 1999 + + diff --git a/documentation/motor_release.html b/documentation/motor_release.html index b5e096f3..daa541de 100644 --- a/documentation/motor_release.html +++ b/documentation/motor_release.html @@ -1,653 +1,715 @@ - + - - + + + + + + + + + EPICS Motor Record Release Notice - - -
    -

    -Motor Record Version 4.4 Release Notice

    - -
    + + +
    +

    Motor Record Version 4.5 Release Notice

    +
    +!WARNING!
    +motorRecord.dbd has been modified.  This requires you to 'rebuild' any +and all user trees (i.e., <ioctop>) that load the motor record (see +README item #2 for details). +
    +

    Modifications to Existing Features

    +
    + Communication Retries +

    Once a communication error is detected, one retry is attempted (Further +retries are made, if the position RETRY field is non-zero).  If the retry +fails, then a communication error is reported.  No further attempt is +made to communicate with the controller until subsequent user input (e.g., +a new target position is entered).  This change affects all device drivers +using GPIB or RS232 serial communication mechanisms (i.e., non-VME Bus boards). +

    +

    -Modifications to Existing Features

    -Disable Travel Limits -

    The travel limits can be disabled by setting both dial high and low -limits equal to zero; i.e., DHLM = DLLM = 0. -

    RVAL ignored error -

    A problem was discovered with entering target positions through RVAL.  -If the difference between the current and the next target position (i.e., -RDIF, DIFF) was less than the retry deadband (RDBD), and the next target -position was in the "preferred direction", then the new RVAL was ignored.  -This error occured on releases as far back as V3.4. -

    New Features
    -Jog velocity and acceleration parameters -

    Two new fields (JVEL and JAR) were added to  support jog velocity -and acceleration parameters.  These fields are only supported with -Oregon Micro Systems, Inc device driver support.  The JVEL field allows -the user to change the jog velocity of the motor on-the-fly. -

    -

    -Motor Record Version 4.3 Release Notice

    -This release of the motor record is strictly a bug fix release; no new -features have been added. -

    STOP field hangs record -

    An error was introduced into the motor record with the release of V4.2 -(see README file item #14 under V4.2 ).  This error occurred if the -STOP field was activated when the motor was not moving (i.e., MIP = 0).  -The motor record would become "stuck", and not respond to a move request -(due to the internal state machine associated with IP being set to the -"stop" state), until the condition was cleared by either a SPMG-stop or -some other user action that forced the MIP field to zero. -

    HIDEOS support removed -

    HIDEOS is no longer supported.  MPF is the only supported alternative -to HIDEOS. -
      -

    -

    -Motor Record Version 4.2 Release Notice

    -This release of the motor record is compatible with EPICS R3.13.2 and above. -

    !WARNING! -
    motorRecord.dbd has been modified.  This requires you to 'rebuild' -any and all user trees (i.e., <ioctop>) that load the motor record (see -README item #20 for details). -
      -
      -

    -

    -Modifications to Existing Features

    -Precedence between field pairs -

    At boot-up, if one field of a field pair (i.e., VMAX/SMAX, VBAS/SBAS, -VELO/S, BVEL/SBAK) is zero and the other field is nonzero, the nonzero -field takes precedence.  If both fields of a given field pair are -nonzero, the RPS member of the field pair (i.e., SMAX, SBAS, S, SBAK) takes -precedence.  This requirement was lost with the release of V4.0. -

    Moving Off a Limit Switch with a Oms58 device -

    An error occurs with the OMS VME58 when the user runs the motor into -a limit switch and then attempts to move away from the limit switch.  -If either an absolute or incremental move is utilized to move away from -the limit switch, the OMS VME58 ignores the 1st move attempt.  Subsequent -moves work.  In addition, the user can jog off a limit switch.  -This error was hidden in most applications if RTRY was nonzero. -

    Separate motion commands for target and backlash moves -

    The record level support assumed that the motor controller would accept -two motion commands on the same command line.  This occurs when backlash -compensation is enabled.  Since the IM483[PL/SM] controller does not -have this capability, support for a command line "record separator" character -was added.  The record separator is defined as an ASCII (IS2) character -= /x1E.  Currently, only one record separator is allowed in a command -line. -

    Errors introduced in V4.0 -

    Unfortunately, several errors were introduced into the motor record -with V4.0.  The following have been fixed: -

      -
    • -If the "ncards" argument of the omsSetup() function in st.cmd file was -not accurate (i.e., did not match the actual number of OMS VME8/44 boards -in the VME crate); the "dbior" command could result in erroneous information +

      Requirements Clarification

      + +The requirements on how the motor record processes a new target position +while the motor is in motion have never been specified.  The requirements +are as follows:
      +
      Case #1:  The motor record is given a new position, which +is in the opposite direction from the current motor motion.  The motor +is immediately stopped and given a motion command to the new position.
      +
      Case #2:  The motor record is given a new position, which +is in the same direction as the current motor motion, but the new position +is closer to the motor's current position than the original target position.  +The motor is stopped after it has gone past the new position; then a command +is given to return to the new position.
      +
      +Case #3:  The motor record is given a new position, which is in the +same direction as the current motor motion, but the new position is further +from the motor's current position than the original position.  After +the motor reaches the original target position and stops, a command is given +to the new target position (Previous motor record versions ignored the new +target position.)
      +

      Bug Fix for Driver Power Monitoring error

      + The Driver Power Monitoring feature (available only with OMS VME58 +controllers) was erroneously and randomly being enabled.  This resulted +in the error message Drive power failure at VME58 card# motor# appearing +at the VxWorks console. +

      Soft Channel device support modifications

      +
        +
      • Prevent record processing before "interruptAccept" is true.  This +helps prevent alarms.
        • +
      • If the readback is changing, but motion was not initiated by this +record, then reset the motor record's target to actual position (i.e., VAL/DVAL/RVAL += RBV/DRBV/RRBV) after the move.
        • +
      • Lowered the priority of the "soft_motor task below the "dbCaLink" +task.  This fixes the "DMOV processing before the last DRBV update" +problem.
        +
        • + +
      + Bug Fix for Array Holes in VMEbus based controllers +

      For VMEbus based motor controllers only (i.e., OMS), a hole + in an array of VME based motor controller boards caused the system to crash +with a memory access error on the address of the missing controller.  +For example, if oms58Setup(3, 8, 0x4000, 190, 5, 10) was issued without a +board at 0xFFFF5000, a bus error would occur if the user attempted to move +a motor on the missing board.

      +

      This release allows holes in an array of VMEbus based motor +controllers.

      +

      RES Field

      +

      With previous releases of the motor record, the RES field was set +to either ERES or MRES, based on whether or not the following statement was +true; MSTA indicates an encoder is present, AND, UEIP is set to YES.  +This state (i.e., MSTA indicates an encoder is present, AND, UEIP is set to +YES) resulted in the record converting all position and velocity related values +from EGU's to raw encoder counts before sending them to the motor controller.  +This is the manner in which the OMS controllers work (see OMS User's Manual, +ER# command).

      +

      With this release, all raw positions, velocity and acceleration are +in terms of motor steps.  The RES field is preserved for backward compatibility + only.  With this release, the RES field is always equal to MRES.
      +

      +

      Backlash Correction

      +Previous motor record releases put both the "slew" and backlash correction +moves on the same motor controller command line.  Some controllers (i.e., +OMS) handled this correctly by processing the slew move followed by the backlash +correction move.  Other controllers (i.e, Newport) did not handle this +correctly and processed the commands immediately, resulting in the controller +moving to the target position without backlash correction, but at the backlash +correction velocity.
      +
      +With this release, backlash correction commands are not issued to the controller +until after the slew move is completed.
      +

      Separate +/- Limit Switch status bits

      +The MSTA field has been modified by providing separate +/- limit switch status +bits.  The MSTA bits are defined as follows: +
      +
        +
      1. DIRECTION: (0:Negative, 1:Positive)
        2. +
      2. DONE: motion is complete.
        3. +
      3. PLUS_LS: plus limit switch has been hit.
        4. +
      4. HOMELS: state of the home limit switch.
        5. +
      5. Unused
        6. +
      6. POSITION: closed-loop position control is enabled.
        7. +
      7. Unused
        8. +
      8. HOME: if at home position.
        9. +
      9. PRESENT: encoder is present.
        10. +
      10. PROBLEM: driver stopped polling.
        11. +
      11. MOVING: non-zero velocity present.
        12. +
      12. GAIN_SUPPORT: motor supports closed-loop position control.
        13. +
      13. COMM_ERR: Controller communication error.
        14. +
      14. MINUS_LS: minus limit switch has been hit.
        +
        15. +
      +
      +
      +
      +

      New Features

      +
      + +

      Advanced Control Systems and Mclennan device driver support +

      +

      Mark Rivers has added device driver support for the following motor +controllers:

      +
        +
      • Advanced Control Systems, Corp. model MCB-4B
        • +
      • Mclennan model PM304
        • + +
      + +
      +

      Motor Record Version 4.4 Release Notice

      +
      + +
      +

      Modifications to Existing Features

      +
      + Disable Travel Limits +

      The travel limits can be disabled by setting both dial high and +low limits equal to zero; i.e., DHLM = DLLM = 0.

      +

      RVAL ignored error

      +

      A problem was discovered with entering target positions through +RVAL.  If the difference between the current and the next target position +(i.e., RDIF, DIFF) was less than the retry deadband (RDBD), and the next +target position was in the "preferred direction", then the new RVAL was ignored.  +This error occured on releases as far back as V3.4.

      +
      New Features
      + Jog velocity and acceleration parameters +

      Two new fields (JVEL and JAR) were added to  support jog velocity +and acceleration parameters.  These fields are only supported with Oregon +Micro Systems, Inc device driver support.  The JVEL field allows the +user to change the jog velocity of the motor on-the-fly.

      +
      +

      Motor Record Version 4.3 Release Notice

      +
      + This release of the motor record is strictly a bug fix release; no new features +have been added. +

      STOP field hangs record

      +

      An error was introduced into the motor record with the release of +V4.2 (see README file item #14 under V4.2 ).  This error occurred if +the STOP field was activated when the motor was not moving (i.e., MIP = 0).  +The motor record would become "stuck", and not respond to a move request (due +to the internal state machine associated with IP being set to the "stop" +state), until the condition was cleared by either a SPMG-stop or some other +user action that forced the MIP field to zero.

      +

      HIDEOS support removed

      +

      HIDEOS is no longer supported.  MPF is the only supported alternative +to HIDEOS.
      + 

      +
      +

      Motor Record Version 4.2 Release Notice

      +
      + This release of the motor record is compatible with EPICS R3.13.2 and above. +

      !WARNING!
      +motorRecord.dbd has been modified.  This requires you to 'rebuild' any +and all user trees (i.e., <ioctop>) that load the motor record (see +README item #20 for details).
      + 
      + 

      +
      +

      Modifications to Existing Features

      +
      + Precedence between field pairs +

      At boot-up, if one field of a field pair (i.e., VMAX/SMAX, VBAS/SBAS, +VELO/S, BVEL/SBAK) is zero and the other field is nonzero, the nonzero field +takes precedence.  If both fields of a given field pair are nonzero, +the RPS member of the field pair (i.e., SMAX, SBAS, S, SBAK) takes precedence.  +This requirement was lost with the release of V4.0.

      +

      Moving Off a Limit Switch with a Oms58 device

      +

      An error occurs with the OMS VME58 when the user runs the motor +into a limit switch and then attempts to move away from the limit switch.  +If either an absolute or incremental move is utilized to move away from the +limit switch, the OMS VME58 ignores the 1st move attempt.  Subsequent +moves work.  In addition, the user can jog off a limit switch.  +This error was hidden in most applications if RTRY was nonzero.

      +

      Separate motion commands for target and backlash moves +

      +

      The record level support assumed that the motor controller would +accept two motion commands on the same command line.  This occurs when +backlash compensation is enabled.  Since the IM483[PL/SM] controller +does not have this capability, support for a command line "record separator" +character was added.  The record separator is defined as an ASCII (IS2) +character = /x1E.  Currently, only one record separator is allowed in +a command line.

      +

      Errors introduced in V4.0

      +

      Unfortunately, several errors were introduced into the motor record +with V4.0.  The following have been fixed:

      +
        +
      • If the "ncards" argument of the omsSetup() function in st.cmd file +was not accurate (i.e., did not match the actual number of OMS VME8/44 boards +in the VME crate); the "dbior" command could result in erroneous information or a bus error.
        • - -
      • -Jog request would not work after the state of the UEIP field was changd.
        • - -
      • -Backlash correction was not occurring after a JOG.
        • - -
      • -The motor record would 'hang' in the moving state on the rare occasion -when a target position (i.e., VAL or DVAL) fell almost exactly half way -between two integer RVAL values, and the retry feature was enabled (i.e., -RTRY is nonzero)
        • -
      - -
      -

      -New Features

      -Newport PM500 device support -

      Device driver support for the Newport PM500 is available for this release -of the motor record.  This device/driver is based on Mark River's -PM500 V2.0 release. -

      Intelligent Motion Systems, Inc. IM483 device support -

      Device driver support for Intelligent Motion Systems (IMS) IM483[I/IE] -is available with this release.  Two different device/drivers are -available for the same motor  controller.  The two device/drivers, -IM483PL and IM483SM, correspond to the two available IM483 communication -modes, party line and single mode, respectively (see the -IMS Software Reference Manual for details). -
        -

      -

      -Motor Record Version 4.1 Release Notice

      -Although the motor record software in this release is compatible with EPICS -baseR3.13.1.1 and above, the directory structure, the "make" files and -the configuration files are intended for the "unbundled" architecture of -EPICS R3.13.2 and above. -
      -

      -Modifications to Existing Features

      - -

      -OMS VME58 retry problem

      -Several errors in the OMS VME58 driver were found.  All the errors -caused the same problem.  Namely, erroneous retries occurred intermittently -when multiple axes were commanded to move on the same controller.  -This error occurred because old position data was being passed back from -the driver after Done was detected.  The erroneous intermittent retries -occurred more often when the Oms setup parameters called for a high frequency -(e.g., 60 Hz) "polling" rate and OMS board interrupts were enabled. -

      -OMS Stop problem

      -A problem with issuing a stop command (via either the STOP or SPMG field) -was found with all OMS boards and all versions of the OMS -device drivers.  The root cause of this problem is a statement in -the OMS manual that is not entirely correct; the AC and VL commands -are not completely queued. -
        -
        -
      -

      -Motor Record Version 4.0 Release Notice

      -Release 4.0 of the motor record is only compatible with EPICS baseR3.13.1.1 -and above.  This document describes changes made to the motor record -and its' associated device driver support between versions 3.5 and 4.0. -
      -

      -Modifications to Existing Features

      - -

      -GAIN Field Removed

      -Since the GAIN field is redundant (i.e., PID parameters can be set individually) -it has been removed. -
        -

      -HOM[F/R] Bug Fix

      -Previous releases of the motor record had a potential problem associated -with the homing function.  The motorx_all.adl V1.9 MEDM display sets -the HOM[F/R] fields on and off, corresponding to the user pressing and -releasing the respective home button.  Depending on the pollRate -defined in the st.cmd Setup command and the speed at which the user -toggled the HOM[F/R] buttons; the record level software would turn off -the DMOV field when the HOM[F/R] button was turned off and a motor status -update had not yet been received.  As a result, when the motor completed -it's homing function the command positions (i.e., VAL, DVAL, RVAL) were -not updated. -

      All previous motor record releases contained the DMOV problem; the commanded -position update problem was limited to the previous release (V3.5).  -With this release, a dbPutField to either HOMF or HOMR is valid on a FALSE -to TRUE transition (i.e., 0 to 1), but a TRUE to FALSE transition (i.e., -1 to 0) will result in an error.   motorx_all.adl_V2.2 -(which is included with this distribution) sets the HOM[F/R] fields on -when the user presses the homing button, but is does not set it -off when the button is released.  The motor record clears the HOM[F/R] -field when the homing operation is done (i.e., completed or terminated). -
        -

      -Initial Position

      -If both the auto restore and controller target position values are non-zero -at boot-up, then DVAL will be initialized from the controller's value.  -In other words, the controller's target position takes precedence over -the autorestore value when both systems have non-zero DVAL values.  -As before, it is assumed that a zero target position from autorestore or -the controller at boot-up are default values, and hence, they are ignored -in favor of a non-zero value. -

      Previous releases of the motor record allowed the auto restore to take -precedence over the controller when initializing the target position (i.e., -DVAL). -
        -

      -Access Security Level

      -In order to support the new VMAX/SMAX fields, the Access Security Level -for the following fields have been changed from one to zero: -
      -
        -
      • -MRES
        • - -
      • -UREV
        • - -
      • -VBAS
        • - -
      • -SBAS
        • -
      -
      - -

      -MM4000/5 Device Driver

      -Although the previous motor record release (V3.5) had device driver support -for the MM4000, it is not recommended for use with either the MM4000 -or the MM4005 controllers.  The following changes were made to the -previous release to create, what is now, the MM4000/5 device driver support: -
        -
      1. -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.
        2. - -
          -
        1. -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.
          2. - -
        2. -Since the MM4005's position cannot be set by EPICS, the initial position -of its' motors (see Initial Position above) will always be initialized +
        3. Jog request would not work after the state of the UEIP field was changd.
          4. +
        4. Backlash correction was not occurring after a JOG.
          5. +
        5. 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)
          6. + +
    + +
    +

    New Features

    +
    + Newport PM500 device support +

    Device driver support for the Newport PM500 is available for this +release of the motor record.  This device/driver is based on Mark River's +PM500 V2.0 release.

    +

    Intelligent Motion Systems, Inc. IM483 device support +

    +

    Device driver support for Intelligent Motion Systems (IMS) IM483[I/IE] +is available with this release.  Two different device/drivers are available +for the same motor  controller.  The two device/drivers, IM483PL +and IM483SM, correspond to the two available IM483 communication modes, +party line and single mode, respectively (see the IMS Software +Reference Manual for details).
    + 

    +
    +

    Motor Record Version 4.1 Release Notice

    +
    + Although the motor record software in this release is compatible with EPICS +baseR3.13.1.1 and above, the directory structure, the "make" files and the +configuration files are intended for the "unbundled" architecture of EPICS +R3.13.2 and above. +
    +

    Modifications to Existing Features

    +
    + +

    OMS VME58 retry problem

    + Several errors in the OMS VME58 driver were found.  All the errors caused +the same problem.  Namely, erroneous retries occurred intermittently +when multiple axes were commanded to move on the same controller.  This +error occurred because old position data was being passed back from the driver +after Done was detected.  The erroneous intermittent retries occurred +more often when the Oms setup parameters called for a high frequency (e.g., +60 Hz) "polling" rate and OMS board interrupts were enabled. +

    OMS Stop problem

    + A problem with issuing a stop command (via either the STOP or SPMG field) +was found with all OMS boards and all versions of the OMS device +drivers.  The root cause of this problem is a statement in the OMS manual + that is not entirely correct; the AC and VL commands are not +completely queued.
    + 
    +  +
    +

    Motor Record Version 4.0 Release Notice

    +
    + Release 4.0 of the motor record is only compatible with EPICS baseR3.13.1.1 +and above.  This document describes changes made to the motor record +and its' associated device driver support between versions 3.5 and 4.0. +
    +

    Modifications to Existing Features

    +
    + +

    GAIN Field Removed

    + Since the GAIN field is redundant (i.e., PID parameters can be set individually) +it has been removed.
    +  +

    HOM[F/R] Bug Fix

    + Previous releases of the motor record had a potential problem associated +with the homing function.  The motorx_all.adl V1.9 MEDM display sets +the HOM[F/R] fields on and off, corresponding to the user pressing and releasing +the respective home button.  Depending on the pollRate defined +in the st.cmd Setup command and the speed at which the user toggled +the HOM[F/R] buttons; the record level software would turn off the DMOV field +when the HOM[F/R] button was turned off and a motor status update had not +yet been received.  As a result, when the motor completed it's homing +function the command positions (i.e., VAL, DVAL, RVAL) were not updated. +

    All previous motor record releases contained the DMOV problem; the +commanded position update problem was limited to the previous release (V3.5).  +With this release, a dbPutField to either HOMF or HOMR is valid on a FALSE +to TRUE transition (i.e., 0 to 1), but a TRUE to FALSE transition (i.e., 1 +to 0) will result in an error.   motorx_all.adl_V2.2 (which +is included with this distribution) sets the HOM[F/R] fields on when the +user presses the homing button, but is does not set it off when the +button is released.  The motor record clears the HOM[F/R] field when +the homing operation is done (i.e., completed or terminated).
    + 

    +

    Initial Position

    + If both the auto restore and controller target position values are non-zero +at boot-up, then DVAL will be initialized from the controller's value.  +In other words, the controller's target position takes precedence over the +autorestore value when both systems have non-zero DVAL values.  As before, +it is assumed that a zero target position from autorestore or the controller +at boot-up are default values, and hence, they are ignored in favor of a +non-zero value. +

    Previous releases of the motor record allowed the auto restore to +take precedence over the controller when initializing the target position +(i.e., DVAL).
    + 

    +

    Access Security Level

    + In order to support the new VMAX/SMAX fields, the Access Security Level for +the following fields have been changed from one to zero: +
    +
      +
    • MRES
      • +
    • UREV
      • +
    • VBAS
      • +
    • SBAS
      • + +
    +
    + +

    MM4000/5 Device Driver

    + Although the previous motor record release (V3.5) had device driver support +for the MM4000, it is not recommended for use with either the MM4000 +or the MM4005 controllers.  The following changes were made to the previous +release to create, what is now, the MM4000/5 device driver support: +
      +
    1. 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.
      2. + +
        +
      1. 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.
        2. +
      2. Since the MM4005's position cannot be set by EPICS, the initial position +of its' motors (see Initial Position above) will always be initialized from the controller's value.
        3. -
      - -
    2. -The MM4005 supports up to eight axes.  User access to the controller's -front panel is required to scroll the front panel display through all eight -axes.  Since remote mode locks out the user from using the -controller's front panel, the motor record no longer puts the MM4000/5 -in remote mode.  EPICS is unable to communicate with the MM4000/5 -controller if it is in local mode and the front panel is -not at the top menu.   A Controller communication error -bit was allocated in the MSTA field to help aid user's in diagnosing a -controller communication error.  Currently, only the MM4000/5 device -driver sets this error indicator.  When the communication error bit -is set True in the MSTA, the motor record SEVR field is set to INVALID_ALARM -and the STAT field is set to COMM_ALARM.  User's who want their MM4000/5 -in remote mode at boot-up can add the remote mode command ("MR") to  -their INIT field.
      3. -
    - -

    -Bug Fix for OMS VME58 running on PowerPC

    -Through an odd set of circumstances the Oms58 driver was not performing -status updates on PowerPC (PPC) platforms.  All users of the OMS VME58 -controller on a PPC platform must upgrade to Motor Record version 4.0 for -full functionality. -
    -

    -New Features

    -Newport MM3000 Device Support -

    Device driver support for the MM3000 exist for this release of the motor -record.  Note the following differences between the MM4000 and MM3000 -device drivers: -

      -
    • -The MM3000 does not support a generic Load Position commands.  -In other words, the user can only define the current controller position -as being the zero position.  This limitation is reflected in the motor -record device support.  When the SET field is true, the only valid -entry to either the DVAL or RVAL fields is zero.
      • - -
    • -The only position units the MM3000 will communicate with the host in, are -either encoder ticks or stepper motor steps.
      • -
    - -

    -Uninitialized Oms/Oms58 Driver Error Check

    -With previous release, if the Oms or Oms58 driver was some how omitted -from the database, a "... card does not exist" error message would result.  -With this release, an explicit error check and corresponding error message -(i.e., "Oms[58] driver uninitialized.") is issued at record initialization -if a required driver is not initialized. (Because of the particulars of -MM[3000/4000] initialization, this is not an issue with Newport controllers.) -

    -Maximum Velocity Fields (VMAX/SMAX)

    -Maximum velocity fields have been added; VMAX in EGU/s units and SMAX in -RPS units. -

    In order to support BURT, range checking is done in such a way that -any minimum (i.e., VBAS/SBAS) or maximum (i.e., VMAX/SMAX) value entered -is valid.  For example, if the minimum is entered and it exceeds the -maximum, then the maximum is set to the new minimum value.  Slew (VELO/S) -and backup velocity (BVEL/SBAK) fields are forced by the motor record to -be within the range set by VMAX/SMAX and VBAS/SBAS, inclusively.  -For example, if VELO is entered and it is less than the minimum, then VELO -is set to VBAS. -

    To facilitate software upgrades, a zero VMAX disables maximum velocity -error checking.  Those who use both BURT and VMAX (i.e., nonzero VMAX) -should insure that VMAX and VBAS are placed before VELO and BVEL in their -BURT request files.  VMAX/SMAX have Access Security Level zero. -

    motorx_setup_1.7.adl (which is included with this distribution) -includes support for the maximum velocity fields. -
      -

    -

    -Motor Record Version 3.5 Release Notice

    -Release 3.5 of the motor record is only compatible with EPICS baseR3.13.1.1 -and above.  This document describes changes made to the motor record -and its' associated device driver support between versions 3.4 and 3.5.  -Those changes are as follows: -
    -

    -Modifications to Existing Features

    - -

    -Command Primitives

    -This feature is available only with OMS VME8/44/58 or Newport MM4000 -device support (i.e., devOms, devOms58, devMM4000). Three motor record -fields are available to the user to send ASCII command primitives to the -servo control board at fixed, predefined, times.  Each of the following -fields is defined as a character string: -
      1. INIT - Sent at record initialization. -
      2. PREM - Sent before every command string that causes motion. -
      3. POST - Sent after a complete motion is finished or when -an overtravel limit switch is detected.
    -No error checking is done by the motor record or the device driver to insure -that the command strings are valid.  Command primitives that result -in a response from the motion control board are valid, but the response -is not processed. -

    -Servo related Fields

    - -
      -
    • -The GAIN field "prompt" has been changed from "Response Gain" to "Combined -Gain".  In addition, valid values for the GAIN field have been changed -to [0.0, for MM4000 - 0.00005, for OMS] <= GAIN <= 1.  For more + + +
    • The MM4005 supports up to eight axes.  User access to the controller's +front panel is required to scroll the front panel display through all eight +axes.  Since remote mode locks out the user from using the controller's +front panel, the motor record no longer puts the MM4000/5 in remote mode +.  EPICS is unable to communicate with the MM4000/5 controller if it +is in local mode and the front panel is not at the top menu.   +A Controller communication error bit was allocated in the MSTA field +to help aid user's in diagnosing a controller communication error.  +Currently, only the MM4000/5 device driver sets this error indicator.  +When the communication error bit is set True in the MSTA, the motor record +SEVR field is set to INVALID_ALARM and the STAT field is set to COMM_ALARM.  +User's who want their MM4000/5 in remote mode at boot-up can add the remote +mode command ("MR") to  their INIT field.
      • + + + +

      Bug Fix for OMS VME58 running on PowerPC

      + Through an odd set of circumstances the Oms58 driver was not performing status +updates on PowerPC (PPC) platforms.  All users of the OMS VME58 controller +on a PPC platform must upgrade to Motor Record version 4.0 for full functionality. +
      +

      New Features

      +
      + Newport MM3000 Device Support +

      Device driver support for the MM3000 exist for this release of +the motor record.  Note the following differences between the MM4000 +and MM3000 device drivers:

      +
        +
      • The MM3000 does not support a generic Load Position commands.  +In other words, the user can only define the current controller position as +being the zero position.  This limitation is reflected in the motor record +device support.  When the SET field is true, the only valid entry to +either the DVAL or RVAL fields is zero.
        • +
      • The only position units the MM3000 will communicate with the host +in, are either encoder ticks or stepper motor steps.
        • + +
      + +

      Uninitialized Oms/Oms58 Driver Error Check

      + With previous release, if the Oms or Oms58 driver was some how omitted from +the database, a "... card does not exist" error message would result.  +With this release, an explicit error check and corresponding error message +(i.e., "Oms[58] driver uninitialized.") is issued at record initialization +if a required driver is not initialized. (Because of the particulars of MM[3000/4000] +initialization, this is not an issue with Newport controllers.) +

      Maximum Velocity Fields (VMAX/SMAX)

      + Maximum velocity fields have been added; VMAX in EGU/s units and SMAX in +RPS units. +

      In order to support BURT, range checking is done in such a way +that any minimum (i.e., VBAS/SBAS) or maximum (i.e., VMAX/SMAX) value entered +is valid.  For example, if the minimum is entered and it exceeds the +maximum, then the maximum is set to the new minimum value.  Slew (VELO/S) +and backup velocity (BVEL/SBAK) fields are forced by the motor record to be +within the range set by VMAX/SMAX and VBAS/SBAS, inclusively.  For example, +if VELO is entered and it is less than the minimum, then VELO is set to VBAS. +

      +

      To facilitate software upgrades, a zero VMAX disables maximum +velocity error checking.  Those who use both BURT and VMAX (i.e., nonzero +VMAX) should insure that VMAX and VBAS are placed before VELO and BVEL in +their BURT request files.  VMAX/SMAX have Access Security Level +zero.

      +

      motorx_setup_1.7.adl (which is included with this distribution) +includes support for the maximum velocity fields.
      + 

      +
      +

      Motor Record Version 3.5 Release Notice

      +
      + Release 3.5 of the motor record is only compatible with EPICS baseR3.13.1.1 +and above.  This document describes changes made to the motor record +and its' associated device driver support between versions 3.4 and 3.5.  +Those changes are as follows: +
      +

      Modifications to Existing Features

      +
      + +

      Command Primitives

      + This feature is available only with OMS VME8/44/58 or Newport MM4000 device +support (i.e., devOms, devOms58, devMM4000). Three motor record fields +are available to the user to send ASCII command primitives to the servo control +board at fixed, predefined, times.  Each of the following fields is +defined as a character string: +
        1. INIT - Sent at record initialization.
      +  2. PREM - Sent before every command string that causes motion.
      +  3. POST - Sent after a complete motion is finished or when an overtravel +limit switch is detected.
      + No error checking is done by the motor record or the device driver to insure +that the command strings are valid.  Command primitives that result in +a response from the motion control board are valid, but the response is not +processed. +

      Servo related Fields

      + +
        +
      • The GAIN field "prompt" has been changed from "Response Gain" to "Combined +Gain".  In addition, valid values for the GAIN field have been changed +to [0.0, for MM4000 - 0.00005, for OMS] <= GAIN <= 1.  For more on PID, see "PID Gain Parameters" below.
        • - -
      • -The status enable field (i.e., STEN) has been eliminated; the control -enable field (i.e., CNEN) is used to both control the torque enable -and show its' status.
        • -
      - -

      -Unused Fields Removed

      -The following unused motor record fields were deleted: MODE, TRAK, MDEL, -ADEL, CVEL, POSM, ALST, MLST -
        -
        -
      -

      -New Features

      - -

      -Device Directives

      -Device directive definition and processing: -
        -
      • -Valid only in the INIT field.
        • - -
      • -Must be identified by the following;
        • - -
        -
      • -First character of INIT string must be a '@'.
        • - -
      • -One or more characters followed by a terminating '@'; i.e., device directives -must have nonzero length.
        • - -
      • -A valid device directive; currently, only "DPM_ON".
        • -
        - -
      • -INIT strings are stripped of valid device directives (including @'s) and -tested for nonzero length before being sent to the controller.  For -example, given the INIT string, "@DPM_ON@HE", the device directive @DPM_ON@ +
      • The status enable field (i.e., STEN) has been eliminated; the + control enable field (i.e., CNEN) is used to both control +the torque enable and show its' status.
        • + +
      + +

      Unused Fields Removed

      + The following unused motor record fields were deleted: MODE, TRAK, MDEL, +ADEL, CVEL, POSM, ALST, MLST
      + 
      +  +
      +

      New Features

      +
      + +

      Device Directives

      + Device directive definition and processing: +
        +
      • Valid only in the INIT field.
        • +
      • Must be identified by the following;
        • + +
      • First character of INIT string must be a '@'.
        • +
      • One or more characters followed by a terminating '@'; i.e., device +directives must have nonzero length.
        • +
      • A valid device directive; currently, only "DPM_ON".
        • +
        +
      • INIT strings are stripped of valid device directives (including @'s) +and tested for nonzero length before being sent to the controller.  +For example, given the INIT string, "@DPM_ON@HE", the device directive @DPM_ON@ is stripped out before HE is sent to the controller.
        • -
      - -

      -Driver Power Monitoring

      - -
        -
      • -This feature is only available with the OMS VME58 device support.
        • - -
      • -The 8 User I/O signals are assigned to the 8 possible VME58 axes as follows:
        • -
      - -
                        -User I/O #0 <> X axis -
                        -"       " 1 <> Y  " -
                        -..................... -
                        -"       " 7 <> S  " -
      • -Drive-power monitoring defaults to disabled at boot-up.  Request enabling -drive-power monitoring by entering the device directive "@DPM_ON@" command -into the motor record initialization field (i.e., INIT).  The INIT -field is processed at record initialization (i.e., bootup), hence if there -are no errors, drive-power monitoring will be enabled after the next bootup.
        • - -
      • -Whenever a request is made to enable drive-power status monitoring, an -error check is made (using the VME58 "RB" command) to verify that the User -I/O has been configured as an input.  The following message will appear -in the error log if a configuration error is detected; "Invalid VME58 configuration; -RB = 0x####", where "####" is the VME58's response to the RB command.
        • - -
      • -When drive-power status monitoring is enabled and a power failure is detected, -the device driver will respond by activating the the RA_OVERTRAVEL bit -in the MSTA.  This results in either HLS or LLS being activated depending -on the DIR field. In addition, the following message will appear in the -error log; "Drive power failure at VME58 card#?? motor#??".
        • -
      - -

      -Soft Channel Device Support

      -The immediate goals for soft channel motor record device support were twofold.  -First, to solve the problem of nonlinear position conversion in the data -base, rather than in the record.  Second, to provide a more flexible -motor record interface for Table Records and SPEC. -

      New fields have been added to the motor record to support the Soft Channel -device driver.   The new fields are all database links associated -with existing motor record fields.  The new links and their associated -fields are listed in the table below: -
        -
        -

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      LinkLink Type Associated Field
      OUT*DBOUTPUT -
      DVAL
      -
      STOODBOUTPUTSTOP
      DINPDBINPUTDMOV
      RDBL*DBINPUT -
      DRBV
      -
      RINPDBINPUT -
      RMP
      -
      - -
      -

      * - Not a new field, but a new function provided only by soft channel -device support.

      - -

      The Soft Channel database links are only processed when the Soft Channel -device driver is selected.  These links are ignored when using any -other Motor Record device driver.  At this time, the above links are -not -dynamically retargetable. -

      The OUT, DINP and RDBL are monitored for value changes via a CA event -task.  Users must choose either a dial input link (RDBL) or a raw -input link (RINP), but not both. -
        -
        -

      -Newport MM4000 Device Support

      -This is Mark -Rivers MM4000 device support ported to the latest motor record release.  -The following are the functional differences between Mark's version 1.01 -and -
      this release: -
      -
        -
      1. -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.
        2. - -
      2. -Servo support has been extended to the MM4000 controller.
        3. -
      -
      - -

      -PID Gain Parameters

      -With this release there are two ways to set the motor controllers' PID -parameters; either through the Combined Gain field (i.e., GAIN) -or through the individual PID gain parameter fields (i.e., PCOF, ICOF, -DCOF).  Let the motor controller PID parameters be represented by -CKP, CKI and CKD; then the relationship between these two methods is as -follows: -
      For the MM4000       For -all OMS controllers
      - -
        -
      • -CKP  = GAIN                              + +
      + +

      Driver Power Monitoring

      + +
        +
      • This feature is only available with the OMS VME58 device support.
        • +
      • The 8 User I/O signals are assigned to the 8 possible VME58 axes as +follows:
        • + +
      + +
        +                +User I/O #0 <> X axis
        +                +"       " 1 <> Y  "
        +                +.....................
        +                +"       " 7 <> S  "
      • Drive-power +monitoring defaults to disabled at boot-up.  Request enabling drive-power +monitoring by entering the device directive "@DPM_ON@" command into the motor +record initialization field (i.e., INIT).  The INIT field is processed +at record initialization (i.e., bootup), hence if there are no errors, drive-power +monitoring will be enabled after the next bootup.
        • +
      • Whenever a request is made to enable drive-power status monitoring, +an error check is made (using the VME58 "RB" command) to verify that the +User I/O has been configured as an input.  The following message will +appear in the error log if a configuration error is detected; "Invalid VME58 +configuration; RB = 0x####", where "####" is the VME58's response to the +RB command.
        • +
      • When drive-power status monitoring is enabled and a power failure +is detected, the device driver will respond by activating the the RA_OVERTRAVEL +bit in the MSTA.  This results in either HLS or LLS being activated +depending on the DIR field. In addition, the following message will appear +in the error log; "Drive power failure at VME58 card#?? motor#??".
        • + +
      + +

      Soft Channel Device Support

      + The immediate goals for soft channel motor record device support were twofold.  +First, to solve the problem of nonlinear position conversion in the data base, +rather than in the record.  Second, to provide a more flexible motor +record interface for Table Records and SPEC. +

      New fields have been added to the motor record to support +the Soft Channel device driver.   The new fields are all database +links associated with existing motor record fields.  The new links and +their associated fields are listed in the table below:
      + 
      + 

      +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      LinkLink Type Associated Field
      OUT*DBOUTPUT +
      DVAL
      +
      STOODBOUTPUTSTOP
      DINPDBINPUTDMOV
      RDBL*DBINPUT +
      DRBV
      +
      RINPDBINPUT +
      RMP
      +
      +
      + +
      +

      * - Not a new field, but a new function provided only by soft +channel device support.

      +
      + +

      The Soft Channel database links are only processed when the +Soft Channel device driver is selected.  These links are ignored when +using any other Motor Record device driver.  At this time, the above +links are not dynamically retargetable.

      +

      The OUT, DINP and RDBL are monitored for value changes via +a CA event task.  Users must choose either a dial input link (RDBL) +or a raw input link (RINP), but not both.
      + 
      + 

      +

      Newport MM4000 Device Support

      + This is Mark +Rivers MM4000 + device support ported to the latest motor record release.  The following +are the functional differences between Mark's version 1.01 and
      +this release: +
      +
        +
      1. 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.
        2. +
      2. Servo support has been extended to the MM4000 controller.
        3. + +
      +
      + +

      PID Gain Parameters

      + With this release there are two ways to set the motor controllers' PID parameters; +either through the Combined Gain field (i.e., GAIN) or through the +individual PID gain parameter fields (i.e., PCOF, ICOF, DCOF).  Let +the motor controller PID parameters be represented by CKP, CKI and CKD; then +the relationship between these two methods is as follows: +
      For the MM4000       + For all OMS controllers
      + +
        +
      • CKP  = GAIN                              CKP =        1999.9 * GAIN
        • - -
      • -CKI   = 2 * GAIN                        +
      • CKI   = 2 * GAIN                        CKI =  2 * 1999.9 * GAIN
        • - -
      • -CKD = 3 * GAIN                        +
      • CKD = 3 * GAIN                        CKD = 3 * 1999.9 * GAIN
        • -
      -Note that setting any of the individual PID record fields is not -reflected in the value of the GAIN field. -

      -Highland V544 Device Support

      -Device support for the Highland V544 is available with this release.  -This version (i.e., version 1.3) is functionally the same as the earlier -release (i.e., version 1.2).  No new features have been added. -
        -
      -

      -Motor Record Version 3.4 Release Notice

      -This document describes changes made to the motor record and its' associated -device driver support between versions 3.3 and 3.4.  Those changes -are as follows: -

      -Device driver design error fix

      -A design error was discovered in the OMS device drivers (drvOms and drvOms58).  -The EPICS device driver support task (i.e., tmotor) would query the OMS -motion controller for status information immediately after a motion command.  -Since the state of the controller board was in the midst of changing, this -sometimes resulted in inconsistent or conflicting status information being -returned to the motor record.  This problem was remedied by enforcing -a minimum time delay (16.67 ms) between a motion command and a status query. -

      It is difficult to enumerate the symptoms associated with this problem.  -Sometimes they exhibited themselves intermittently, other times bad data -stayed in the record.   Several symptoms are as follows: -

      -
        -
      • -Erroneous motor stops being issued by the device support when changing + +
      + Note that setting any of the individual PID record fields is not reflected +in the value of the GAIN field. +

      Highland V544 Device Support

      + Device support for the Highland V544 is available with this release.  +This version (i.e., version 1.3) is functionally the same as the earlier release +(i.e., version 1.2).  No new features have been added.
      +  +
      +

      Motor Record Version 3.4 Release Notice

      +
      + This document describes changes made to the motor record and its' associated +device driver support between versions 3.3 and 3.4.  Those changes are +as follows: +

      Device driver design error fix

      + A design error was discovered in the OMS device drivers (drvOms and drvOms58).  +The EPICS device driver support task (i.e., tmotor) would query the OMS motion +controller for status information immediately after a motion command.  +Since the state of the controller board was in the midst of changing, this +sometimes resulted in inconsistent or conflicting status information being +returned to the motor record.  This problem was remedied by enforcing +a minimum time delay (16.67 ms) between a motion command and a status query. +

      It is difficult to enumerate the symptoms associated with +this problem.  Sometimes they exhibited themselves intermittently, other +times bad data stayed in the record.   Several symptoms are as +follows:

      +
      +
        +
      • Erroneous motor stops being issued by the device support when changing motor direction.
        • - -
      • -Backlash occurring when the motor is moving in the same direction as the -sign of BDST.
        • - -
      • -DVAL and RBV becoming out-of-synch.  RBV would always be an old value -from the previous move.
        • -
      -
      - -

      -PID Parameter Support for VME58

      -The motor record classifies a motor as a servo if it has two features; -an adjustable closed loop position response gain and the ability to enable/disable -closed loop position control (i.e., motor torque).  A motor lacking -either of the above two features is classified as a stepper and is supported -by the standard motor record features.  The following three motor -record fields support servo motors: -

        1. GAIN - Closed loop position response gain of the motor. -
        2. CNEN - Enable/disable closed loop position control request. -
        3. STEN - Closed loop position control status (i.e., -
           enabled/disabled). -

      Currently, servo support is only available with OMS's VME58 device support -(i.e., VME58-[4S/8S/2S2/2S6/4S4/6S2] model boards).  At driver initialization, -the driver automatically detects whether or not the underlying device supports -the use of the GAIN field and thereby classifies the motor as a stepper -or a servo.   Bit#11 of the MSTA field is set on/off based on -the results of this test.  If the device supports the GAIN field, -then bit#11 of the MSTA is set on and all of the above servo fields are -enabled.   Otherwise, they are disabled and bit#11 of the MSTA -is set off.  When the servo fields are disabled, they can still be -read or written to without an error response. -

      The VME58 device support allows the closed loop position gain of the -motor to be set directly through the GAIN field.  For the VME58, setting -the GAIN field value results in the Combined Coefficient command (i.e., -KK#) being executed with the GAIN field value as the argument to the command.  -This command, in turn, sets the PID loop parameter values (with the OMS -VME58, gain changes do not take effect until the command velocity is zero). -

      The user can request that the closed loop position control be enabled -or disabled by setting the CNEN field nonzero or zero, respectively. -
      Likewise, the user can monitor the state of closed loop position control -(i.e., enabled/disabled) by reading the STEN field.  See the OMS "VME58 -Family User's Manual" for further details. -

      -Command primitives feature

      -Three motor record fields are available to the user that can be used to -send ASCII command primitives to the servo control board at fixed, predefined, -times.  Each field is defined as a character string. -

        1. INIT - Sent at record initialization. -
        2. PREM - Sent before every command string that causes motion. -
        3. POST - Sent after a complete motion is finished. -

      No error checking is done by the motor record or the device driver to -insure that the command strings are valid.  Command primitives that -result in a response from the motion control board are valid, but the response -is not processed. -
        -
        - - +

    • Backlash occurring when the motor is moving in the same direction +as the sign of BDST.
      • +
    • DVAL and RBV becoming out-of-synch.  RBV would always be an old +value from the previous move.
      • + +
    + + +

    PID Parameter Support for VME58

    + The motor record classifies a motor as a servo if it has two features; an +adjustable closed loop position response gain and the ability to enable/disable +closed loop position control (i.e., motor torque).  A motor lacking either +of the above two features is classified as a stepper and is supported by +the standard motor record features.  The following three motor record +fields support servo motors: +

      1. GAIN - Closed loop position response gain +of the motor.
    +  2. CNEN - Enable/disable closed loop position control request.
    +  3. STEN - Closed loop position control status (i.e.,
    +     enabled/disabled).

    +

    Currently, servo support is only available with OMS's +VME58 device support (i.e., VME58-[4S/8S/2S2/2S6/4S4/6S2] model boards).  +At driver initialization, the driver automatically detects whether or not +the underlying device supports the use of the GAIN field and thereby classifies +the motor as a stepper or a servo.   Bit#11 of the MSTA field is +set on/off based on the results of this test.  If the device supports +the GAIN field, then bit#11 of the MSTA is set on and all of the above servo +fields are enabled.   Otherwise, they are disabled and bit#11 of +the MSTA is set off.  When the servo fields are disabled, they can still +be read or written to without an error response.

    +

    The VME58 device support allows the closed loop position +gain of the motor to be set directly through the GAIN field.  For the +VME58, setting the GAIN field value results in the Combined Coefficient command +(i.e., KK#) being executed with the GAIN field value as the argument to the +command.  This command, in turn, sets the PID loop parameter values +(with the OMS VME58, gain changes do not take effect until the command velocity +is zero).

    +

    The user can request that the closed loop position control +be enabled or disabled by setting the CNEN field nonzero or zero, respectively. +
    +Likewise, the user can monitor the state of closed loop position control (i.e., +enabled/disabled) by reading the STEN field.  See the OMS "VME58 Family +User's Manual" for further details.

    +

    Command primitives feature

    + Three motor record fields are available to the user that can be used to send +ASCII command primitives to the servo control board at fixed, predefined, +times.  Each field is defined as a character string. +

      1. INIT - Sent at record initialization.
    +  2. PREM - Sent before every command string that causes motion.
    +  3. POST - Sent after a complete motion is finished.

    +

    No error checking is done by the motor record or the +device driver to insure that the command strings are valid.  Command +primitives that result in a response from the motion control board are valid, +but the response is not processed.
    + 
    + 

    + +