spec

Software for Diffraction

newport

Various Newport motor controllers

DESCRIPTION

spec supports a number of Newport motor controller models, including the following:

Newport Agilis
Newport CONEX-AGP
Newport DL
Newport ESP300
Newport MM2000 (formerly Klinger KL2000)
Newport MM2500 (formerly Micro-Controle ITL09)
Newport MM3000
Newport MM4000
Newport MM4005
Newport MM4006
Newport NSC200
Newport PM500
Newport PZC200
Newport SMC100
Newport XPS

spec support for the Newport Agilis is described in spec's agilis help file. spec support for the Newport MM2000 and MM3000 models is described in spec's kl2000 help file.

The following sections describe the spec support for the Newport CONEX-AGP, Newport DL, Newport SMC100 and Newport XPS.

Newport CONEX-AGP

The Newport Agilis-P model CONEX-AGP is a single-axis motor controller for a piezo actuator with encoder feedback. Use the "dump" option with the motor_par() command to list all the parameters names associated with the controller along with their current values. The parameters can be assigned as standard or non-standard optional parameters using spec's hardware configuration editor, as appropriate.

The CONEX-AGP has a USB interface that is supported on Linux and Mac OSX using USB-to-serial kernel drivers. On Linux, the standard ftdi_sio kernel module is required along with the special udev rules installed by spec in /etc/udev/rules.d/10-spec_usb.rules. On OSX, the VCP driver available at the ftdichip.com must be installed, and the CONEX USB vendor and product IDs must be added to the kernel extension Info.plist file as explained in the FTDI Technical Note 105 available at the FTDI website.

Newport DL

The Newport DL Controller Series single-axis motion controller for delay line stage uses an internal state machine. In order to move the stage, the controller must be in the READY state. In order to set certain parameters, the controller must be in the CONFIGURATION state. The only way to get to the READY state from the power-on or the CONFIGURATION state is to pass through the NOT INITIALIZED, INITIALIZING, NOT REFERENCED and HOMING states. The CONFIGURATION state can only be reached through the NOT INITIALIZED state. The NOT INITIALIZED state is reached through power-on, a hardware fault or the reset command. The spec support for the controller keeps track of the controller state and issues the needed commands to put the controller through the state changes.

The DL controller has many programmable parameters. All parameters can be changed in the CONFIGURATION state. New values assigned to parameters in the CONFIGURATION state are stored in the controller's non-volatile memory. Other parameters can be changed in the READY or DISABLED state, but changes in those states are temporary and will be lost on the next power cycle of the controller.

spec programs the controllers soft limits to match the limits configured in spec's settings file.

The following motor_par() commands are implemented. Note that the second argument is case insensitive.

motor_par(mne, "warning_distance" [, arg])
There is a firmware issue with the DL controllers in that if an initialization command is sent while the stage is too close to the end-of-run position, the stage runs past the optical limits and gets stuck, requiring manual intervention to move the stage away the end of run. When the stage is within "warning_distance" of the limit, spec will ask if the user really wants to proceed with actions that would send an initialize (IE), reset (RS) or home (OR) command to the controller. The default value of "warning_distance" is 15. This parameter can be configured with a different value as a nonstandard optional parameter in config file.
motor_par(mne, "dump" [, arg])

With no arguments, displays all parameters obtained using the ZT command. The command associated with each parameter and the parameter value are displayed along the following lines:

ID      DLS325
AC      600
AF      1
DBL     5e-06
DBH     3.5e-05
...

With an argument, parameters that match the argument string are displayed. For each matching argument, spec sends a separate command to retrieve the parameter value from the controller.

The parameter name argument is case insensitive. The string can be the name of a single parameter or can contain the standard "globbing" meta characters: *, ? and []. (A * matches any string, while a ? matches any single character. With the [...] pattern, any string that contains the characters within the square brackets is matched. Two characters separated by a hyphen specify a range of characters that will match. An initial ^ negates the enclosed character set.)

