Frame Buffer Management for Streaming Point Motion

Introduction

This topic applies to XMP/ZMP controller for all OS commanding streaming point motion such as PT, PVT, Spline, and BSpline. It provides information on how the controller gets motion frames from the host computer. It also provides recommendations to optimize system performance. For MPI releases 03.03.08 and later (except 03.04.00), frame buffer management is only needed when commanding motion with a number of points larger than the buffer size minus 2. The default for buffer size is 128.

This document provides an understanding on how the host computer loads motion frames to the controller to effectively perform different types of streaming point motion. This application note is directed for applications with small time and/or position deltas between points.

The controller uses trajectory information (time of travel and initial position, velocity, acceleration and jerk) to move from one point to another. This trajectory information is packaged into a data structure called a frame. These frames are created by the application at the host computer. At some point, these frames are downloaded down to the controller memory before execution.

The controller memory will only hold a certain amount of frames at a time depending on the amount of available memory. The maximum amount of frames that the controller holds at a time is called the buffer size. This is important to understand for applications that stream points with small time and/or position deltas between points. When all of the frames cannot be loaded initially, the controller will send an event requesting more points to the host computer. It takes time for the host computer to download more points to the controller.

Terms and Definitions

Below is a screen shot from the vm3 utility of the parameters that are used in the frame buffer management. We are now looking at the controller’s memory. To get to the screenshot below, hit F3 after running vm3, then hit Ctrl+PgDown to view the Axis object memory.

MPIXMPData.Axis[n].TC.FrameIndex
The current executing motion frame index for axis n.

MPIXMPData.Axis[n].TC.LoadIndex
The frame index where the next motion frames will be loaded for axis n.

MPIXMPData.Axis[n].TC.Frame
Pointer to motion frames that currently reside in the controller for axis n.

MPIXMPData.Axis[n].TC.BufferSize
Specifies the maximum number of motion frames that can reside in the controller at one time for axis n. This value can be accessed through axisFrameCount in the MPIControlConfig structure using the mpiControlConfigGet /Set function. This value is configurable with a default buffer size of 128 frames. BufferSize must be a power of 2 (128, 256, etc). BufferSize can be set individually by each axis. When increasing the buffer size, check the available memory in the controller by looking at the Controller Summary Window in Motion Console.

MPIXMPData.Axis[n].TC.BufferLowLimit
When the number of frames left in the controller reaches this value, the controller will send a request to the host computer to load more frames. This value is only used when executing a streaming point motion such as PT, PVT, Spline, or BSpline.

For the default buffer low limit, please note the table in the Frame Buffer Size section.
For Trapezoidal, SCurve and Velocity moves, the motion profile has to fit in the controller’s memory since the controller has to calculate motion trajectory. Therefore, for these motion types, the host will not have to keep filling up the buffer.

Axis[n].TC.BufferEmptyLimit
When the number of frames left for axis n in the controller reaches this value and its value is greater than 0, the axis will generate an MPIEventTypeMOTION_OUT_OF_FRAMES event and the Motion Supervisor will generate an E_STOP action.

If BufferEmptyLimit is set to 0 or -1, then this feature is disabled and E_STOP action and MPIEventTypeMOTION_OUT_OF_FRAMES event will not be generated.
The valid range is zero to the controller's axis frame buffer size. This value is configurable through emptyCount in the MPIMotionPoint structure.

EmptyCount
Specifies the minimum number of points in the controller’s buffer to trigger an E_STOP and MPIEventTypeMOTION_OUT_OF_FRAMES event. EmptyCount is also referred as Axis[n].TC.BufferEmptyLimit.

Number of frames
To execute m number of PT, PVT points, the host computer will send (m + 2) number of frames to the controller. The one extra frame indicates the beginning of the move, while the other extra frame indicates the end of the move.

Running out of frames
Describes a situation where the motion program is not able to keep the point buffer primed with points. At this point, you will receive an MPIEventTypeMOTION_OUT_OF_FRAMES event and an E_STOP action is generated when bufferEmptyLimit is enabled, because the rest of the move is expected to be downloaded in the controller before the previous points run out.

Discussion

Inside the controller, motion frames are being stored in a circular buffer as shown below.

Frame Buffer Size

* This feature will be added in a future 03.04.xx patch release. It is not featured in the 03.04.00 Production Release. See the Release Notes section for more information.

