These release notes describe changes made to stepper motor related code that was supplied with EPICS Version R3.12.2 SLAC Date: 1996/01/28 01:38:17.
Additionally, support is described for the Allen Bradley 1746-HSTP1 stepper motor controller module. 

The basic modification was to move the implementation of the initialization algorithm (supplied through the IALG field in a stepper motor record) from the record
support code (recSteppermotor.c) to the device or driver support code. This allows the specific device to determine how to move the stepper motor to the
positive or negative limit. Both of the stepper motor drivers standardly supplied with EPICS (drvCompuSm.c and drvOms.c) were modified to accommodate this
change. Other nonstandard stepper motor support codes will need modification to handle the new SM_FIND_LIMIT (defined in steppermotor.h) command (see
the CompuMotor or OMS codes for examples).

In addition, two new algorithms have been added to the list of initialization algorithm choices. These are "Move to Positive Home" and "Move to Negative Home",
which are implemented through the new SM_FIND_HOME command. These were added in accommodation of the new device support for the Allen Bradley
1746-HSTP1 stepper motor controller (devSmAB1746HSTP1.c), which allows the use of a home limit switch in addition to the standard end point limit
switches. Nonstandard device and driver support for stepper motor controllers which do not have this capability should be modified to ignore or complain when
they receive the SM_FIND_HOME command (cf, drvCompuSm.c or drvOms.c).

The new device support code for the Allen Bradley 1746-HSTP1 stepper motor controller requires the EPICS standard issue Allen Bradley driver (drvAb.c).

From the comments at the top of devSmAB1746HSTP1.c [perhaps good for inclusion into the "EPICS: AllenBradley Driver and Device Support" manual?]:

Device support for the 1746-HSTP1 module was written assuming that there are no wiring errors. Consequently, if your apparatus does not agree throughout
itself which direction is clockwise (+) and which direction is counterclockwise (-), unexpected things may happen.

The 1746-HSTP1 device support code was written from the perspective of the Allen Bradley 1746-HSTP1 module. Clockwise (+) is therefore defined to be the
direction in which the stepper motor axis turns when it is viewed from the shaft end of the motor, as per page 4-18 of the 1746-HSTP1 User's Manual (AB Pub
No. 1746-999-121, March 1995).

The 1746-HSTP1 devices have no hardware configuration switches or jumpers to be concerned with. However, "HSTP1 CONFIG OUTPUT WORDs" (Pages
4-4 and A-1 of the User's Manual) must be passed to the device support layer in the parm section of the stepper motor record .OUT field. The string is parsed
with the format string "%hi%hi%i" and is allowed to be a maximum of AB_PARAM_SZ (currently #defined to be 26 in include/link.h) characters long. Use only
whitespace to separate the values. The three values that must be supplied are:

     Hstp1CfgCsr[0] - Configuration word
     Hstp1CfgCsr[1] - Active level word
     Hstp1StartSpd  - Starting speed word (1 - 250000 pulses/sec)

  An example param string is:    0x8413 0x0010 500

Page 4-4 of the User's Manual states that valid configurations require the home limit switch input and one or both of the end (CW or CCW) limit switch inputs to
be enabled, even if the associated switch is not present. 

Due to the way in which the HSTP1 handles limit switch conditions, it is best to avoid them. If a limit switch has been activated, one can either issue a Find Home
command to the HSTP1 to make it hunt for the home switch, or issue single step (Jog) commands to bump the jig off the switch. The jogging procedure is very
slow since it requires a reading the HSTP1 registers to get the current state of the limit switches, a clearing of the HSTP1 command register to make the
appropriate jog bit sensitive to transition and a setting of the appropriate jog bit in the command register. A 25 MHz NI VXIcpu-030 operating with an AB
6008-SV1R scanning module can thus achieve a jog rate of about 3 Hz. If a position request causes the jig to run into one of the switches, the only motion
requests that are accepted by this code are those that move the jig in the direction of getting off of the switch, again, presuming no wiring errors.

One of the rules of writing EPICS device support code is that the process routine must complete as fast as possible since any delays in it cause other records to
be held up. For this reason all commands to this device support layer issued by the record support process routine are queued onto a message queue. The reason
it is done this way rather than processing the commands directly is that there are sometimes delays in getting access to the hard- ware, either the VME scanner, or
the controller itself. Because it is easy to set up a situation in which EPICS sends commands to this code faster than they can be processed, one must handle the
case where the queue fills up. When the queue is full, we break the rules and wait for up to HSTP1_K_EPICSQDLY seconds for previously entered commands
to be taken off the queue in an attempt to throttle EPICS. If the timeout expires, bad status is returned to indicate that the command could not be handled at the
time. Typically, the queue is configured to be deep enough that this situation never arises.

In order to reduce the chance of a knobbed .VAL field from overflowing the command queue, the motor is declared to be moving as soon as a motion request is
recognized, even though it is not necessarily moving yet. This prevents the record support layer from sending out corrections until the motor arrives at the
requested spot. However, there is a problem because if the position request is changed while the motor is still moving, it will be ignored by the record support. To
prevent this, supply a non-zero retry count and an appropriate deadband when setting up your database. Additionally, always put knobs and sliders in "release"
mode rather than in "motion" mode.

The basic scan rate when there are active stepper motors is 1/3 second. When there are no active stepper motors, this code sleeps. Consequently, any manual
motion of the stepper motor axes is not accounted for.

This code can, in principle, handle an arbitrary number of 1746-HSTP1 stepper motor controller modules. However, limitations are provided by memory,
semaphore, and message queue resources, and bus and "blue hose" bandwidths. Note that this code spawns only two tasks, both of which are terminated with
corresponding resources freed if no stepper motor records are found in the system.