diff --git a/.ci/travis-prepare.sh b/.ci/travis-prepare.sh
new file mode 100755
index 0000000..7beb7b4
--- /dev/null
+++ b/.ci/travis-prepare.sh
@@ -0,0 +1,164 @@
+#!/bin/sh
+set -e -x
+
+SUPPORT=$HOME/.cache/support
+
+install -d $SUPPORT
+
+# Conditionally build IPAC
+if [ -n "$IPAC" ]; then
+ IPAC_PATH=$SUPPORT/ipac
+else
+ IPAC_PATH=
+fi
+
+RELEASE_PATH=$TRAVIS_BUILD_DIR/configure/RELEASE
+EPICS_BASE=$SUPPORT/epics-base
+
+cat << EOF > $RELEASE_PATH
+IPAC=$IPAC_PATH
+SNCSEQ=$SUPPORT/seq
+ASYN=$SUPPORT/asyn
+EPICS_BASE=$SUPPORT/epics-base
+EOF
+
+# use default selection for MSI
+sed -i -e '/MSI/d' configure/CONFIG_SITE
+
+if [ ! -e "$EPICS_BASE/built" ]
+then
+
+ git clone --depth 10 --branch $BASE https://github.com/epics-base/epics-base.git $EPICS_BASE
+
+ EPICS_HOST_ARCH=`sh $EPICS_BASE/startup/EpicsHostArch`
+
+ case "$STATIC" in
+ static)
+ cat << EOF >> "$EPICS_BASE/configure/CONFIG_SITE"
+SHARED_LIBRARIES=NO
+STATIC_BUILD=YES
+EOF
+ ;;
+ *) ;;
+ esac
+
+ case "$CMPLR" in
+ clang)
+ echo "Host compiler is clang"
+ cat << EOF >> $EPICS_BASE/configure/os/CONFIG_SITE.Common.$EPICS_HOST_ARCH
+GNU = NO
+CMPLR_CLASS = clang
+CC = clang
+CCC = clang++
+EOF
+ ;;
+ *) echo "Host compiler is default";;
+ esac
+
+ # requires wine and g++-mingw-w64-i686
+ if [ "$WINE" = "32" ]
+ then
+ echo "Cross mingw32"
+ sed -i -e '/CMPLR_PREFIX/d' $EPICS_BASE/configure/os/CONFIG_SITE.linux-x86.win32-x86-mingw
+ cat << EOF >> $EPICS_BASE/configure/os/CONFIG_SITE.linux-x86.win32-x86-mingw
+CMPLR_PREFIX=i686-w64-mingw32-
+EOF
+ cat << EOF >> $EPICS_BASE/configure/CONFIG_SITE
+CROSS_COMPILER_TARGET_ARCHS+=win32-x86-mingw
+EOF
+ fi
+
+ # set RTEMS to eg. "4.9" or "4.10"
+ if [ -n "$RTEMS" ]
+ then
+ echo "Cross RTEMS${RTEMS} for pc386"
+ install -d /home/travis/.cache
+ curl -L "https://github.com/mdavidsaver/rsb/releases/download/travis-20160306-2/rtems${RTEMS}-i386-trusty-20190306-2.tar.gz" \
+ | tar -C /home/travis/.cache -xj
+
+ sed -i -e '/^RTEMS_VERSION/d' -e '/^RTEMS_BASE/d' $EPICS_BASE/configure/os/CONFIG_SITE.Common.RTEMS
+ cat << EOF >> $EPICS_BASE/configure/os/CONFIG_SITE.Common.RTEMS
+RTEMS_VERSION=$RTEMS
+RTEMS_BASE=/home/travis/.cache/rtems${RTEMS}-i386
+EOF
+ cat << EOF >> $EPICS_BASE/configure/CONFIG_SITE
+CROSS_COMPILER_TARGET_ARCHS+=RTEMS-pc386
+EOF
+
+ fi
+
+ make -C "$EPICS_BASE" -j2
+ # get MSI for 3.14
+ case "$BASE" in
+ 3.14*)
+ echo "Build MSI"
+ install -d "$HOME/msi/extensions/src"
+ curl https://epics.anl.gov/download/extensions/extensionsTop_20120904.tar.gz | tar -C "$HOME/msi" -xvz
+ curl https://epics.anl.gov/download/extensions/msi1-7.tar.gz | tar -C "$HOME/msi/extensions/src" -xvz
+ mv "$HOME/msi/extensions/src/msi1-7" "$HOME/msi/extensions/src/msi"
+
+ cat << EOF > "$HOME/msi/extensions/configure/RELEASE"
+EPICS_BASE=$EPICS_BASE
+EPICS_EXTENSIONS=\$(TOP)
+EOF
+ make -C "$HOME/msi/extensions"
+ cp "$HOME/msi/extensions/bin/$EPICS_HOST_ARCH/msi" "$EPICS_BASE/bin/$EPICS_HOST_ARCH/"
+ echo 'MSI:=$(EPICS_BASE)/bin/$(EPICS_HOST_ARCH)/msi' >> "$EPICS_BASE/configure/CONFIG_SITE"
+
+ cat <> configure/CONFIG_SITE
+MSI = \$(EPICS_BASE)/bin/\$(EPICS_HOST_ARCH)/msi
+EOF
+
+ ;;
+ *) echo "Use MSI from Base"
+ ;;
+ esac
+
+ touch $EPICS_BASE/built
+else
+ echo "Using cached epics-base!"
+fi
+
+# IPAC
+if [ -n "$IPAC" ]; then
+ if [ ! -e "$SUPPORT/ipac/built" ]; then
+ echo "Build ipac"
+ install -d $SUPPORT/ipac
+ git clone --depth 10 --branch $IPAC https://github.com/epics-modules/ipac.git $SUPPORT/ipac
+ cat << EOF > $SUPPORT/ipac/configure/RELEASE
+EPICS_BASE=$SUPPORT/epics-base
+EOF
+ make -C $SUPPORT/ipac
+ touch $SUPPORT/ipac/built
+ else
+ echo "Using cached ipac"
+ fi
+else
+ echo "Skipping ipac"
+fi
+
+
+# sequencer
+if [ ! -e "$SUPPORT/seq/built" ]; then
+ echo "Build sequencer"
+ install -d $SUPPORT/seq
+ curl -L "http://www-csr.bessy.de/control/SoftDist/sequencer/releases/seq-${SEQ}.tar.gz" | tar -C $SUPPORT/seq -xvz --strip-components=1
+ cp $RELEASE_PATH $SUPPORT/seq/configure/RELEASE
+ make -C $SUPPORT/seq
+ touch $SUPPORT/seq/built
+else
+ echo "Using cached seq"
+fi
+
+
+# asyn
+if [ ! -e "$SUPPORT/asyn/built" ]; then
+ echo "Build asyn"
+ install -d $SUPPORT/asyn
+ curl -L "https://epics.anl.gov/download/modules/asyn${ASYN}.tar.gz" | tar -C $SUPPORT/asyn -xvz --strip-components=1
+ cp $RELEASE_PATH $SUPPORT/asyn/configure/RELEASE
+ make -C "$SUPPORT/asyn" -j2
+ touch $SUPPORT/asyn/built
+else
+ echo "Using cached asyn"
+fi
diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 0000000..9712a09
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1,5 @@
+#Which files need CRLF handling
+* text=auto
+*.sh eol=lf
+*.bat eol=crlf
+*.cmd -text
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..fae3cab
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,17 @@
+*~
+O.*
+*.swp
+*BAK.adl
+bin/
+db/
+dbd/
+html/
+include/
+lib/
+templates/
+cdCommands
+envPaths
+dllPath.bat
+auto_settings.sav*
+auto_positions.sav*
+.ccfxprepdir/
diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 0000000..0f4036e
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,27 @@
+sudo: false
+dist: trusty
+language: c
+compiler:
+ - gcc
+cache:
+ directories:
+ - $HOME/.cache
+addons:
+ apt:
+ packages:
+ - libreadline6-dev
+ - libncurses5-dev
+ - perl
+ - clang
+ - g++-mingw-w64-i686
+ - re2c
+env:
+ - BASE=3.14 STATIC=shared SEQ=2.2.4 ASYN=4-31 IPAC=2.14
+ - BASE=3.14 STATIC=static SEQ=2.2.4 ASYN=4-31 IPAC=2.14
+ - BASE=R3.15.5 STATIC=shared SEQ=2.2.4 ASYN=4-31 IPAC=2.14
+ - BASE=R3.15.5 STATIC=static SEQ=2.2.4 ASYN=4-31 IPAC=2.14
+ - BASE=3.16 STATIC=shared RTEMS=4.10 SEQ=2.2.4 ASYN=4-31 IPAC=2.14
+ - BASE=3.16 STATIC=shared CMPLR=clang WINE=32 SEQ=2.2.4 ASYN=4-31 IPAC=
+ - BASE=3.16 STATIC=static WINE=32 SEQ=2.2.4 ASYN=4-31 IPAC=
+install: ./.ci/travis-prepare.sh
+script: make
diff --git a/README b/README
index 10defa7..10ca6a5 100644
--- a/README
+++ b/README
@@ -1,4 +1,13 @@
-Motor Module R6-9 Release Notes
+Notice
+======
+
+This file was historically used to document changes to the motor module that
+were relevant to developers. It is largely obsolete now that the motor module
+has moved github. It will not be updated in the future and is likely to move
+to the documentation directory.
+
+
+Motor Module R6-10 Release Notes
===============================================================================
The motor module software in this release is compatible with EPICS base
@@ -144,6 +153,74 @@ Known Problems
- Tapping the Jog button can cause the motor to move past the
soft-travel limit when backlash is nonzero.
+Modification Log for R6-10
+==========================
+
+2) Fix for OMS controllers that do not have the correct deceleration rate at
+ the end of a JOG. Bug introduced with item #9 under R6-6.
+
+ File modified: OmsSrc/devOmsCom.cc
+
+3) - If the user request UEIP be set true and the MSTA's EA_PRESENT indicator
+ is off, then special() denies the request and sets UEIP false. In other
+ words, UEIP can only be set true if the device/driver has set the
+ "Encoder is Present" MSTA indicator true. Replaced six occurrences of
+ logic that tested both UEIP and EA_PRESENT with just UEIP.
+
+ - UEIP and URIP are mutually exclusive. For example, if the user request
+ UEIP be set true when URIP is also true, then the special() function
+ will set URIP off and vice versa. Added the special attribute to URIP.
+
+ - If URIP is true and the RDBL link points to a valid DBR_DOUBLE, then the
+ value pointed to by RDBL will be multiplied by RRES, divided by MRES
+ and stored in RRBV. This fixes a problem with all previous releases
+ where RRBV was inconsistent with DRBV when URIP was true.
+
+ Files modified: motorApp/MotorSrc/motorRecord.cc
+ motorApp/MotorSrc/motorRecord.dbd
+
+4) Fix for build errors when SNCSEQ isn't defined in the RELEASE file.
+
+ Files added: motorApp/AerotechSrc/devAerotechSeq.dbd
+ motorApp/NewportSrc/devNewportSeq.dbd
+ Files modified: motorApp/AerotechSrc/Makefile
+ motorApp/AerotechSrc/devAerotech.dbd
+ motorApp/NewportSrc/Makefile
+ motorApp/NewportSrc/devNewport.dbd
+
+5) Márcio Paduan Donadio (LNLS) fixed a bug with SYNC field processing. SYNC
+ was being ignored when URIP == True.
+
+ Files modified: syncTargetPosition() in motorRecord.cc
+
+6) Kevin Peterson discovered an initialization bug when the motor record is
+ configured to do retries. When configured to do retries, the motor
+ record issues incremental rather than absolute moves. If the motor
+ behaves badly (e.g., a piezo stiction motor) the controller's absolute
+ step count can be far from its' absolute readback position. The motor
+ record initialization logic that determines how the target positions
+ are initialized at boot-up was not taking into consideration whether
+ or not the motor record is configured to do retries, and therefore,
+ whether or not absolute or incremental moves were issued by the motor
+ record. With this release, if the motor record is configured to do
+ retries, then the controller's absolute position is ignored (because
+ the controller's absolute position was "corrupted" by retries) and the
+ autosave/restore position is used to set the controllers position.
+
+ Switching between retries on and off (relative vs. absolute moves)
+ between reboots will cause unpredictable results and is not covered
+ by this bug fix.
+
+ Files modified: motor_init_record_com() in MotorSrc/motordevCom.cc
+ init_controller() in MotorSrc/devMotorAsyn.c
+
+7) The MAXv User's Manual specifies that "The IRQ interrupt level range is
+ 0x010-0x111 (IRQ2-7)...". The appropriate error check has been added to
+ the MAXvSetup() call.
+
+ File modified: OmsSrc/drvMAXv.cc
+
+
Modification Log for R6-9
=========================
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..793e787
--- /dev/null
+++ b/README.md
@@ -0,0 +1,17 @@
+# motor
+APS BCDA synApps module: motor
+
+[![Build Status](https://travis-ci.org/epics-modules/motor.png)](https://travis-ci.org/epics-modules/motor)
+
+**Note**: Current discussion on future of the *motor* module repository: https://github.com/epics-modules/motor/issues/55
+
+For more information, see:
+* [main page](https://epics-modules.github.io/motor)
+* [motor wiki](https://github.com/epics-modules/motor/wiki)
+* http://www.aps.anl.gov/bcda/synApps
+* [HTML documentation](https://github.com/epics-modules/motor/blob/master/docs/README.md)
+
+[Report an issue with Motor](https://github.com/epics-modules/motor/issues/new?title=%20ISSUE%20NAME%20HERE&body=**Describe%20the%20issue**%0A%0A**Steps%20to%20reproduce**%0A1.%20Step%20one%0A2.%20Step%20two%0A3.%20Step%20three%0A%0A**Expected%20behaivour**%0A%0A**Actual%20behaviour**%0A%0A**Build%20Environment**%0AArchitecture:%0AEpics%20Base%20Version:%0ADependent%20Module%20Versions:&labels=bug)
+[Request a feature](https://github.com/epics-modules/motor/issues/new?title=%20FEATURE%20SHORT%20DESCRIPTION&body=**Feature%20Long%20Description**%0A%0A**Why%20should%20this%20be%20added?**%0A&labels=enhancement)
+
+converted from APS SVN repository: Fri Oct 16 12:31:41 CDT 2015
diff --git a/configure/RELEASE b/configure/RELEASE
index 6c1a60a..56f99a3 100644
--- a/configure/RELEASE
+++ b/configure/RELEASE
@@ -17,7 +17,7 @@ SUPPORT=
# Recommended ASYN release: R4-23
ASYN=$(SUPPORT)/asyn/R4-23
-# Need the sequencer and the bust record for the MM4005 and XPS trajectory scanning
+# Need the sequencer and the busy record for the MM4005 and XPS trajectory scanning
# Recommended SNCSEQ release: R2.1.16
SNCSEQ=$(SUPPORT)/seq/seq-2-1-16
# Recommended BUSY release: R1-6
@@ -37,6 +37,9 @@ EPICS_BASE=
# Recommended IPAC release: R2-12
IPAC=$(SUPPORT)/ipac/R2-12
+# Script module needed to build ScriptMotorController
+#!LUA=$(SUPPORT)/lua
+
# The following is only needed for the motor examples in iocBoot.
#!MOTOR=$(TOP)
diff --git a/documentation/Doxyfile b/docs/Doxyfile
similarity index 99%
rename from documentation/Doxyfile
rename to docs/Doxyfile
index e3f527a..e0f8a64 100755
--- a/documentation/Doxyfile
+++ b/docs/Doxyfile
@@ -586,6 +586,10 @@ INPUT = ../../asyn/asyn/miscellaneous/asynPortDriver.cpp \
../motorApp/NewportSrc/XPSController.h \
../motorApp/NewportSrc/XPSController.cpp \
../motorApp/NewportSrc/XPSAxis.h \
+ ../motorApp/NewportSrc/AG_CONEX.cpp \
+ ../motorApp/NewportSrc/AG_CONEX.h \
+ ../motorApp/NewportSrc/AG_UC.cpp \
+ ../motorApp/NewportSrc/AG_UC.h \
../motorApp/NewportSrc/XPSAxis.cpp \
../motorApp/MotorSimSrc/motorSimDriver.h \
../motorApp/MotorSimSrc/motorSimDriver.cpp
diff --git a/documentation/EnsemblePSOFly.txt b/docs/EnsemblePSOFly.txt
similarity index 100%
rename from documentation/EnsemblePSOFly.txt
rename to docs/EnsemblePSOFly.txt
diff --git a/documentation/Makefile b/docs/Makefile
similarity index 100%
rename from documentation/Makefile
rename to docs/Makefile
diff --git a/docs/Problems.html b/docs/Problems.html
new file mode 100644
index 0000000..f4393c0
--- /dev/null
+++ b/docs/Problems.html
@@ -0,0 +1,1060 @@
+
+
+
+
+
+ Motor Module Known Problems
+
+
+
+Motor Module: Known problems
+
+Known problems with Release 6-10 and later
+
+See issues on github: https://github.com/epics-modules/motor/issues
+
+Known problems with Release 6-9
+
+
+Known problems with Release 6-8
+
+
+ -
+
+ Soft-travel Limits
+
+
+
+ -
+ Although there are a number of improvements with R6-8's support of soft-travel
+ limits (LVIO), there are also two problems that will remain "Known Problems".
+ These limitation are as follows:
+
+
+ -
+ Tweaking (TWF/TWR) very small increments with UEIP = Yes while in the invalid
+ range of the soft-travel limits may put the motor record in a state where the
+ user cannot tweak in either direction. The solution is to either jog the motor
+ towards the valid range or increase the tweak increment value (TWV field).
+
+ -
+ Tapping the Jog button can cause the motor to move past the soft-travel limit
+ when backlash is nonzero.
+
+
+
+
+
+
+
+ Newport ESP100/300/301
+
+
+ The R6.8 ESP support changes made to "Use MRES rather than controller resolution
+ to do EGUtoRAWbacktoEGU conversion." do not work. (Model 1 drivers do not always
+ have access to motor record data.) The most obvious problem with R6.8 ESP
+ support is the inability to "set" the controller's position.
+
+
+ This
+ patch file rolls back the R6.8 ESP changes and adds one bug fix to
+ the EPS100/300/301 driver; when a controller error occurs, the driver prints the
+ error code to the console and sets the RA_PROBLEM bit of the MSTA field. The
+ motor record patch unconditionally sends a "stop motor" command whenever a
+ driver sets the RA_PROBLEM bit. Finally, the patch file updates ESP info in the
+ README file.
+
+
+ R6-8-1 includes both the MRES related rollback and the STOP on RA_PROBLEM bug fix.
+
+
+
+
+Known problems with Release 6-7
+
+
+ -
+
+ Aerotech Ensemble
+
+
+
+ -
+ Due to network broadcasting upgrades to Aerotech Ensemble Motion Composer,
+ starting with motor module R6-7-1, the EPICS Ensemble driver only supports
+ 4.01.002 Ensemble version firmware 4.01.002 and above.
+
+ -
+ The home search from EPICS command was been restored with R6-7-1. In order for
+ an EPICS home search command to work, the Aerotech Ensemble example program, HomeAsync.abx,
+ must be compiled and stored in the Ensemble. In addition, the Parameters>System>TaskExecutionSetup
+ parameter must be set to enable Auxiliary Task execution.
+
+
+
+
+
+
+
-
+
+ Schneider Electric (formally IMS) MDrive
+
+
+ Joe Sullivan fixed several bugs in the Schneider Electric MDrive driver
+ associated with input buffer overflows that arose with newer MDrive firmware (e.g.,
+ 3.003). These bug fixes were 1st released with motor module R6-7-1.
+
+
+
+
+
+
+Known problems with Release 6-5
+
+
+ -
+
+ Aerotech Ensemble
+
+
+
+ -
+ With previous releases the Aerotech Ensemble asyn motor driver would crash the
+ IOC at boot-up if the Ensemble was not powered up and able to communicate. Fixed
+ with R6-5-1.
+
+ -
+ The EOT limit switch status was not available except via an Ensemble fault
+ condition. With release R6-5-1 the status of the EOT limit switches are always
+ available.
+
+
+
+
+
+
+
-
+
+ OMS MAXv WatchDog Timeout Counter
+
+
+ Beginning with R6-5-1 and OMS MAXv firmware ver:1.33, the EPICS MAXv driver reads
+ the MAXv's Watchdog Timeout Counter at bootup, and with every motor status
+ update. If the Counter is nonzero, an error message is sent to both the errlog
+ task and the console. Since a watchdog timer trip indicates that the MAXv has
+ rebooted and no longer has valid motor positions, the driver disables the
+ controller. That specific controller is no longer available to EPICS until after
+ the VME crate has been power cycled. Other MAXv boards in the system are
+ unaffected by this scenario.
+
+
+ To better communicate this problem to the user, several medm displays have been
+ changed. Small displays (motorx_tiny.adl, motorx.adl) will show a yellow border
+ around their position readback values. Larger displays (motorx_more.adl,
+ motorx_all.adl) will display the message "Controller Error" in yellow. The
+ following error message at the console and/or in the errlog is definitive;
+
+
+
+ ***MAXv card #(card#) Disabled*** Watchdog Timeout CTR =(count)
+
+
+
+
+
+ -
+
+ spec upgrade required
+
+
+ The RES field was removed from the motor record with R6-5. Since earlier
+ versions of Certified Scientific Software's spec used the RES field, an upgrade
+ to spec version 5.8.06-6 or above is required for spec to work with motor record
+ R6-5 and above. The problem of using earlier versions of spec with motor record
+ R6-5 exhibits itself by spec setting the "responsive" parameter to zero and not
+ allowing any motor motion.
+
+
+
+ -
+
+ VxWorks 6.x compiler error
+
+
+ The GNU preprocessor assertions in motor.h are deprecated with the VxWorks 6.x
+ compiler. Test for CPU macros that are compatible with VxWorks 6.x have been
+ added. This change prevents an "Error: unknown bit order!" compiler error with
+ VxWorks 6.x. This problem is fixed with R6-5-2 and above. Alternatively, you can
+ replace <motor>/motorApp/MotorSrc/motor.h with the following copy: motor.h
+
+
+
+ -
+
+ Aerotech Ensemble Home Search
+
+
+ The EPICS Ensemble driver uses Aerotech's ASCII communication protocol. That
+ protocol blocks all communication on the ASCII comm. port during a home search.
+ Consequently, once a home search is started from EPICS, it is unable to stop it.
+ As a result, beginning with R6-5-2, the home search command has been commented
+ out of the EPICS driver until an Ensemble firmware update resolves this problem.
+
+
+
+
+
+Known problems with Release 6-4
+
+
+ -
+ R6-4 had 64-bit compile problems with the PI E816 and Aerotech Ensemble device
+ drivers. Fixed with R6-4-1 and above.
+
+
+
-
+ Dirk Zimoch (PSI) discovered and fixed a bug in the orginial OMS MAXv driver (R5-4)
+ that caused the home switch status in the response string to be overwritten.
+ Fixed with R6-4-2 and above.
+
+
+
+
-
+ A problem was introduced in R6-4 of the old motor record device drive
+ architecture. If during the move of one or more motors the motor task did not
+ issue an OS delay during status updates, it could potentially not respond to any
+ further motor commands. Fixed with R6-4-2 and above.
+
+
+
-
+ There is a bug in these motor record versions (R6-4, R6-4-1, R6-4-2)
+ that affects motors that have encoders and are configured to do closed-loop
+ control via retries (i.e. UEIP=Yes and RTRY != 0). Retries are not done
+ correctly and occasionally motors exceed their maximum retries and are left at
+ their backlash position; i.e., command position - backlash distance. See the
+ Release Notice for further error conditions. Fixed with R6-4-3 and above.
+
+
+
-
+ The asynMotor device support in general, and the simulated motor, in particular,
+ had save/restore related problems. Fixed with R6-4-4 and above.
+
+
+
-
+ Previous releases of the Aerotech Ensemble device driver had incorrect Jog
+ speeds, lacked support for a negative PosScaleFactor parameter and did not
+ detect maximum travel limit switch faults correctly. Fixed with R6-4-4 and above.
+
+
+
+
+Known problems with Release 6-3
+
+
+ -
+ The OMS VME58 "stale data" problem is caused by the driver communicating via the
+ ASCII commands while the DPRAM was updating. The OMS VME58 driver was modified
+ with R6-3 to eliminate this contention and the "stale data delay" was set to
+ zero. Since then a problem with OMS VME58 2.24-8S version firmware and all 2.35
+ firmware versions has arisen. When the user sets the motor record's position,
+ the previous target and readback positions are read from the controller on the
+ next update.
+
+ With releases after R6-3 (e.g., R6-3-1 and R6-4) the driver searches all VME58
+ board ID's for either 2.24-8S or any 2.35 version. If any board is found, the "stale
+ data delay" is set to a non-zero value.
+
+
+
-
+ A problem was reported by Emma Shepherd (Diamond) with R6-3 if the "Use RDBL
+ Link" field (URIP) was set to "Yes". The NTM logic was sending stop commands
+ and issuing the "tdir=.." message to the console if the RDBL link was used. This
+ error was the result of changing the NTM logic as described in item #11 under R6-3
+ modifications.
+
+ With releases after R6-3 (e.g., R6-3-1 and R6-4), the NTM logic is restored to
+ using feedback rather than reference positions. In addition, with release R6-4
+ and after, an "NTM deadband factor" field (NTMF) is added to allow the user to
+ set the NTM deadband; NTM deadband = NTMF * (|BDST| + RDBD) NTMF must be >= 2.
+ If properly configured, the NTM deadband prevents NTM logic from issuing a STOP
+ command at the end of a DC motor move that overshoots its' target position.
+
+
+
-
+ The asyn motor device driver architecture does not support the motor record
+ GET_INFO command. Hence, operations that require a status update (i.e., setting
+ the position) were not working. This is fixed in R6-4.
+
+
+
-
+ In the process of fixing the OMS VME58 "stale data" problem described above,
+ needless delays were added to the code that updated the VME58's DPRAM. These
+ needless delays can be calculated as follows;
+
+ delay = (n-1) * (1/sysClkRate)
+
+ where, n = # of VME58 boards in the IOC.
+ sysClkRate = 60 Hz, unless changed by a sysClkRateSet() from st.cmd.
+
+ These delays are eliminated with R6-4-2 and above.
+
+
+
+
+Known problems with Release 6-2
+
+
+
+ -
+ Link errors occurred when building "XPSGatheringMain" for the solaris-sparc-gnu
+ target. Newport users should upgrade to R6-2-1.
+
+
+
-
+ Errors occurred in various motorApp's when building for the solaris-sparc (SUNWspro)
+ target. SUNWspro users should upgrade to R6-2-1.
+
+
+
-
+ Mark River's found and fixed a bug in the motor record. RDBD was being used in
+ motor record initialization before the RDBD validation check. This resulted in
+ motor positions not being initialized from save/restore at boot-up if RDBD was
+ not included in a save/restore save set. This is fixed in R6-2-2.
+
+
+
-
+ A bug was introduced into the shell command motorUtilInit affecting these
+ versions of the motor distribution; R6-2, R6-2-1 and R6-2-2. This bug resulted
+ in the erroneous error message; "motorUtilInit: Prefix %c: has more than 53
+ characters. Exiting". Replace <motor>/motorApp/MotorSrc/motorUtil.cc with
+ the following copy: motorUtil.cc
+
+
+
-
+ The "alldone" PV in motorUtil.db defaulted to the "moving" state between "iocInit
+ " and "motorUtilInit", giving the false indication that motors were moving
+ during boot-up. The "alldone" PV now defaults to the "done" state. Replace <motor>/motorApp/Db/motorUtil.db
+ with the following copy: motorUtil.db
+
+
+
+
+Known problems with Release 6-1
+
+
+ -
+ The Newport PM500 driver was not issuing the correct command when it queried for
+ the number of axes at boot up. This resulted in a "PM500 system error" message
+ on the 1st axis; fixed in R6-2.
+
+ -
+ A bug was introduced with R6-0; the OMS device support was overwriting PID
+ parameter fields during its' normalization calculation; fixed in R6-2.
+
+ -
+ There was a bug in the logic that determines the precedence between using the
+ controller's or save/restore's motor position at boot-up. Negative controller
+ positions were not handled correctly; fixed in R6-2
+
+ -
+ The home request (HOMF/HOMR) were not cleared when a soft-limit violation
+ occurred; fixed in R6-2.
+
+ -
+ Due to releasing R6-1 during Newport development, R6-1 can result in linker
+ errors on the symbol "xpsgathering". Newport users should upgrade to R6-2.
+
+
+
+Known problems with Release 6-0
+
+
+ -
+ The R6-0-bugfix CVS repository branch has become corrupted. Hence, no further
+ changes will be made (i.e., bug fixes) to the R6-0 branch.
+
+ -
+ A bug was introduced with this release. The OMS device support overwrites PID
+ parameter fields during its' normalization calculation. This is fixed in R6-2.
+
+
+
+Known problems with Release 5-9
+
+
+ -
+ An undocumented change was made in R5-4 to two OMS setup functions. Namely, the
+ unused 2nd argument ("axes per card") was eliminated from omsSetup() and
+ oms58Setup().
+
+
+ -
+ Since R4-5 the motor record has required that RDBD be >= MRES. The test for
+ this condition was done using floating point values. This caused an occasional
+ error that resulted in the record not always issuing a motor move command when
+ RDBD = MRES and the user issued an incremental move request equal to MRES. This
+ is fixed with R5-9-1 and R6-0.
+
+
+ -
+ A warning message was added with R5-6 when a user attempted to move an OMS motor
+ with an invalid velocity (slew <= base). Applications that manipulate the
+ velocity values are unaware of this restriction and create a torrent of
+ these messages. With release R5-9-1 and R6-0 the OMS device driver will
+ only output this warning message once.
+
+
+ -
+ Added a work around for OMS PC68/78 firmware error. PC68/78 controllers make an
+ erroneous response after they are queried with the "?KP" command at boot-up.
+ This resulted in 1st axis having same position (RP command) as last the axis.
+ This is fixed with R5-9-1 and R6-0.
+
+
+ -
+ GPIB under ASYN allows only one input EOS character; no output EOS is allowed.
+ Adjustments were made to the Newport ESP300 driver to accomodate this
+ restriction with R5-9-1 and R6-0.
+
+
+ -
+ The CVS repository has become out of synch with the R5-9-1 tar file (motorR5-9-1.tar.gz).
+ Hence, no further changes will be made (i.e., bug fixes) to the R5-9 branch.
+
+
+
+Known problems with Release 5-8
+
+Known problems with Release 5-7
+
+Known problems with Release 5-6
+
+Known problems with Release 5-5
+
+Known problems with Release 5-4
+
+
+ -
+ An undocumented change was made to two OMS setup functions. Namely, the unused
+ 2nd argument ("axes per card") was eliminated from omsSetup() and oms58Setup()
+ in R5-4.
+
+
+
+Known problems with Release 5-3
+
+
+ -
+ "sorry, not implemented: `tree_list' not supported by dump_type" error when
+ compiling drvOms.cc and drvOms58.cc under Tornado 2.2. The Tornado 2.2 compiler
+ (i.e., 2.96) creates errors in devLib.h. The root cause of this "bug" is a
+ problem with the gcc-2.96 compiler bundled with Tornado 2.2. Unfortunately, to
+ date, Wind River is only helping with workarounds; not fixing the compiler. Hence,
+ the following patches are required.
+
+
+ -
+ For R3.14.4-5, replace <base>src/libCom/osi/devLib.h with the following
+ copy: devLib.h
+
+ -
+ Edit <motor>/motorApp/OmsSrc/drvOms.cc by uncommenting the lines with the Tornado
+ 2.2 comment and commenting out the line with the Tornado 2.0.2
+ comment.
+
+ -
+ Edit <motor>/motorApp/OmsSrc/drvOms58.cc by uncommenting the lines with
+ the Tornado 2.2 comment and commenting out the line with the Tornado
+ 2.0.2 comment.
+
+
+
+
+Known problems with Release 5-2
+
+
+ -
+ "sorry, not implemented: `tree_list' not supported by dump_type" error when
+ compiling drvOms.cc and drvOms58.cc under Tornado 2.2. The Tornado 2.2 compiler
+ (i.e., 2.96) creates errors in devLib.h. The root cause of this "bug" is a
+ problem with the gcc-2.96 compiler bundled with Tornado 2.2. Unfortunately, to
+ date, Wind River is only helping with workarounds; not fixing the compiler. Hence,
+ the following patches are required.
+
+
+ -
+ For R3.14.4-5, replace <base>src/libCom/osi/devLib.h with the following
+ copy: devLib.h
+
+ -
+ Replace <motor>/motorApp/OmsSrc/drvOms.cc with the following
+ updated copy: drvOms.cc
+
+ -
+ Replace <motor>/motorApp/OmsSrc/drvOms58.cc with the following
+ updated copy: drvOms58.cc
+
+
+
+
+Known problems with Release 4-9
+
+
+ -
+ PID parameters (i.e., PCOF, ICOF and DCOF fields) were not initialized at boot-up.
+ With R4.9.1, if the GAIN_SUPPORT bit in the MSTA is true, each nonzero,
+ PID parameter will be initialized. For backwards compatibility, zero valued PID
+ parameters will not be initialized.
+
+
+ -
+ Previous releases of the IMS MDrive device driver did not work. Thanks to Kevin
+ M. Peterson (UNI-CAT) for identifying and fixing the errors in previous releases.
+
+
+ -
+ Fixed with R4-9-2.
+
+
+
+ -
+ Two bugs were found and fixed with the Newport MM3000 device support. First,
+ the enable/disable torque control field (CNEN) was not working. Second, an
+ error was introduced into the Newport MM3000 device driver with R4-8; the driver
+ was confusing valid responses with the "system error" response from the
+ controller
+
+
+ -
+ Fixed with R4-9-3.
+
+
+
+ -
+ A retry on initial communication with the Physik Instrumente (PI) C-844 motor
+ controller was added. The controller was intermittently not responding after an
+ IOC power-cycle.
+
+
+ -
+ Fixed with R4-9-4.
+
+
+
+ -
+ Modifications were made to the motor record in order to allow a user to
+ configure it for periodic status updates using the SCAN field.
+
+
+ -
+ Available with R4-9-4.
+
+
+
+ -
+ The motor record would get into an invalid state when it attempted to perform a
+ backlash correction move in the direction of an activated limit switch.
+
+
+ -
+ Fixed with R4-9-5.
+
+
+
+ -
+ Bug fix for home request re-activating after a limit switch error is cleared.
+ This release clears the homing and jog request after a LS or travel limit error.
+ Updated the motorx_all.adl MEDM screen (V2.5) to show the state of the jog
+ request.
+
+
+ -
+ Fixed with R4-9-5.
+
+
+
+ -
+ A bug was reported by David Maden (PSI) that occurred when a motor was jogged
+ into a limit switch with the DIR field set to "Neg". Under these conditions, the
+ motor record was not processing the limit error condition correctly. This
+ resulted in the motor record not setting either of the limit error indicator
+ fields (HLS/LLS) and becoming stuck in the "Moving" state.
+
+
+ -
+ Fixed with R4-9-6.
+
+
+
+ -
+ Kevin Peterson (UNI-CAT) and I diagnosed a bug that is in all R3.13 versions of
+ the motor record distribution. The bug is in the interface between motor record
+ GPIB capable drivers (i.e., Newport MM4000/5/6, MM3000, PM500, ESP300/100) and
+ the EPICS base GPIB driver; drvGpib.
+ Dynamic memory is allocated and shared with drvGpib by the motor task. The
+ problem arises here, at the end of ibLinkTask in drvGpib.c;
+
+ plink->deviceStatus[pnode->device] = (*(pnode->workStart))(pnode);
+
+ pnode->workStart is a pointer to gpibIOCallback() in gpibIO.c. When
+ gpibIOCallback() is done processing it "gives" a semaphore that is "taken" by
+ either gpibIOSend() and gpibIORecv(). Both gpibIOSend() and gpibIORecv()
+ immediately free the shared memory.
+
+ This works almost all the time; but occasionally the memory is taken by some
+ other task and trashed before the line above is executed resulting in a bus
+ error on "pnode->device".
+
+ As a quick fix, the task priorities of the all GPIB capable controllers has been
+ lowered below ibLinkTasks priority. This allows ibLinkTask to finish processing
+ and be waiting for the next GPIB request before the shared memory is de-allocated.
+
+
+ All users of the R3.13.x version of the motor record distribution that use GPIB
+ to communicate to Newport controllers (i.e., Newport MM4000/5/6, MM3000, PM500,
+ ESP300/100), should upgrade to the R4-9-6 release.
+
+
+ -
+ Fixed with R4-9-6.
+
+
+
+
+Known problems with Release 4-8
+
+
+ -
+ Previous releases of the IMS MDrive device driver did not work. Thanks to Kevin
+ M. Peterson (UNI-CAT) for identifying and fixing the errors in previous releases.
+
+
+ -
+ Fixed with R4-9-1.
+
+
+ -
+ Users of the status update field (STUP) should use a later release.
+
+
+ -
+ Fixed with R4-9 and above.
+
+
+ -
+ Two bugs were found and fixed with the Newport MM3000 device support. First,
+ the enable/disable torque control field (CNEN) was not working. Second, an
+ error was introduced into the Newport MM3000 device driver with R4-8; the driver
+ was confusing valid responses with the "system error" response from the
+ controller
+
+
+ -
+ Fixed with R4-8-1 and above.
+
+
+
+
+Known problems with Release 4-7
+
+
+ -
+ With release R4-5, DBE_LOG was omitted from the event select mask of all
+ db_post_events() calls. This prevented archival clients from being
+ notified of process variable changes.
+
+
+ -
+ Fixed with R4-7-1.
+
+
+ -
+ Communication with the Newport MM3000 motor controller was getting out of
+ synchronization whenever the MM3000 responded with an error message. This
+ problem was resolved by having recv_mess() in drvMM3000.c detect an error
+ message response, print the error message and then, recursively, call itself.
+ This restored communication transmit/receive synchronization.
+
+
+ -
+ Fixed with R4-7-2.
+
+
+ -
+ With release R4-7, there was a slight (undocumented) modification made to the
+ way that backlash correction functioned. If a move is in the preferred direction
+ and the backlash speed and acceleration are the same as the slew speed and
+ acceleration, then the backlash move is skipped and the motor moves directly to
+ the target position. Unfortunately, there was a bug in the logic that appeared
+ only when MRES< 0. When MRES < 0, and the backlash speed and acceleration were
+ the same as the slew speed and acceleration, the motor record did the opposite
+ of the requirements; i.e., it did backlash correction when the move was in the
+ preferred direction and did not do backlash correction when the move was not in
+ the preferred direction.
+
+
+ -
+ Fixed with R4-7-2.
+
+
+ -
+ The Newport ESP300 would randomly crash at boot-up because an internal parameter
+ ("drive_resolution") was not always, under all configurations, initialized. With
+ this release, the "drive_resolution" is set based on the response to the ESP300
+ "SU?" command. In addition, the user is required to set MRES to the resolution
+ of the controller as explained in the new document /motorApp/NewportSrc/README.
+
+
+ -
+ Fixed with R4-7-2.
+
+
+ -
+ A bug was introduced in R4-6 while fixing another bug; see item#2 under
+ Modification Log from R4-5 to R4-6 in the distribution README file. This error
+ exhibited itself only under the following conditions; BDST != 0, DLY != 0 and a
+ new target position is issued before the backlash correction move. Under these
+ conditions the motor record became unresponsive; i.e., it locked up.
+
+
+ -
+ Fixed with R4-7-3.
+
+
+ -
+ Although there is no explicit statement in the motor record documentation, most
+ user's would expect the "Readback settle time" field (DLY) to update the
+ readback after the delay timeout. It did not do this. With this release, the
+ readback is updated one time after the timeout.
+
+
+ -
+ Fixed with R4-7-3.
+
+
+ -
+ There were problems with the tweak function (TWF/TWR) when the TWV was set to
+ less than MRES. Under this condition, the following scenario would result. First,
+ tweak forward (TWF). Since DIFF < MRES, the motor is not moved. Next, tweak
+ reverse (TWR). Next TWF again. The motor record does not respond; i.e., DVAL
+ and RVAL are not updated; VAL is not posted. A single tweak, back and forth,
+ confirms that the motor record is not responding.
+
+
+ -
+ Fixed with R4-7-4.
+
+
+ -
+ The motor record would lock-up when a user tried to move off an activated limit
+ switch with the OMS VME58 servo motor controller board (i.e., model -8S). See "Known
+ Problems" item #4 in the motor record's distribution README file.
+
+
+ -
+ Fixed with R4-7-4.
+
+
+
+
+Known problems with Release 4-6
+
+
+ -
+ An uninitialized pointer error check was omitted from ESP300_init_record() in
+ the devESP300.c file. This resulted in a bus error at boot-up if there was
+ a failure to connect to the controller. Choose one of the following
+ methods to applying the bug fix:
+
+
+ -
+ Replace <motor>/motorApp/NewportSrc/devESP300.c with the following
+ updated copy: devESP300.c
+
+ -
+ Install motor record version R4-6-1 or above, which includes this bug fix.
+
+
+
+ -
+ With release 4-5, DBE_LOG was omitted from the event select mask of all
+ db_post_events() calls. This prevented archival clients from being
+ notified of process variable changes.
+
+
+ -
+ Fixed with R4-6-2.
+
+
+ -
+ Communication with the Newport MM3000 motor controller was getting out of
+ synchronization whenever the MM3000 responded with an error message. This
+ problem was resolved by having recv_mess() in drvMM3000.c detect an error
+ message response, print the error message and then, recursively, call itself.
+ This restored communication transmit/receive synchronization.
+
+
+ -
+ Fixed with R4-6-3.
+
+
+ -
+ The Newport ESP300 would randomly crash at boot-up because an internal parameter
+ ("drive_resolution") was not always, under all configurations, initialized. With
+ this release, the "drive_resolution" is set based on the response to the ESP300
+ "SU?" command. In addition, the user is required to set MRES to the resolution
+ of the controller as explained in the new document /motorApp/NewportSrc/README.
+
+
+ -
+ Fixed with R4-6-3.
+
+
+ -
+ A bug was introduced in R4-5-1 while fixing another bug; see item#2 under
+ Modification Log from R4-5 to R4-5-1 in the distribution README file. This error
+ exhibited itself only under the following conditions; BDST != 0, DLY != 0 and a
+ new target position is issued before the backlash correction move. Under these
+ conditions the motor record became unresponsive; i.e., it locked up.
+
+
+ -
+ Fixed with R4-6-4.
+
+
+ -
+ Although there is no explicit statement in the motor record documentation, most
+ user's would expect the "Readback settle time" field (DLY) to update the
+ readback after the delay timeout. It did not do this. With this release, the
+ readback is updated one time after the timeout.
+
+
+ -
+ Fixed with R4-6-4.
+
+
+
+
+Known problems with Release 4-5
+
+
+ -
+ Soft Channel Device Support - see Release
+ Notice.
+
+
+ -
+ Fixed with R4-5-1.
+
+
+ -
+ Backlash Correction Bug Fixes - see Release
+ Notice.
+
+
+ -
+ Fixed with R4-5-1
+
+
+ -
+ With release 4-5, DBE_LOG was omitted from the event select mask of all
+ db_post_events() calls. This prevented archival clients from being
+ notified of process variable changes.
+
+
+ -
+ Fixed with R4-5-2
+
+
+
+ -
+ Communication with the Newport MM3000 motor controller was getting out of
+ synchronization whenever the MM3000 responded with an error message. This
+ problem was resolved by having recv_mess() in drvMM3000.c detect an error
+ message response, print the error message and then, recursively, call itself.
+ This restored communication transmit/receive synchronization.
+
+
+ -
+ Fixed with R4-5-3.
+
+
+ -
+ The Newport ESP300 would randomly crash at boot-up because an internal parameter
+ ("drive_resolution") was not always, under all configurations, initialized. With
+ this release, the "drive_resolution" is set based on the response to the ESP300
+ "SU?" command. In addition, the user is required to set MRES to the resolution
+ of the controller as explained in the new document /motorApp/NewportSrc/README.
+
+
+ -
+ Fixed with R4-5-3.
+
+
+ -
+ A bug was introduced in R4-5-1 while fixing another bug; see item#2 under
+ Modification Log from R4-5 to R4-5-1 in the distribution README file. This error
+ exhibited itself only under the following conditions; BDST != 0, DLY != 0 and a
+ new target position is issued before the backlash correction move. Under these
+ conditions the motor record became unresponsive; i.e., it locked up.
+
+
+ -
+ Fixed with R4-5-3.
+
+
+ -
+ Although there is no explicit statement in the motor record documentation, most
+ user's would expect the "Readback settle time" field (DLY) to update the
+ readback after the delay timeout. It did not do this. With this release, the
+ readback is updated one time after the timeout.
+
+
+ -
+ Fixed with R4-5-3.
+
+
+
+ -
+ An error occurred when the SET/USE field was in the SET mode and the FOFF field
+ was in the FROZEN mode. Under these conditions, if the user entered a new RVAL,
+ the record ignored every other new RVAL; with every other new DVAL that the user
+ entered, RVAL was not updated. VAL always worked.
+
+
+ -
+ Fixed with R4-5-4.
+
+ -
+ Replace <motor>/motorApp/MotorSrc/motorRecord.c with the following updated
+ copy: motorRecord.c
+
+
+
+
+Known problems with Release 4-4
+
+
+ - The "Driver Power Monitoring" feature (available only for OMS VME58
+ controllers) was erroneously and randomly being enabled. Choose
+ one of the following methods to applying the bug fix:
+
+
+ - Make the following modification to <motor>/motorApp/MotorSrc/motordevCom.c:
+
+
+ 202a203
+ > ptrans->dpm = OFF;
+
+
+ - Replace <motor>/motorApp/MotorSrc/motordevCom.c with the
+following updated copy:
+ motordevCom.c
+ - Install motor record version R4-4-1 or above, which includes this
+bug fix.
+
+
+ - Code around "safeDoubleToFloat conversion bug" in EPICS R3.13.5.
+ A bug was introduced into R3.13.5 with the "dbConvert and dbFastLinkConv"
+ fix (see EPICS base Release Notes for R3.13.5) that resulted in the inability
+ to set PV fields defined as DBF_FLOAT's to zero. One of the scenarios
+ where this has caused a problem is when a user tries to disable software
+ travel limits by setting DHLM = DLLM = 0. Choose the following methods
+ to applying the bug fix:
+
+
+ - Replace <motor>/motorApp/MotorSrc/motordevCom.c with the following
+ updated copy:
+ motorRecord.c
+
+
+ - The makeConfigAppInclude.pl perl script distibuted with R4-4 and
+ R4-4-1 does not support spaces between the macro and the "=" sign in the
+ config/RELEASE file.
+
+
+ - The following scenario would put the motor record into an invalid state.
+ A new target position (i.e., VAL/DVAL/RVAL) is written to the motor
+record under the following conditions,
+
+ - motion is in progress (i.e., DMOV is false).
+
+
+ - the new target position is different from the actual position by
+less than the retry deadband (|DIFF| < RDBD).
+
+
+ - backlash correction is enabled (i.e., BDST is non-zero) and the
+new move is NOT in the "preferred direction" (preferred direction is the
+direction in which the motor moves during the backlash-takeout part of a
+motor move).
+
+Install motor record version 4-4-2 or above to fix this problem.
+
+
+
+Known problems with Release 4-3
+
+
+-
+The "Driver Power Monitoring" feature (available only for OMS VME58 controllers)
+was erroneously and randomly being enabled. Choose one of the following
+methods to applying the bug fix:
+
+
+-
+Make the following modification to <motor>/motorApp/MotorSrc/motordevCom.c:
+
+202a203
+
> ptrans->dpm = OFF;
+
+-
+Replace <motor>/motorApp/MotorSrc/motordevCom.c with the following updated
+copy: motordevCom.c
+
+-
+Install motor record version R4-3-1, which includes this bug fix.
+
+
+-
+Under certain conditions target positions entered through RVAL were ignored.
+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.
+Motor record version R4-3-2 includes the fix for this bug.
+
+
+
+Known problems with Release 3-5
+
+
+ - Under certain conditions target positions entered through RVAL were
+ignored. 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.
+
+
+
+ - Replace motorRecord.c with the following updated copy:
+motorRecord.c
+
+
+
+
+
+
+
+
diff --git a/docs/README.md b/docs/README.md
new file mode 100644
index 0000000..12d11f9
--- /dev/null
+++ b/docs/README.md
@@ -0,0 +1,8 @@
+# HTML documentation
+
+* [index.html](https://epics-modules.github.io/motor) (formerly motor.html)
+* [motorDeviceDriver.html](https://epics-modules.github.io/motor/motorDeviceDriver.html)
+* [motorRecord.html](https://epics-modules.github.io/motor/motorRecord.html)
+* [motor_files.html](https://epics-modules.github.io/motor/motor_files.html)
+* [motor_release.html](https://epics-modules.github.io/motor/motor_release.html)
+* [trajectoryScan.html](https://epics-modules.github.io/motor/trajectoryScan.html)
diff --git a/docs/epics_logo.gif b/docs/epics_logo.gif
new file mode 100644
index 0000000..26ed21a
Binary files /dev/null and b/docs/epics_logo.gif differ
diff --git a/docs/index.html b/docs/index.html
new file mode 100644
index 0000000..2c436c6
--- /dev/null
+++ b/docs/index.html
@@ -0,0 +1,618 @@
+
+
+
+
+
+
+
+ EPICS: Motor Record
+
+
+
+EPICS: Motor Record and Device/Driver support.
+
+
+ - Module Owners: Kevin Peterson
+
+
+
+
+This is the home page for both the motor record and various motor controllers
+supported by motor record device/drivers.
+
+
+GitHub repository: https://github.com/epics-modules/motor
+
+
+Please email any comments to Kevin Peterson who
+is responsible for coordinating development and releases. Bug reports can be created on
+github.
+
+
+Where to Find it
You can download the software using
+the links in the table below:
+
+
+
+Required Modules
+
+
+
+ Motor Version |
+ Required modules |
+ Release needed |
+
+
+ R6-10 |
+ ASYN
+ IPAC (for serial
+ or GPIB communication only) |
+ R4-25
+ R2-13 |
+
+
+ R6-9 |
+ ASYN
+ IPAC (for serial
+ or GPIB communication only) |
+ R4-25
+ R2-13 |
+
+
+ R6-8 |
+ ASYN
+ IPAC (for serial
+ or GPIB communication only) |
+ R4-21
+ R2-12 |
+
+
+ R6-7 |
+ ASYN
+ IPAC (for serial
+ or GPIB communication only) |
+ R4-18
+ R2-11 |
+
+
+ R6-5 |
+ ASYN
+ IPAC (for serial
+ or GPIB communication only) |
+ R4-13-1
+ R2-10 |
+
+
+ R6-4 |
+ ASYN
+ IPAC (for serial
+ or GPIB communication only) |
+ R4-10
+ R2-9 |
+
+
+ R6-3 |
+ ASYN
+ IPAC (for serial
+ or GPIB communication only) |
+ R4-9
+ R2-9 |
+
+
+ R6-2 |
+ ASYN
+ IPAC (for serial
+ or GPIB communication only) |
+ R4-7
+ R2-8 |
+
+
+ R6-1 |
+ ASYN
+ IPAC (for serial
+ or GPIB communication only) |
+ R4-6
+ R2-8 |
+
+
+ R6-0 |
+ ASYN
+ IPAC (for serial
+ or GPIB communication only) |
+ R4-6
+ R2-8 |
+
+
+ R5-9-1 |
+ ASYN
+ IPAC (for serial
+ or GPIB communication only) |
+ R4-6
+ R2-8 |
+
+
+ R5-8 |
+ ASYN (for
+ serial or GPIB communication only)
+ IPAC (for serial
+ communication only) |
+ R4-4
+ R2-8 |
+
+
+ R5-7 |
+ ASYN (for
+ serial or GPIB communication only)
+ IPAC (for serial
+ communication only) |
+ R4-3
+ R2-8 |
+
+
+ R5-6 |
+ ASYN (for
+ serial or GPIB communication only)
+ IPAC (for serial
+ communication only) |
+ R4-2
+ R2-8 |
+
+
+ R5-5 |
+ ASYN (for
+ serial or GPIB communication only)
+ IPAC (for serial
+ communication only) |
+ R4-1
+ R2-8 |
+
+
+ R5-4 |
+ ASYN (for
+ serial or GPIB communication only)
+ IPAC (for serial
+ communication only) |
+ R3-3
+ R2-7a |
+
+
+ R5-3 |
+ MPF (for
+ serial communication only; no GPIB support)
+ IPAC (for serial
+ communication only) |
+ R2-4-2
+ R2-7a |
+
+
+ R5-2 |
+ MPF (for
+ serial communication only; no GPIB support)
+ |
+ R2-4
+ |
+
+
+ R4-9 |
+ MPF
+ (for serial or GPIB communication only)
+ mpfGpib
+ (for GPIB communication only; runtime requirement only)
+ mpfSerial
+ (for serial communication only) |
+ R1-10
+ R1-5
+ R1-5 |
+
+
+ R4-8 |
+ MPF
+ (for serial or GPIB communication only)
+ mpfGpib
+ (for GPIB communication only; runtime requirement only)
+ mpfSerial
+ (for serial communication only) |
+ R1-10
+ R1-4
+ R1-4 |
+
+
+ R4-7 |
+ MPF
+ (for serial or GPIB communication only)
+
+ mpfGpib
+ (for GPIB communication only; runtime requirement only)
+
+ mpfSerial
+ (for serial communication only) |
+ R1-10
+
+ R1-4
+
+ R1-4 |
+
+
+ R4-6 |
+ Same as R4-5 |
+
|
+
+
+ R4-5
+ |
+ MPF
+ (for serial or GPIB communication only)
+ mpfGpib
+ (for GPIB communication only; runtime requirement only)
+ mpfSerial
+ (for serial communication only)
+ |
+ R1-8
+ R1-4
+ R1-3
+ |
+
+
+ R4-4 |
+ MPF
+ (for serial or GPIB communication only)
+ mpfGpib
+ (for GPIB communication only; runtime requirement only)
+ mpfSerial
+ (for serial communication only) |
+ R1-6
+ R1-3
+ R1-2 |
+
+
+ R4-3 |
+ MPF
+ (for serial or GPIB communication only)
+ mpfGpib
+ (for GPIB communication only; runtime requirement only)
+ mpfSerial
+ (for serial communication only) |
+ R1-6
+ R1-3
+ R1-2 |
+
+
+ R4-1 |
+ MPF
+ (for serial or GPIB communication only)
+ mpfGpib
+ (for GPIB communication only; runtime requirement only)
+ mpfSerial
+ (for serial communication only)
+
+
+ OR
+
+ HIDEOS (for
+ serial or GPIB communication only) |
+ R1-5
+ R1-3
+ R1-1
+
+ Latest?
+
+ |
+
+
+
+
+
+Installation and Building
After obtaining a copy of the distribution,
+it must be installed and built for use at your site. These steps only need to
+be performed once per site (unless versions of the module running under
+different releases of EPICS and/or the other required modules are needed).
+
+ -
+ Create an installation directory for the module, usually this will end with
+
+
+ .../support/motor/
+ -
+ Place the distribution file in this directory. Then issue the commands (Unix
+ style)
+
+
+ gunzip motor<rel>.tar.gz
tar xvf motor<rel>.tar
+ where <rel> is the release. For example.
+
+ motor4-1.tar.gz
+ -
+ This creates a <top> application.
+
+
+ .../support/motor/motor<rel>
+ -
+ Edit the config/RELEASE file and set the paths to your installation of
+ EPICS base (i.e., define SUPPORT and EPICS_BASE).
+
+ -
+ Edit .../support/motor/motor<rel>/motorApp/Makefile. Define
+ which device/driver modules to build.
+
+ -
+ Run gnumake in the top level directory and check for any compilation
+ errors.
+
+
+
+
+Documentation
The following documentation is available:
+
+ -
+ Consult the README file in the motor distribution for configuration
+ details.
+
+
+
+
+
+
+Page Last Modified: 05/01/2018
+Kevin Peterson
+
+
+
+
+
diff --git a/documentation/motorDeviceDriver.html b/docs/motorDeviceDriver.html
similarity index 64%
rename from documentation/motorDeviceDriver.html
rename to docs/motorDeviceDriver.html
index 0205b9a..2a4ada6 100644
--- a/documentation/motorDeviceDriver.html
+++ b/docs/motorDeviceDriver.html
@@ -206,176 +206,6 @@
The asynMotorAxis base class defines the following methods:
-
- This driver inherits from ADDriver.
- It implements many of the parameters in
- asynNDArrayDriver.h and in
- ADArrayDriver.h. It also implements a number of parameters that are specific
- to the mar345 detector. The mar345
- class documentation describes this class in detail.
-
- Implementation of standard driver parameters
-
- The following table describes how the mar345 driver implements some of the standard
- driver parameters.
-
-
-
-
-
- Implementation of Parameters in asynNDArrayDriver.h and ADDriver.h, and EPICS Record
- Definitions in ADBase.template and NDFile.template |
-
-
-
- Parameter index variable |
-
- EPICS record name |
-
- Description |
-
-
-
- ADAcquire |
-
- $(P)$(R)Acquire |
-
- Setting this to 1 starts an acquisition sequence. If ADNumImages is greater than
- 1 then it acquires multiple frames. For each frame it does the following:
-
- - Erases the detector if mar345EraseMode is "Before expose".
- - Opens the shutter if either the mar345 shutter or EPICS shutter controls are enabled.
- - Waits for the desired exposure time.
- - Closes the shutter if either the mar345 shutter or EPICS shutter controls are
- enabled.
- - Scans the detector and saves the file.
- - Erases the detector if mar345EraseMode is "After scan".
-
- If ADAcquire is set to 0 during exposure (step 3 above) then it proceeds immediately
- to step 4, finishes collecting the current frame and stops the acquisition sequence
- if ADNumImages is greater than 1. If mar345Abort is set to 0 then the acquisition
- is terminated as soon as possible without saving the data. Note however that commands
- to the mar345 server to erase, change mode, or scan cannot be aborted, so the driver
- must wait for these commands to complete. |
-
-
-
-
- It is useful to use NDPluginROI to define an ROI containing the entire mar345 detector.
- The MaxValue_RBV PV in this ROI can be monitored to make sure that the 16-bit limit
- of 65,535 is not being approached in any pixel.
-
-
- mar345 specific parameters
-
- The mar345 driver implements the following parameters in addition to those in asynNDArrayDriver.h
- and ADDriver.h. Note that to reduce the width of this table the parameter index
- variable names have been split into 2 lines, but these are just a single name, for
- example mar345ScanSize
.
-
-
-
-
-
- Parameter Definitions in mar345.cpp and EPICS Record Definitions in mar345.template
- |
-
-
-
- Parameter index variable |
-
- asyn interface |
-
- Access |
-
- Description |
-
- drvInfo string |
-
- EPICS record name |
-
- EPICS record type |
-
-
-
- Readout parameters |
-
-
-
- mar345
- ScanSize |
-
- asynInt32 |
-
- r/w |
-
- The detector diameter to read out. Choices are 180mm, 240mm, 300mm, and 345mm.
- |
-
- MAR_SIZE |
-
- $(P)$(R)ScanSize
- $(P)$(R)ScanSize_RBV |
-
- mbbo
-
- mbbi |
-
-
-
- mar345
- ScanResolution |
-
- asynInt32 |
-
- r/w |
-
- The pixel size to use when reading the detector out. Choices are 0.10 and 0.15mm.
- |
-
- MAR_RESOLUTION |
-
- $(P)$(R)ScanResolution
- $(P)$(R)ScanResolution_RBV |
-
- mbbo
-
- mbbi |
-
-
-
-
- Configuration
-
- The mar345 driver is created with the mar345Config command, either from C/C++ or
- from the EPICS IOC shell.
- int mar345Config(const char *portName, const char *serverPort,
- int maxBuffers, size_t maxMemory,
- int priority, int stackSize)
-
-
- For details on the meaning of the parameters to this function refer to the detailed
- documentation on the mar345Config function in the
- mar345.cpp documentation and in the documentation for the constructor for
- the mar345 class.
-
-
- There an example IOC boot directory and startup script (iocBoot/iocMAR345/st.cmd)
- provided with areaDetector.
-
-
- MEDM screens
-
- The following show the MEDM screens that are used to control the mar345 detector.
- Note that the general purpose screen ADBase.adl can be used, but it exposes many
- controls that are not applicable to the mar345, and lacks some fields that are important
- for the mar345.
-
- mar345.adl
is the main screen used to control the mar345 driver.
-
-
-
- mar345.adl
-
![mar345.png](mar345.png)
+ NOTE: This documentation file is incomplete. It needs to be completed.