Added the subroutine compumotor_command_tcpip() which sends a compumotor
command over the network to the compumotor.  It then expects a reply which is
stored in the reply character buffer allocated in the front end to the
subroutine motorcmd_net.  As the subroutine stands it is untested, and will
hopefully be tested soon.  Comments in the file compumotor_command_tcpip.c
explain the arguments to the subroutine.  

Bob
Wed Jul 13 15:00:37 MDT 2005
--
Corrected the allocation of the pointer to a pointer character array.
Currently the program compiles, and appears to run.  At least it allocates the
matrix as expected.  Now we will have to see if it accepts multiple line
replies from the compumotor.

Bob
Mon Jan 31 11:31:22 MST 2005
--
Altered the call to compumotor_command to accept a matrix (char **) of char to
accept multiple line replies from the compumotor.  The parameter
number_of_terminators determines the number of lines.  The replies are stored
in each element of the array, and must be allocated before the call to
compumotor_command.  As the code stands, it has yet to be tested.

Bob
Thu Jan 27 18:57:01 MST 2005
--
First version of the code that works properly.  As it stands the code 
communicates over the rs232 port successfully to the compumotor.  The two 
functions that are of concern are rs232_openport which opens the device to 
allow the communication over serial to occur, and compumotor_command that 
sends a command to the compumotor, and expects a reply if an array is passed 
to hold a reply. Also altered the compumotor_command function to hopefully 
allow multiple line replies.  This remains untested, but should work.

Bob
Thu Jan 27 12:15:00 MST 2005
--
Altered an inconsistency with a pointer from an array that was being set in
rs232_getline.c.  Basically I changed the two lines 

    buffer[i+1] = NULL;
and 
  buffer[i-1] = NULL;

with 

    buffer[i+1] = '\0';
and 
  buffer[i-1] = '\0';

Bob
Tue Jan 25 20:41:20 MST 2005
--
Drastically altered the code.  The code is now much simplier, and uses none of
the data structres defined by the original MX code.  All the code from the MX
software is almost completely removed from the repository.  As the cose
currently stands it compiles, but it has not been tested.

Bob
Tue Jan 25 20:30:43 MST 2005
--
Started to add definitions into the header files.  Also started to edit each
of the files that are required by compumotor_command.c.  The definitons I am
defining are being renamed for our own specific case.  What still needs to be
done is the initialization routines need to be worked out.  

Bob
Mon Jan 17 17:22:55 MST 2005
--
Started to split each function call into thier own files.  This makes it
easier for writing your own functions.  The file names will refelct the name
of the function within.  In other words, the function int serial_putline()
will be wthin the file named serial_putline.c.  Also started to rename the
functions and manipulate them to serve our purposes.  I will also be dividing
the definitins within the header files into ones specific to the protocol used
to communicate.  

Bob
Tue Jan 11 04:41:13 MST 2005
--
Made trivial changes to the code.  This will change in the future (probably
tomorrow :-).  

Bob
--
Then when I had access to the machine all by myself, I tried to
get the assorted .c files to compile individually.

For the file minitxtra,that required eliminating a redundant
declaration of mx_default_scan_pause_request_handler() and changing
the variable name mx_list_of_types to mx_initial_list_of_types inside
the function mx_initialize_drivers() to avoid conflict with an earlier
declaration of a global variable of that name. It also required
introducing a few new declarations into the header file minit.h, which
is #include-d by minitxtra.c.  These changes consisted of #define-ing
PRINTFLIKE and a macro based on it, mx_error(). The macro MX_DEBUG
also needed to be defined.

Now all the files minit.c, minitxtra.c, motorcmd.c, and lib.c compile
without error when they are individually compiled with the command
"gcc -c filername.c".  The object files do not yet link together
nicely, however.

Rich Barrans 6 January 2005
---
Bob added the CHANGELOG to the /testing directory and emphasized the
importance of religiously, thoroughly, and clearly recording all
changes I make and the reasons therefore.  Rich Barrans 6 January 2005
---