# Procedure for new motor record device drivers
Author: sluiter

# Procedures for adding new motor controller support to motor record

1. Select a supported controller that most closely matches the characteristics of the new controller. If the new controller is simply a different model of a supported controller family (e.g. Oregon Micro Systems or Newport's Motion Master), then, of course, chose a model from the controller family that most closely matches the characteristics of the new controller. Otherwise, select a supported controller based on other characteristics, such as; communication interface (i.e., VME, RS232, GPIB), controller features (e.g., encoder support, DC servo support, etc.), etc. In what follows this will be called the source controller or source device driver.

- When I added MM3000 device support I selected the MM4000 because it is simply a different Newport model.
- When I added IM483 device support I selected the MM4000 because it has a serial communication option.

2. Chose an appropriate device name for the new controller. Copy the relevant files from the selected source controller, to the new, destination, controller, giving the new files appropriate names using the new device name. (See motor_files.html for a list of all motor record source code files.)

- When I added MM3000 device support I copied the following files:

- devMM4000.c -> devMM3000.c
- drvMM4000.h -> drvMMCom.h
- drvMM4000.c -> drvMM3000.c

- When I added IM483 device support I copied the following files:

- devMM4000.c -> devIM483.c
- drvMMCom.h -> drvIM483.h
- drvMM4000.c -> drvIM483.c

3. Modify all the new files by cleaning up the obvious header information (e.g. filename, usage, etc.). Delete the old Modification Log entries and add a single new entry that notes which source file you copied to start this file.
4. Modify the new driver include file (e.g., drvOms.h, drvMMCom.h, drvIM483.h, etc.) first.

- Fix the multiple inclusion protection; i.e.,

- #ifndef INCfilenameh
- #define INCfilenameh 1
- #endif /* INCfilenameh */

- Delete everything in the driver include file that is specific to the old controller. If a device specific data area is needed for this controller, then that structure definition should appear in this file (see the MMcontroller structure in drvMMCom.h or IM483controller structure in drvIM483.h).

5. Modify the device source code file (e.g., devOms.c, devMM4000.c, devIM483.c, etc.) next.

- Do a global find and replace on the file; replacing the source root name with the destination root name; e.g., MM4000 to IM483.
- Find the <device>_build_trans() function. Unless the source controller you chose was from the same family of controllers, the command primitives for the new controller will not match those of the source controller. Hence, each of the switch case statements in <device>_build_trans() will have to be;

1. Evaluated, as to be whether or not the new controller can support the associated motor command.
2. If the new controller supports the motor command, find the command primitive for the motor command and modify the switch case code to output the correct command primitive.

- Check that the command line terminator function argument located in the <device>_end_trans() function is correct.
- Determine whether or not the destination motor controller supports multiple commands on the same command line. For example, the Oregon Micro Systems (OMS) motor controllers allow the velocity base, slew velocity, acceleration and target position all on the same command line (e.g., AX VB200 VL4000 AC4444 MA-38866 GD ID). The Newport Motion Master (i.e, MM3000, MM4000, MM4005) and PM500 controllers also support multiple commands. On the other hand, multiple commands are not supported by the Intelligent Motion Systems (IMS) IM483 motor controller.

- If multiple commands on the same command line is supported, then the functions <device>_start_trans(), <device>_end_trans() and <device>_build_trans() in the destination device code should look like those found in any of the Newport device files; i.e., devPM500.c, devMM4000.c or devMM3000.c. In addition, determine the command seperation ASCII character for the destination motor controller and append this ASCII character to the end of each command primitive.
- If multiple commands on the same command line is not supported, then the functions <device>_start_trans(), <device>_end_trans() and <device>_build_trans() in the should look like those found in any of the IMS device files; i.e., devIM483SM.c or devIM483PL.c.

6. Modify the driver source code file (e.g., drvOms.c, drvMM4000.c, drvIM483.c, etc.) next.

- Do a global find and replace on the file; replacing the source root name with the destination root name; e.g., MM4000 to IM483.
- Locate each call to send_mess() that passes a string constant argument, either explicitly or through a preprocessor macro name. Modify either the string constant or the macro definition for the new controller.
- Determine whether or not the destination motor controller echos commands and whether or not this feature can be disabled. If echoing cannot be disabled, then set the brdptr->cmnd_response = ON in motor_init().