Retain specifies whether or not the points should be stored in a buffer after execution.
If retain=0, the points will not be stored after execution.
If retain=1, the points will be stored in a buffer.
This feature is useful for backing up on path. Retain belongs to the MPIMotionPoint structure.

FramesLeftToBeExecuted specifies the difference between between LoadIndex and FrameIndex.

If (LoadIndex > FrameIndex)
FramesLeftToBeExecuted = LoadIndex - FrameIndex

Else
FramesLeftToBeExecuted = BufferSize + LoadIndex - FrameIndex

The number of frames that are left to be executed at the time that the request is made to the host computer is equal to the BufferLowLimit value.

Example for the 03.03.08 and later (except 03.04.00):

With a 512 frame buffer loading a long move,the first load is 510 frames (initial frame load max) and then 382 frames are loaded whenever there are fewer than 128 (BufferLowLimit) frames to execute.

Comments and Recommendations

To avoid receiving an MPIEventTypeMOTION_OUT_OF_FRAMES event, consider the following:

1. When commanding motion from an application running on a PC with an XMP installed or locally on an eXMP, Frame Buffer Management is rarely an issue. Since writes across the PCI bus are very fast, the major source of delay for downloading points is the host processor load. This can be partially managed by setting a higher Thread Priority for the Event Manager. Increasing the Frame Buffer Size may be required for moves with very short position or time deltas between points.



2. The eventMgr handles events and automatically loads more frames into the controller. The mpiEventMgrService(...) function checks the event source and makes calls to mpiMotionFrameBufferLoad(...) to load more frames (if the controller requests more). The eventMgr can be handled via the main task or a thread. It is either driven by polling or interrupts. If the application uses the serviceCreate(eventMgr, ...) function, then the eventMgr will be launched in a thread. The serviceCreate(...) function contains arguments to specify interrupts, thread priority, and polling period.



3. When using the client/server interface with streaming point motion, be sure to use a thread to manage the point list buffer. Do not poll the Point List Buffer management. The delays involved in polling can cause the Point List Buffer to run dry. To optimize performance, set the thread with an appropriate thread priority. The Service object in the apputil library provides a simple way to provide this type of threaded management.



4. When commanding a motion via client/server, additional delays will impact the time required to download frames. Although it is important to consider the host processor load and set the thread priority for the Event Manager accordingly, the factors that cause the majority of the delay are network speed, network traffic, and the overhead of running in client/server mode. Since these delays are unpredictable, Frame Buffer management becomes a more critical issue. Increasing the Frame Buffer size to greater than the longest possible point list will ensure that all points get downloaded before the motion begins. When this is not possible, increase the Frame Buffer size to the largest value possible to maximize the BufferLowLimit value and test this value in the tool or system. When possible, increase the time between points to provide more time per frame. In some cases, it may be necessary to modify the design of the application to have the mpiMotionStart(...) command called from the local host. Please contact the Applications Team for more information.
   
   

   NOTE: For releases prior to 03.03.08 and 03.04.00, the initial frame download will be a maximum of half the buffer size. For 03.03.08, 03.04.01 and later releases, the initial frame download will be a maximum of Frame Buffer size minus two. See chart above for more details on frame buffer size.

5. When using MPI Release 03.03.08 and future releases (please verify support in Release Notes), an increase in buffer size will result in an increase in the bufferLowLimit.



6. If the frames are not loaded in the time that is available to download points, an MPIEventTypeMOTION_OUT_OF_FRAMES event and E-STOP action will be generated.
   
   

   For example,
   bufferLowLimit value = 32
   emptyCount = 5
   Average Time Delta for each point = 2ms

   Time Available to Download Points = (BufferLowLimit – EmptyCount)*(Average Time Delta)
   = (32 – 5)*(2ms)
   = 54ms

7. If all the points for a move do not fit into the controller's buffer, you must set the emptyCount to a non-zero value. Any points that do not fit into the controller's buffer will be streamed from the host to the controller via the eventMgr. The controller monitors the emptyCount to determine if it will run out of points. If the number of frames left in the controller's buffer is less than the emptyCount, an E_STOP action will occur for all axes mapped to the Motion Supervisor. An E_STOP will decelerate the axes to a stop along the path of the controller's remaining points. The emptyCount must be set to a large enough value to allow the E_STOP to stop motion before the end of the point list is reached. For example, if each point takes 5 milliseconds to execute and an E_STOP is configured for 20 milliseconds, then emptyCount should be 4 (or higher).