A command such as motor_par(mne, "dump", "*") would display all the parameters that spec allows to be modified along the following lines, showing spec's long name for the parameter, the controller command and the parameter value:

                      ...
  dc_derivative_gain  (KD)  : 421
  dc_following_error  (FE)  : 1
    dc_integral_gain  (KI)  : 3.5e+06
dc_proportional_gain  (KP)  : 31000 -> 30000
       deadband_high (DBH)  : 3.4e-05
        deadband_low (DBL)  : 5e-06
      driver_voltage  (DV) C: 48
       enable_keypad  (JM)  : 1
   encoder_frequency (ENF) C: 8
       encoder_pitch (ENP) C: 0.0798742
         force_limit (FML)  : 17000
         home_method  (HT) C: 3
  home_search_offset  (HO) C: -1.5
                      ...

If a C appears before the colon, the parameter can only be changed when the controller is in CONFIGURATION state. If a second value appears after a ->, that is a value that has been assigned to the parameter, but has not yet been sent to the controller.

The argument "home*" would display only parameters that begin with home:

       home_method  (HT) C: 3
home_search_offset  (HO) C: -1.5
    home_slew_rate  (OH) C: 29
      home_timeout  (OT) C: 15

The long-name parameters can be set in the config file as nonstandard optional parameters.

motor_par(mne, param [, value])
Gets or sets the value for the named parameter. The name can be the short controller command or spec's long name. When getting values, the short name causes spec to read the value currently set in the controller from the controller. When the long name is used, the value returned is the value in spec's memory, which may be different if the controller hasn't yet been updated with the modified values. When setting values, the values are not sent to the controller until the next move or homing command, although modified parameters can be programmed at once using the "update" command, described below.
motor_par(mne, "update" [, arg])
Checks if the values of any of the programmable parameters have been changed using motor_par() and updates the controller with the new values. Some parameters require the controller to be put into the CONFIGURATION state, which means the controller will go through initialization and homing before the next move command. If arg is missing or has the value zero, parameters that can be updated from the READY or DISABLED state are not updated. If arg is 1, all modified parameters are updated, but the state is not forced to CONFIGURATION state. If arg is 2, the controller is switched to CONFIGURATION state before updating values. Values set in CONFIGURATION state are saved in non-volatile memory.
motor_par(mne, "reset")
Sends the reset command (RS) to the controller, which puts the controller in the NOT INITIALIZED state.

The following command pass-through options are available if absolutely needed, but one has to understand the DL state machine and make sure commands sent do not interfere with spec's programming of the controller.

motor_par(mne, "send", cmd)
Sends the string cmd to the DL controller assigned to motor mne.
motor_par(mne, "read", cmd)
Sends the string cmd to the DL controller assigned to motor mne and returns the reply.

Newport SMC100

The SCM100 comes in two flavors, CC and PP. The PP version supports the "base_rate" parameter, while the CC version does not. In addition, some of the optional parameters listed below aren't available for one flavor or the other as indicated.

The SMC100 operates with an internal state machine, which complicates programming and usage. The controller must go through a home cycle after being powered on or reset. In order to perform a home cycle, the controller must first be reset. The controller becomes unresponsive after a reset, and spec will wait five seconds before continuing after resetting the controller. In order to change the values of many of the parameters, the controller must be in a configuration state, which can only be reached by resetting the controller.

spec programs the soft limits to match the limits configured in spec's settings file.

The following motor_par() options are available:

motor_par(motor, "send", cmd)
Sends the string cmd to the SMC100 channel associated with motor.
motor_par(motor, "read", cmd)
Sends the string cmd to the SMC100 channel associated with motor, as above, and returns a string containing the response.
motor_par(motor, "usend", cmd)
Sends the string cmd to the SMC100 unit associated with motor, but doesn't address the command to a specific motor or add the line terminators. Thus cmd must include the full SMC100 command syntax.
motor_par(motor, "uread", cmd)
Sends the string cmd to the SMC100 unit associated with motor, as above, and returns a string containing the response.
motor_par(motor, "update")
Updates any parameters that have changed, resetting the controller if necessary, then putting the controller back into the "ready" state after parameters have been programmed. The same action is performed on the first move after parameters have been changed. This "update" option avoids having a reset/ready delay on the first move of scan, for example.

