\subsection{Compumotor 6K and 6000 Series Motor Controllers}
\textit{Platforms: All}

\ \newline
This set of drivers supports both the Compumotor 6000 and 6K series of 
controllers from the 
\MxLink{http://www.compumotor.com/}
 {Compumotor division of Parker Hannifin \textit{(http://www.compumotor.com/)}}.
Vendor information about the 6K series can be found at
\MxLink{http://www.compumotor.com/literature/pg023\_6k.htm}
{http://www.compumotor.com/literature/pg023\_6k.htm}

Several different MX drivers are associated with this type of controller.
They are:
\begin{itemize}
  \item\textit{compumotor\_int} - An interface driver that manages all of the
	Compumotor controllers attached to a particular serial port or
	Ethernet connection.  There will be one of these records for
	each controller.
  \item\textit{compumotor} - The basic motor driver for Compumotor controllers.
  	Each axis will use its own separate instance of this driver.
  \item\textit{compumotor\_lin} - Designed for performing linear interpolation
  	moves with multiple axes.  \textbf{Warning:} currently somewhat broken.
  \item\textit{compumotor\_din} - Used to read the digital input pins on
  	a Compumotor 6K controller.
  \item\textit{compumotor\_dout} - Used to control the digital output pins on
  	a Compumotor 6K controller.
\end{itemize}
So far these drivers have been tested with both the 6K and Zeta 6104
controllers.

An example database for a 4-axis Compumotor 6K controller would look like this
\begin{verbatim}
6k_rs232 interface rs232 tty "" "" 9600 8 N 1 S 0x0d0a 0x0d0a 10 0x0 /dev/ttyS5
6k interface controller compumotor_int "" "" 6k_rs232 0x0 1 1 4
m1 device motor compumotor "" "" 0  0 -1000000 1000000 0 -1 -1 1 0 um 6k_test 1 1 1
m2 device motor compumotor "" "" 0  0 -1000000 1000000 0 -1 -1 1 0 um 6k_test 1 2 1
m3 device motor compumotor "" "" 0  0 -1000000 1000000 0 -1 -1 1 0 um 6k_test 1 3 1
m4 device motor compumotor "" "" 0  0 -1000000 1000000 0 -1 -1 1 0 um 6k_test 1 4 1
\end{verbatim}

\subsubsection{compumotor\_int}
This interface driver manages information about the Compumotor controller
as a whole that is not specific to a particular axis.

\newcommand{\MxFieldCompumotorZintRsCDCZrecord}
{The name of the \textit{rs232\_record} interface that the controller
is plugged into.  In general, the \textit{rs232\_record} can either
correspond to a real RS-232 device such as the \textit{tty} or
\textit{win32\_com} driver or to a device connected via Ethernet,
which will use the \textit{tcp232} driver.}
%
\newcommand{\MxFieldCompumotorZintInterfaceZflags}
{Flags to select optional features.  They are described in more detail below.}
%
\newcommand{\MxFieldCompumotorZintNumZcontrollers}
{For a multidrop system such as the Zeta 6104, this record will
control all of the real controllers attached to the multidrop cable.
You must specify the number of controllers here.  For a 6K
controller, this value will always be 1.}
%
\newcommand{\MxFieldCompumotorZintControllerZnumber}
{This varying length array lists the controller address for each
controller as set by the Compumotor \texttt{ADDR} command.
For a 6K controller, there will only be one value here.}
%
\newcommand{\MxFieldCompumotorZintNumZaxes}
{This varying length array lists the maximum number of motor axes
for each controller on the multidrop cable.
For a 6K controller, there will only be one value here.
The allowed range of values for this field are from 1 to 8.}
%
\ \newline
\MxCompumotorZintDriverFields

\ \newline
The \textit{interface\_flags} field will be the logical OR of the option
bits selected from the following list:
\begin{center}
\begin{tabularx}{0.9\textwidth}{rcX}
0x1 & - & If this flag is selected, the MX driver will send a Compumotor
	\texttt{ADDR} command at startup, which will cause
	the controllers on a multidrop
	to automatically configure their addresses from 1 to N.
	In general, we recommend not use this option.  Instead, you should
	configure the address in the startup program of each controller.
	\\
\ & \ & \\
0x2 & - & If this flag is selected, the MX driver expects the Compumotor
	controller to echo all commands sent to it.  This option is not
	normally recommended since it adds extra RS-232 I/O for reading
	and discarding the echoed command strings.  It is just here in
	case you are alternating operation of the controller
	between MX and some other package that expects the commands
	to be echoed.
	\\
\end{tabularx}
\end{center}

\subsubsection{compumotor}
The \textit{compumotor} driver handles one particular axis in a
Compumotor controller.
Since Compumotor interface records support multiple controllers and axes,
both the controller number and the axis number must be specified.

Go to the \MxInternalLink{motor}{MX Motor Driver Support}
page for the common motor record description fields.
For the \textit{compumotor} driver, the following driver specific fields
are present:
\newline
\newcommand{\MxFieldCompumotorCompumotorZinterfaceZrecord}
{The name of the Compumotor controller record for this motor.}
%
\newcommand{\MxFieldCompumotorControllerZnumber}
{The controller number for this particular motor.}
%
\newcommand{\MxFieldCompumotorAxisZnumber}
{The axis number for this particular motor in the specified controller.}
%
\newcommand{\MxFieldCompumotorFlags}
{Setting particular bits in the flags variable can modify
	the behavior of the driver.  The individual bit values
	are specified below.}
%
\MxCompumotorDriverFields
\ \newline
%
Flag bits for the \textit{flags} field:
\newline
\begin{tabularx}{1.0\textwidth}{rcX}
0x1 & - & This flag tells the driver to get the motor position using the
	TPE (Transfer Position of Encoder) command rather than the
	TPM (Transfer Position of Motor) command. \\
0x2 & - & This flag tells the driver to round raw motor positions to the
	nearest integer when setting motor destinations using the D command
	or redefining the position using the PSET command. \\
0x1000 & - & This flag tells the driver to disable hardware limits 
	for this axis using the LH0 command. \\
\end{tabularx}
%
\subsubsection{compumotor\_din}

\newcommand{\MxFieldCompumotorZdinCompumotorZinterfaceZrecord}
{The name of the Compumotor controller record for this motor.}
%
\newcommand{\MxFieldCompumotorZdinControllerZnumber}
{The controller number for this particular device.}
%
\newcommand{\MxFieldCompumotorZdinBrickZnumber}
{The brick number for this particular device.}
%
\newcommand{\MxFieldCompumotorZdinFirstZbit}
{The bit number of the first bit controlled by this record.}
%
\newcommand{\MxFieldCompumotorZdinNumZbits}
{The number of bits controlled by this record.}
%
\MxCompumotorZdinDriverFields

\subsubsection{compumotor\_dout}

\newcommand{\MxFieldCompumotorZdoutCompumotorZinterfaceZrecord}
{The name of the Compumotor controller record for this motor.}
%
\newcommand{\MxFieldCompumotorZdoutControllerZnumber}
{The controller number for this particular device.}
%
\newcommand{\MxFieldCompumotorZdoutBrickZnumber}
{The brick number for this particular device.}
%
\newcommand{\MxFieldCompumotorZdoutFirstZbit}
{The bit number of the first bit controlled by this record.}
%
\newcommand{\MxFieldCompumotorZdoutNumZbits}
{The number of bits controlled by this record.}
%
\MxCompumotorZdoutDriverFields

\subsubsection{compumotor\_lin}
\textbf{Warning:} The \textit{compumotor\_lin} driver is
partially obsolete and partially broken.
If you merely want to have the motor perform a simultaneous start, then
you should use the \textit{linear\_function} pseudomotor instead.
If you want blended moves, then you will need to fix the part of the
driver that is supposed to do that.
\newline\ \newline
%
\newcommand{\MxFieldCompumotorZlinFlags}
{Setting particular bits in the flags variable can modify
	the behavior of this pseudomotor.  The individual bit values
	are specified below.}
%
\newcommand{\MxFieldCompumotorZlinNumZmotors}
{The number of motors used by this pseudomotor.}
%
\newcommand{\MxFieldCompumotorZlinMotorZrecordZarray}
{This array lists all of the motor records used by this pseudomotor.}
%
\newcommand{\MxFieldCompumotorZlinRealZmotorZscale}
{The real motor position is multiplied by this scale when computing the
raw pseudomotor position.}
%
\newcommand{\MxFieldCompumotorZlinRealZmotorZoffset}
{This offset is added to the scaled real motor position when computing the
raw pseudomotor position.}
%
\newcommand{\MxFieldCompumotorZlinMotorZmoveZfraction}
{When a move is commanded, this value specifies what fraction of the total
raw pseudomotor move is to be performed by this motor.}
%
\MxCompumotorZlinDriverFields

\ \newline
The \textit{interface\_flags} field will be the logical OR of the option
bits selected from the following list:
%
\begin{center}
\begin{tabularx}{0.9\textwidth}{rcX}
0x1 & - & If this flag is selected, the pseudomotor will perform
	a simultaneous start rather than a blended move.
	\textbf{Warning:}  If you do \textit{not} set this bit, the
	driver attempts to perform a blended move.  However, the driver
	currently does not correctly implement the blended move. \\
\end{tabularx}
\end{center}

\subsubsection{General Notes}

\begin{itemize}
  \item The MX drivers assume that daisy-chained controllers
	are numbered from 1 to N where N is the number of controllers.
	This may be done via the \textbf{ADDR} command as described in
	the 6000 and 6K Command Reference manuals.  For more information
	look at the sections named \textit{RS-232C Daisy-Chaining} and
	\textit{RS-485 Multi-Drop} in the Compumotor 6000 or 6K
	Programmer's Guide.

  \item If you use the ethernet port on a 6K controller, you will need
	to use the 'tcp232' RS-232 interface type and specify the
	port number to connect to as 5002.
	
	\textit{Warning: Very old 6K controllers used port 502.
	If there is a problem, using a packet sniffer
	while the vendor supplied code for Windows is running should
	be able to determine the correct port number.}

  \item The MX Compumotor drivers make certain assumptions about the
  	internal configuration of Compumotor controllers.   
	Figure \ref{dr_compumotor_compumotor}
	shows an example startup script for Compmotor controllers
	that is compatible with MX.
\begin{figure}
\begin{verbatim}
; This command script is to be downloaded into a Compumotor 6000 or 6K
; controller in order to set up the controller to be compatible with MX.
; The script sets up a startup command program to be executed by the
; Compumotor controller at power-on.  The commands for ERRLVL, EOT, and MA
; _must_ be set as shown below or else the MX driver will not work.
; If you need other commands to set motor parameters, network addresses,
; and so forth, add them to the commands listed below.
;
; Please note that if you use ECHO1, you must add the 0x2 echo on flag to
; the compumotor_int record that defines the connection to the interface.
; This lets the driver know that it needs to discard echoed characters.
;
; For a single controller, it is better to set ECHO0 since that will 
; eliminate the overhead of discarding the characters.  However, in a
; multidrop daisy chain configuration, ECHO1 _must_ _be_ _set_ since the
; controllers rely on the echoing to send the command on to the next
; controller in the daisy chain.  If ECHO0 is set in a daisy chain
; configuration, the configuration will mostly work but will randomly
; lock up from time to time, so don't do it.
;
; William Lavender -- Last modified April 27, 2002
;
DEF mstart
ERRLVL1          ; Have the controller generate a minimum amount of output.
EOT13,10,0       ; Want all output lines to have the same line terminators.
MA1              ; Use absolute mode for positioning.
LH0              ; Disable limits (for testing only!)
ENC0             ; Use motor step mode ( or set ENC1 for encoder step mode ).
ECHO1            ; Enable command echoing.
END
\end{verbatim}
\caption{Recommended STARTP program for MX controlled Compumotor motors.}
\label{dr_compumotor_compumotor}
\end{figure}
	The MX drivers will not operate correctly if the variables
	\textbf{ERRLVL}, \textbf{EOT}, and \textbf{MA} are not set as shown.
	Also note that the setting shown for \textbf{EOT} means that the 'rs232'
	driver must be configured with the read and write terminators
	set to 0x0d0a.
	In addition, the setting \textbf{ECHO1} is required in order
	for multi-drop installations to function correctly.  For a single
	controller, you may use \textbf{ECHO0} which will reduce the amount
	of serial I/O required.
\end{itemize}

\subsubsection{Bugs}

At present, Zeta 6104s occasionally stop communicating with the MX
driver.  The exact circumstances under which this occurs is not
entirely clear.  However, since most of our Compumotor usage is 
migrating towards the 6K series, the need to fix this issue may
become less important.

