Motor Record and related software

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.

When IGSET = 0, the motor record will obey the SET field and behave as described above.

When IGSET = 1, the motor record will behave as though SET = 0. Ignoring the SET field can useful for applications with soft motors (motors with soft-channel device support).

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.

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. whether absolute or relative position commands are used.

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. 

Note that the ACCS field can be use to specify the acceleration in EGU/s^2.

Velocity and acceleration are related by the following equation:
VELO - VBAS = ACCL * ACCS  

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. 

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. 

(0:"Unity", 1:"Arthmetic", 2:"Geometric", 3:"In-Position")

RMOD allows the user to select different ways of calculating the retry distance move. The default mode (Unity) moves the motor a relative distance based on the dial error (DIFF field). Badly behaved devices (piezo motors) can oscillate around their target position in this mode. Hence, two other modes were added to allow a decreasing response from the motor record after each retry.

The Arithmetic mode generates an arithmetic sequence of corrections. For example, if the max. retry count (RTRY) is 10, then the retries will proceed as follows; DIFF * (1.0), DIFF * (9/10), DIFF * (8/10), etc.

The Geometric mode generates a geometric sequence with a 1/2 common factor of corrections. For example, if the max. retry count is 10, then the retries will proceed as follows; DIFF * (1.0), DIFF * (1/2) DIFF * (1/4), DIFF * (1/8), etc.

The In-Position mode is used only with servos. This mode does not send any motion commands to the controller during a retry. It simply waits for the DIFF field to less than the RDBD field. This mode is intended to be used with nonzero DLY and RTRY fields.

Soft Channel Device Driver

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. 

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. 

1. DIRECTION: last raw direction; (0:Negative, 1:Positive)
2. DONE: motion is complete.
3. PLUS_LS: plus limit switch has been hit.
4. HOMELS: state of the home limit switch.
5. Unused
6. POSITION: closed-loop position control is enabled.
7. SLIP_STALL: Slip/Stall detected (eg. fatal following error)
8. HOME: if at home position.
9. PRESENT: encoder is present.
10. PROBLEM: driver stopped polling, or hardware problem
11. MOVING: non-zero velocity present.
12. GAIN_SUPPORT: motor supports closed-loop position control.
13. COMM_ERR: Controller communication error.
14. MINUS_LS: minus limit switch has been hit.
15. HOMED: the motor has been homed.
    

The record is put into MAJOR STATE alarm if either SLIP_STALL or PROBLEM bits are detected. If HLSV is set, then the record is put into HIGH alarm if either a high soft limit or hard limit (PLUS_LS) has been reached. Similary for the low limits.

• Valid values for STUP are OFF(0), ON(1) and BUSY(2).
• A Channel Access (CA) client writes ON(1) to the STUP field which causes the motor record to set STUP to BUSY(2) and request a single controller status update. After the status is updated the record sets STUP to OFF(0).
• CA clients are restricted to writing ON(1) to STUP only when STUP is OFF(0).
• It is the responsibility of the user to restrict the frequency (and thus the incurred overhead) at which the CA client writes ON(1) to STUP.

With the STUP field it is possible to have another EPICS record periodically write ON(1) to the motor record's STUP field. This would result in continuous, periodic status updates.

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.

Command Primitives

Device Directives

• Valid only in the INIT, PREM and POST fields.
• Must be identified by the following;

First character of a device directive string must be a '@'.

One or more characters followed by a terminating '@'; i.e., device directives must have nonzero length.

Valid device directives:

In the INIT field; only "DPM_ON".

In the PREM field;, only "PUT(pvname, pv-value, delay in seconds)".

In the POST field; only "PUT(pvname, pv-value)".

See Driver Power Monitoring below for the DPM_ON directive.  The PUT directive supports changing the value of a database variable.  Note that the PREM supports a time delay argument before the motor move , but that POST does not.  The Readback settle time field (DLY) should be used to create a time delay after the PV specified in the POST field is written.

• Device directive 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.

• 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 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#??".

medm -x -macro "P=XXX:,M=m1" motorx.adl

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

burtrb -f settings.req -o myMotorSettings.snap

burtrb -f positions.
      req -o myMotorPositions.snap

burtwb -f myMotorSettings.snap

burtwb -f myMotorPositions.snap