CoreMotion™
This page provides an overview of CoreMotion's key concepts, introduces key concepts, gives an overview of the main utilities, and identifies the basic sequence of tasks that a new user will need to execute in order to get a machine using CoreMotion up and running. Anyone new to CoreMotion is encouraged to read this page carefully and in its entirety before using CoreMotion or browsing the rest of the documentation.
Overview and Key Concepts
CoreMotion is a technology for bringing real-time motion control into a PC. It consists of a real-time engine, a number of utilities, an application programer's interface, and an abstraction layer to a physical machine's controls (motor drives and I/O). The following figure provides a high level overview of the system.
A basic understanding of the key components shown here is essential to becoming a competent user of CoreMotion. Those components are defined as follows:
Core Motion Engine
The main process for CoreMotion is the CoreMotion Engine. This is a real-time process that runs continuously at a fixed scan period (also called the servo rate). Each scan interval is initiated by an interrupt usually generated by some external servo clock. The engine then wakes up, reads the current state of the hardware (encoder values, inputs, etc.), performs calculations, and then writes new values to the hardware (commanded torque, output values, etc.).
Shared Memory
Because the engine requires real-time performance, it requires that a real-time kernel be installed on the PC in addition to one of Microsoft's Windows operating systems. Thus, you can think of a PC with CoreMotion as having two operating systems. The most efficient way to communicate between these two operating systems is shared memory. One way to think of the Core Motion Engine as a simple real-time scheduler that manages a number of objects. The objects that are managed by the engine are created in shared memory that is visible to both the real-time kernel and Windows applications.
CoreMotion Application Programmer's Interface
Allowing applications to directly modify the objects in shared memory would be both difficult to understand and dangerous. Instead, CoreMotion provides an application programmer's interface for manipulating these objects. The interface is written in C++ and is sometimes referred to as CAPI. A C wrapper is also provided for those who prefer a standard ANSI C interface. All applications and utilities communicate with the engine via this API. There is a version of CAPI available as a DLL for Windows applications and another version available as a static link library for real-time applications. All of the standard CoreMotion Utilities use the Windows DLL.
CODE
CoreMotion was designed to run as both a standalone product and as a low level motion controller to Cimetrix's CODE product. CODE provides many advanced features not available to CoreMotion standalone. A partial list of these features includes inverse kinematics, continuous path, motion queues, conveyor tracking, machine calibration (accuracy enhancement), spatial modeling (node model), geometric modeling, interference checking, and graphical simulation. When CoreMotion runs standalone it uses its own trajectory generator. However, when CoreMotion is used with CODE, CODE generates the trajectories. This is necessary to take advantage of CODE features such as continuous path and conveyor tracking. This means that CODE must also run as a real-time process (see figure above).
CODE Application Programmer's Interface
CODE has its own API, so when CoreMotion is used with CODE, CAPI is not used by the application programmer. The CODE API is a mature API available in C++, C, VB, Borland Delphi and all of the IEEE 1934 languages (PLC languages). In addition to the unique features of CODE, the CODE API supports nearly all of the features of CoreMotion standalone. CAPI is a new API that is still being refined by Cimetrix. As such, Cimetrix has chosen not to publish CAPI for general use just yet. So, while CAPI is used by all of the CoreMotion utilities, and is used by CODE for the interface between CODE and CoreMotion, it is not yet available to application programmer's. Thus today, the CODE API is the only officially supported programmer's interface to CoreMotion.
The Configuration Utility and Wizard
The first CoreMotion utility you will need to use is the Configuration Tool.
It has two modes of operation, A wizard mode for creating a new configuration
and a browser mode for modifying an existing one. Since CoreMotion has hard
real-time requirements, it does not allow memory allocation when the engine is
running (creation of new shared memory objects). When the Configuration Tool
starts up, it first checks to see if there are already CoreMotion objects in
shared memory. If there are none, then it knows the engine is not running and
it starts in the wizard mode. The wizard then walks the user through the
creation of a new set of objects. Once the user has identified all of the
desired objects, the wizard automatically configures these objects to a default
configuration. The wizard then starts the engine and switches to the browser
mode. The wizard mode can only run when the engine is not running.
If the Configuration Tool finds that there are already CoreMotion objects in shared memory, then it starts in the browser mode. The browser mode allows the user to interactively change the configuration of the existing objects, with or without the engine running, but it does not allow new objects to be instantiated or existing objects to be destroyed. Once the objects have been configured, the Configuration Tool allows them to be saved to a file. As these files represent an image of what is in shared memory, we refer to these files as "image" files. Image files are stored in XML format and have a .xml extension.
Memory Viewer
Memory Viewer is the lowest level tool for viewing and configuring memory. While the Configuration Tool only lets you view and edit selected object attributes that are intended to be configured by the user, Memory viewer shows you all of the objects and all of their data and attributes. Its primary purpose is for viewing the current state of the system and for in-depth diagnostics, but it also allows you to change virtually anything in the system. However, unless explicitly instructed to do so by Cimetrix, new users should never edit objects this way. Use memory viewer as a viewer only and do your configuration using the Configuration Tool.
The CoreMotion Classes
So far we have introduced the concept of CoreMotion objects and discussed utilities for creating and editing them, but we have not introduced the object classes themselves. The important standard classes are as follows:
axis - The axis class implements a logical axis and stores properties that faciliate motion control.
axisGroup - Axis Groups are objects that contain a list of Axis objects. The primary purpose of the Axis group object is to provide coordinated path planning for its group of axes. Axis objects can be members of any mnumber of Axis Groups.
digitalInput - Interface to a hardware digital input
digitalOutput - Interface to a hardware digital output
analogInput - Interface to a hardware Analog to Digital converter
analogOutput - Interface to a hardware Digital to Analog converter (DAC)
encoder - The encoder class provides an interface to feedback sensors including data filtering to smooth velocity prediction from slow moving encoders
motor - The motor class maps the physical hardware to the logical axis.
pidControlLaw -This class implements a PID controller with velocity,
acceleration and friction feedforward as well as a number of additional limiters
and filters
observer - Observers are configurable watchdogs that run at the servo
rate. They look for a specified set of conditions, and when those conditions
become true, they execute a list of commands or actions (Mappers in CoreMotion
terminology). All observers have an active flag that turns them on or off as
well as both state and latched state information. State information is updated
every servo clock tick to reflect the current state, whereas the Latched State
becomes true whenever the observer conditions are met and the observer executes
its action. The Latched State remains true until it is explicitly reset AND the
observer conditions are no longer met. Observers can be assigned to a particular
axis. The Configuration Wizard gives options to create up to six standard axis
observers to look for things like limit switches, amp faults, feedback broken
wire detection, etc. Users can also create their own observers and associate
these custom observers with an axis.
mapper - Mappers are commands that preform operations on one variable
and place (map) the results into another variable. They can be active, in which
case they execute every servo cycle, or they can be inactive, in which case they
are executed by some supervisory object such as an observer.
dataCollector - This class gathers the state of a number of variables at multiples of the servo clock. As an example, Core Scope uses a dataCollector in order to gather and plot things like following error or CPU load as a function of time.
userLong - This class provides integer storage for user applications, observers, and mappers.
userFloat - This class provides real number storage for user applications, observers, and mappers
eventQueue - This class implements a queue of events used to notify applications that something they are intereset in has occured. Events are used to communicate between the CoreEngineTask and CAPI clients, events are not used when CoreMotion is used with CODE.
event - This class implements the events held in the queue defined above
system - This class implements a singleton object that contains useful system level information.
Motion and I/O Abstraction
In addition to the standard classes listed above, there will be at least one derived class for interfacing CoreMotion to a specific class of hardware. CoreMotion was designed to be interfaced to virtually any motion control hardware including both digital and analog drives. This interface is accomplished by specializing the base hardware interfae class. CoreMotion currently ships with one such specialized class for interfacing to Delta Tau's PC servo card. This servo card provides an analog drive interface. This class is as follows:
pcServoCard - This class implements the interface to Delta Tau's PC Servo Card. This is an analog drive, incremental incoder interface card for up to 8 servo axes as well as several general purpose I/Os.
Tuner
Once the basic configuration is created, it is time to start tuning the servo loops and testing the system. Tuner is the tool for this. From the tuner you first select an axis group and then you select an axis from that group. You can then modify the control law parameters (gains), enable/disable the amps, open/close the servo loop, and define and execute test moves.
Scope
Scope is a tool that allows you to look at the state of the system as a function of time. It functions much like a digital oscilloscope, letting you plot anything in shared memory. With scope you define groups of up to 16 traces which can be simultaneously viewed. Each trace has its own scale and color. You can define multiple groups and quickly switch between groups. You can look at the system in real-time, or you can record the traces for a specified amount of time. Recorded traces can be exported so that they can be viewed in other applications such as Microsoft's Excel. Recorded traces can be started manually or they can be triggered by an event such as an I/O bit changing state. Scope is most often used as part of tuning, where you can observe things like following error, overshoot and settling time. But it is really a very general purpose tool that lets you look at anything including real-time performance and the CPU load due to motion control.