Architectural Overview
Host Bus
Encoder Inputs
Digital-to-Analog Converter (DAC) Subsystem
Analog Inputs
SHARC DSP Processor Subsystem
Memory Organization
Faults and Resets
XMP Data Architecture
XMP Controller Motion Drive I/O

XMP Data Architecture

This section provides a dynamic look at the XMP's data architecture, between board components, and between the controller and external devices such as drive amplifiers.

XMP Power-up Sequence

When first powering-up the XMP controller, several actions initialize the controller according to the firmware's settings and prepare it for motion control.

Power is applied

During power-up, the host computer initializes. Power is also supplied via bus lines to the XMP controller and other devices connected to the PCI bus. The XMP controller's power supervisor waits for the bussed power supply to attain voltage thresholds (2.93 for 3.3 VDC power, and 4.63 for 5 VDC power) before powering the controller's components. Until power fully stabilizes, the board is kept in a reset condition.

Once initialized, the CPU bios polls the bus and assigns an address to each device (including the XMP controller).

PCI handshakes with SHARC DSP and Lattice

When the XMP controller's PCI receives a bus address from the host computer's CPU bios, it handshakes with the SHARC and Lattice.

FPGAs loaded

With the FPGA's file format determined, the SHARC loads both FPGAs with the following:

  • DSP variables (including default timing parameters)
  • FPGA image
  • SIM4 FPGA image (if a SIM4 module is installed)
Firmware loaded from flash memory into the DSP

With the FPGAs loaded, the controller is now ready to load the firmware from flash memory to the DSP.

DACs calibrated and activated

At the beginning of the power-up process, the digital-to-analog converters (DACs) are kept grounded (i.e., in an inactive, OFF state) until the controller is ready to switch them in. This avoids erroneous inputs-outputs with the drive. After the DSP is loaded, the DACs are internally calibrated and activated. The system may now accept input from the drives and send commands.


Controller initializes

The controller's boot configuration is based upon parameters stored in flash memory; these determine the controller's (and drive's) start-up behavior. One of the programmer's first tasks is to define what this "hello world" starting state ought to be immediately after power-up. In some instances, it may prove advantageous to keep a default boot configuration in flash memory, then modify it from the application during boot-up. In other instances, it may be better for the application to flash the controller's memory with an entirely new set of parameters during boot-up. The user must determine the best approach.


Controller configuration can be done using Motion Console; however, during development of an application, it is the programmer's responsibility to write code that properly configures the controller for its next session upon exit of the application. The controller should utilize safe amp enabling and hardware I/O to prevent runaway conditions during start-up.


For this example, we will assume the following safety measures:

  • The drive is configured for active high amp enabling. (That is, the drive cannot be enabled without controller input.)
  • The controller is configured to awaken with the Amp Enable line set to low (off). This should keep an active high drive disabled.
  • The controller is configured to trigger an Abort if the Position Error is greater than some specified value. Because the controller's data registers are all set to zero at start-up (including the Command and Actual Position values), any mechanical movement will produce a Position Error. By triggering an Abort based on Position Error, the controller safeguards against uncommanded moves.2
Device Driver and Operating System Loads

At this point, the XMP controller is initialized and ready for use. The next and final phase of the power-up sequence is the loading of the XMP's device driver and operating system on the host computer. This must be completed before any motion control application can be loaded and run.

The XMP controller's device driver is shipped to load manually; however, it can be reconfigured to load automatically. To view the XMP's device driver, access your operating system's Devices window. (In WindowsNT? environments, the XMP controller's device driver is labeled as MeiXMP.)

The operating system completes its loading within several seconds of the XMP's initialization.

Load Motion Control Application
Application boot-up

When a motion control application (e.g., Motion Console) is loaded, it first verifies that the XMP controller is operational. The user interface is displayed and is now available for use.

Create Control Object and Initialize Controller

Before any motion application can move axes, it must create a controller object and initialize communication. This is a standard requirement for any application which intends movement.

Homing the Motion Control System

Homing is the setting of a coordinate system through detection of a known point in space (the "home" point). A home point can be defined using a limit switch, or by detecting a signal from the encoder such as a home or index pulse. This is typically the first act a controller must perform before running the main application code.