The following standard optional parameters are implemented for the SMC100 controller and can be set on the first or second optional motor parameter screens of the configuration editor, reached by typing m from the main motor screen. The first column is the SMC100 command that corresponds to the spec parameter name in the second column.

KP "dc_proportional_gain" (not PP)
KD "dc_derivative_gain" (not PP)
KI "dc_integral_gain" (not PP)
FE "dc_following_error" (not PP)
KV "dc_veloc_feedforward" (not PP)
HT "home_method"

The following non-standard optional parameters can entered on the non-standard parameter screen of the configuration editor, reached by typing p from the main motor screen. The parameter name in the second column should be entered in the spec configuration editor to generate the SMC100 command given in the first column

JR  "jerk_time"
FD  "cut-off_frequency" (not PP)
FF  "friction_compensation" (not PP)
FRM "micro-step_factor" (not CC)
FRS "full_step_value" (not CC)
DV  "driver_voltage" (not PP)
OT  "home_timeout"
QIL "peak_current"
QIR "rms_current"
QIT "rms_time"
SC  "closed_loop" (not PP)
SU  "encoder_increment" (not PP)

As always, all the above parameters can be set temporarily using motor_par(), but the values will not be retained in spec on restarting or hardware reconfiguration.

Newport XPS

Newport's XPS motor controller communicates exclusively via sockets and contains its own computer and operating system. Motor parameters must be configured by downloading and uploading the XPS configuration files by ftp. spec mnemonics must match the XPS motor names in the XPS system.ini file. In particular, the value assigned to "PositionerInUse" in the Newport XPS system.ini file must match the spec motor mnemonic. Make sure the motor names in the system.ini file are seven characters or less, as that is the maximum length of a spec motor mnemonic.

spec will send slew rate and acceleration parameters, as set in spec's config file, but those parameters will only be accepted by the XPS if the values are not greater than the maximum values set in the XPS stages.ini file.

Although the value of spec's steps-per-degree parameter is ignored for calculating positions for these motors, the value is used in spec's code for rounding motor positions to their intrinsic resolution. Thus, the parameter should be set to a value the same order of magnitude as the value in the stages.ini file. (Unfortunately, there is no command in the XPS protocol to retrieve the value, other than retrieving and parsing the configuration files, which is beyond spec's scope.)

The XPS controller firmware uses a state machine which only allows certain commands to be accepted in certain states. State changes are initiated by sending certain commands or by the results from executing certain commands.

When an XPS motor is in the not-referenced state, nothing can be done with the motor until the home-search command has been sent. A message is printed during hardware configuration or when a move is attempted telling the user that the home command must be run.

Automatic home-search (when a home search is needed) can be enabled during spec hardware configuration by setting the non-standard optional controller parameter "auto_home" in the hardware configuration file. A value of 1 for the parameter will allow spec to send the home-search command during hardware configuration. A value of 2 will allow spec to send the home-search command any time it is needed.

spec will show warning messages if a move is halted by the controller putting a motor in the disabled state because of a following error (or several other conditions).

If a motor reports it is in the not-initialized state due to the error "both ends of run activated", spec assumes that to mean the motor is disconnected and disables access to that motor to avoid continued error messages. To re-enable access to the motor, it is necessary to fix the problem and restart spec or run the reconfig command.

It is recommended that backlash be configured in the XPS system file and the spec backlash parameter be set to zero in the spec config file.

The following motor_par() options are available:

motor_par(motor, "send", cmd)
Sends the string cmd to the XPS controller associated with motor.
motor_par(motor, "read", cmd)
Sends the string cmd to the XPS controller associated with motor, as above, and returns a string containing the response.