Before homing, objects must be created and the controller must be initialized (see above). One example of a homing sequence is shown below, consisting of:

  • Configure a capture to trigger off the home input.
  • Configure a home event action.
  • Arm the capture.
  • Command a velocity move while polling the capture trigger.
  • When the trigger changes (at the home point), set the origin.
  • Move the axis to the origin.

This homing example is taken from the home1.c sample application program, which may be found in the Sample Applications module and should be studied. For sake of clarity, excerpts are included below.

Configure the Capture trigger

After the motion objects are created and the controller is initialized, the MPI must configure and arm a capture. The trigger in this example is a home sensor (limit switch) on a stage.

Define motion parameters

In preparation for commanding moves, there are several motion parameters which must be defined:.

Two types of moves are used for this sample homing routine: a velocity move and a trapezoidal move. The velocity move consists simply of running the axis at a set velocity, hunting for the home point, without regard to its starting and ending positions.


Because a trapezoidal move requires beginning and ending positions (and we don't know the axis coordinates until the home point is detected), the first move must be a velocity move. After coordinates are established through detection of a home point, a trapezoidal move may be used to move the axis to the origin.

Configure the home event action

The "home event" is the what we use to detect the home point. The home event could be an input from a limit switch, triggered when the axis runs into it. The home event could be a home or index pulse on the encoder. For this example, the stage's HOME switch is used as the trigger, and the trigger's input is configured to be TRUE (active edge).


The "home action" is what happens when the home is detected. In this example, the programmer has decided to define the action as a command to STOP the axis.

Arm the trigger

With the home event and action defined, all that is left is to "arm" the trigger by setting the mpiCaptureArm to TRUE. Recall that earlier, this was set to FALSE to "disarm" the system.

Start a velocity move

With the capture event and action defined, and the trigger armed, we are ready to hunt for the home point. This is accomplished by commanding a velocity move. Before the axis can be commanded, however, the XMP controller must first enable the drive. In this example, it is assumed that the drive is wired to be an active high type; therefore, the Amp Enable line is set to high (on). Drive enabling via software must be done as a separate code item and is not shown here:

As the leadscrew rotates, the slide approaches the home sensor.

Poll trigger status

With the trigger armed, the software's next task is to poll the status of the trigger while the axis continues rotating.

Home event detected

As the axis motor continues turning, the leadscrew rotates until the stage makes contact with the home sensor; this acts as the trigger. When the trigger event is detected, the encoder position is captured and a stop action is initiated.

Define the home position as the origin

When the home pulse is detected in our example, another simultaneous action is initiated: the axis's position is captured by the FPGA. At this point, the axis position is recorded in memory. Meanwhile, the axis slows to a stop. The mpiAxisOriginSet command is then used to set the capture position to zero, making it the new origin of the axis's coordinate system.

Move axis to the (new) origin

Our sample homing routine's last task is to move the axis to the origin. Recall that the home pulse was detected while in motion, and that after detection, the axis coasted to a stop. This means that the axis is now somewhere beyond the home point (our new origin).


Because we now have a coordinate system, we can perform a backward trapezoidal move from the current position to the intended position (the origin).

Delete Objects

Finally, the homing routine must delete the objects it has created. This is performed with a number of deletion objects such as mpiMotionDelete,
mpiAxisDelete, mpiMotorDelete, etc.

Internal Data Movement via "Riptide"

Within a typical SHARC timer cycle, data is moved back and forth between the SHARC and the FPGAs and various feedback devices (e.g., encoders, resolvers, etc.). On the XMP controller, this is performed over a proprietary, dedicated data bus called the "Riptide." The Riptide is the serial backbone of all motion data flow. Within a given SHARC cycle, data moves first from the SHARC to the FPGAs, and then to the drives. Within the same cycle, data is moved in the opposite direction (inbound) from the drive and encoder(s) to the SHARC.

As more drives and encoders are added to the motion control system, the required data bandwidth increases across the Riptide, occupying a greater portion of the foreground tasks.


2. IMPORTANT! Use of Position Error and other positional inputs as safeguards assumes: a) good data connection between the encoder(s) and controller; b) normal conditions. If a higher level of safety is required, then extra measures should be utilized, such as broken encoder wire detection.

Return to Hardware's Main Menu