Release Note
MPI Library Version 03.01.01.B2.12

Description:
Support has been added for the AMC Drive DQ111RE. Changes were made to the amc_digiflex.c drive module.

How do I use this feature?
For more information about the AMC Drive DQ111RE, please contact Advanced Motion Controls.

Description:
Support has been added for the AMC Drive DQ113EE. This drive is similar to the rest of the DQ-series family with the exception of its I/O (4 outputs, 12 inputs). Changes were made to the amc_digiflex.c drive module.

How do I use this feature?
For more information about the AMC Drive DQ113EE, please contact Advanced Motion Controls.

Description:
The Kollmorgen CD Drive now has Probe support.

How do I use this feature?
Please see the Probe object.

Description:
The RMB-10V2 now has Probe support. In order to use Probe with the RMB-10V2, you must download the C0FE0033 FPGA. In order to have enough space for the Probe feature, Pulse support was removed from the C0FE0033 FPGA.

How do I use this feature?
Please see the Probe object.

Description:
The following new Can commands have been added to meiCanCommandType.     
     MEICanCommandTypeNMT_ENTER_PRE_OPERATIONAL
     MEICanCommandTypeNMT_START_REMOTE_NODE
     MEICanCommandTypeNMT_STOP_REMOTE_NODE
     MEICanCommandTypeNMT_RESET_NODE
     MEICanCommandTypeNMT_RESET_COMMUNICATION

These new Can commands allow each of the CANOpen protocols NMT commands to be issued from the host. These replace the original MEICanCommandTypeNMT_STOP and MEICanCommandTypeNMT_START commands.

How do I use this feature?
The new NMT_ENTER_PRE_OPERATIONAL and NMT_START_REMOTE_NODE commands are used in the same way as the original NMT START and NMT_STOP commands.

Description:
The controller's axis frame buffers are now configurable on a per axis basis.

This feature is useful when frame buffers greater than the default 128 frames are required, such as when the axis Camming feature is used.

How do I use this feature?
The number of frames allocated for any one axis MUST be a power of 2 (128, 256, 512, etc...)

WARNING!
Due to the nature of dynamic allocation and the clearing of external memory buffers, mpiControlConfigSet(...) should ONLY be called at the time of motion application initialization and NOT during an motion.

Description:
To simplify the setup and initialization process, the CANOpen I/O nodes from MEI support an auto-detect bit rate feature that automatically detects and sets the appropriate bit rate for the CAN Network Adapter. For more information, please see the SLICE I/O Quick-Start Guide: CANopen.

To support CANOpen nodes that support auto-bit rate detection, CAN firmware versions from 2B1 and onwards now work with nodes that support auto-bit rate detection.

How do I use this feature?
The auto-detect bit rate feature is only supported with CAN firmware CAN002B1 and later.

Description:
Version.exe now reports the vendor ID, product code, version number and serial number of all the nodes on the CANopen network. You can use version.exe to quickly identify the type of node on the CAN network and what version of CAN firmware is being run on the CANopen node.

How do I use this feature?

Description:
CAN Node Version calls have been added to the MPI. The addition of these fields will allow you to quickly identify the type of node on the CAN network and what version of CAN firmware is being run on the CANopen node.

How do I use this feature?
Please see the documentation for the MEICanNodeInfo method.

Description:
Support has been added for re-mapping secondary encoders to different motors on the same node. Please see the documentation for the meiSqNodeConfigSet(...) method.

How do I use this feature?
Please see the documentation for the meiSqNodeConfigSet method.

Description:
Manufacturer and User Fields added to the EEPROM as specified in the Node ID specification. This feature should be used for reading and writing both manufacturer and user information to the node EEPROM.

How do I use this feature?
This feature should be used to store vendor and user specific information on the node.

Description:
For more information, please see the following pages:
Camming: Master-Slave Concept
Camming: General Information
Camming: Correctional Moves

How do I use this feature?
Refer to the links above.

Description:
The lengthy MEIControlVersion structure was divided into several MEIControlInfoX structures.

How do I use this feature?
For more information, see MEIControlInfo.

Description:
A new Compensator object has been added to the MPI to handle Axis position compensation based on compenstion values loaded onto the controller.

How do I use this feature?
Please see the MPI Software Documentation for more information.

Description:
The ability to disable the encoder filter on quadrature encoders has been added to MEIMotorConfig. This feature should be used to enable or disable the quadrature encoder filter.

How do I use this feature?
To disable the filter, set filterDisable to TRUE.

Description:
An AmpWarning event has been added to MPIEventType. This feature should be used to trigger motorEvents off of the AmpWarning bit, which is returned by the drive through the Dedicated I/O word.

How do I use this feature?
The configuration and reporting of the AMP_WARNING event behaves identically to the AMP_Fault event. To configure the event type, use MPIMotorConfig. To check the status of the event type, use mpiMotorStatus.

Description:
Support has been added for the ZMP-series controllers. The ZMP-series is a new high performance SynqNet controller. It supports the same features as the XMP-series and uses the same MPI Library. There are currently no differences in MPI methods or data structures for the ZMP controllers. The main difference between the XMP and ZMP controllers is performance. In general, ZMP controllers can be operated at sample rates from 4 to 8 times the rates for XMP controllers.

The ZMP can be used in place of XMP controllers for applications with performance requirements that exceed the limits of XMP controllers.

How do I use this feature?
The installation of ZMP controllers is identical to that of XMP controllers. Please see the ZMP Hardware Quick-Start Guide for details.

Description:
MoveID and ElementID have been changed to 16-bit resolution. The 16-bit limit on both the MoveID and ElementID was implemented because there was not enough room to support 32 bits for each of the MoveID and ElementID parameters in both the positive and negative frame directions.

For both the MoveID and ElementID, there is now support for 32 bits in both the positive and negative frame directions. For example, in a frame, the lower 16 bits of the MoveID field represent the MoveID for the positive frame direction. The upper 16 bits represent the MoveID for the negative direction.

How do I use this feature?
The basic functionality of MoveID and ElementID has not changed. The only change is that the MoveID and ElementID values are limited to 16 bits. The user does not need to change their implementation (other than to choose IDs that are limited to 16 bits). This is a lower lever implementation issue.

Description:
meiSqNodeAnalogIn(...) has been changed to meiSqNodeAnalogInput(...). This method should be used to read analog inputs located on the Node. It is used on an application level to read analog inputs.

Description:
The MEI object config method and object flash config method interfaces have been changed to be consistent with the MPI object config and flash config methods.

NOTE: This change breaks backwards compatibility for the effected MEI config methods. Your application may need to be recompiled.

In addition, the meiCanFlashNodeConfigGet/Set methods have been depricated in this release. While these methods are still supported, MEI reserves the right to remove depricated methods. Your application should use the new meiCanNodeFlashConfigGet/Set methods if you plan to upgrade to future versions of the MPI.

Description:
The MPI version numbering has been updated from date codes (YYYYMMDD) to a more traditional numbering scheme (Major.Minor.Release). Please see MPI Version Numbering for details. The Software Release Types have also been formally defined. Please see MPI Release Types for details.

Description:
In xmp.h, the MEIXmpIOFrame data type was deleted and the MEIXmpHoldFrame data type was created as a replacement. The functionality has not changed and should be used the same way for triggers.

In xmp.h, the MEIXmpOutputFrame data type was created. It is essentially the same as MEIXmpIOFrame, except Mask is now OffMask and Pattern is now OnMask.

As a result of these changes, MEIMotionAttrOutput was modified accordingly.

How do I use this feature?
This feature should be used when there is a frame set or to clear an output.

For MEIMotionAttrOutput:

OffMask - any bits that are SET will be turned off.
OnMask - any bits that are SET will be turned on.

The OffMask is applied first: output & = ~OffMask
For Output frames, bits Set in the OffMask are turned OFF and bits Set in the OnMask are turned ON.

The order of operations should be:
     output &= ~OffMask;
     output |= OnMask;

Since the OnMask is applied last, the OnMask has precedence. If a bit is set in both the OffMask AND the OnMask, the result is that the bit is turned ON.

Description:
The digitalInputCount and digitalOutputCount fields of the MEICanNodeInfo structure report the number of digital inputs and outputs a node supports. The CANOpen protocol only allows the number of digital inputs and outputs to be interrogated in multiples of eight (i.e. if a node has two digital inputs then digitalInputCount will return eight). For MEI CANOpen Slice nodes, an extension to the CANOpen protocol is supported that allows the exact number of digital inputs to be returned in this field. The CAN firmware on the XMP (versions 2A7 and higher) has been modified to use this field if it is available.

Nodes that don't support this feature (i.e. nodes not made by MEI) are still supported, the only difference is that the number of digital inputs and outputs will still be reported in multiples of eight.

How do I use this feature?
The digitalInputCount and digitalOutputCount fields of the MEICanNodeInfo structure report the number of digital inputs and outputs a node supports. The CANOpen protocol only allows the number of digital inputs and outputs to be interrogated in multiples of eight, i.e. if a node has two digital inputs then digitalInputCount will return eight.

For MEI CANOpen SLICE I/O nodes, an extension to the CANOpen protocol is supported that allows the exact number of digital inputs to be returned in the digitalInputCount field. The CAN firmware for the XMP has been modified to use this field if it is available. Nodes that do NOT support this feature (i.e. nodes not made by MEI) are still supported, the only differance is that the number of digital inputs and outputs will still be reported in multiples of eight.

For more information, see MEICanNodeInfo.

Description:
Allow MPI to set RESUME anytime a STOP is in progress or finished. MPI does not allow RESUME while STOPPING, only when STOPPED. This feature is helpful for an immediate RESUME after a STOP has been commanded without having to wait for a STOP to complete.

How do I use this feature?
Use mpiMotionAction() as normal for an immediate RESUME after a STOP has been commanded without having to wait for STOP to complete.

Description:
MPIMotorEventTrigger.encoder changed from "long" to MPIMotorEncoderFault.

How do I use this feature?
For more information, see MPIMotorEventTrigger.

Description:
Encoder "phaseReversal" was moved from MPIMotorConfig to MEIMotorEncoder, thereby allowing the user to loop through the array of encoder configurations. This change cleans up the design considerably and was necessary because the encoder phase is dependent on the encoder type. Therefore, encoder phase and encoder type needed to be grouped together. Currently, phase reversal is only applicable to quadrature feedback.

How do I use this feature?
For more information, see mpiMotorConfigGet/Set.

Description:
In previous versions, feedforward values were passed to the controller with each point for PTF and PVTF motion. These values were constant during the interval between points. Improvements have been made so that the values can now be interpolated linearly over the interval. The motion types MPIMotionTypePTF and MPIMotionTypePVTF, support user-specified feedforward values for each point. The following improvements have been made to the PTF and PVTF motion types.

• The feedforward values are interpolated linearly over the PT or PVT time intervals. The feedfoward values correspond to the P or PV values. (i.e. When the motion reaches a specified position (PTF) or position and velocity (PVTF), the interpolated feedforward value will be equal to what is specified in the motion parameters.)
  
  
• The feedforward values are not set to 0 at the beginning of the move; they retain the last value that is specified in the PTF or PVTF motion parameters.
  
  
• The feedforward values are not changed by non-PTF or PVTF moves. Previous versions of the firmware would set the feedforward value to zero for any move that was not a PTF or PVTF move (i.e. PT, PVT, Spline, S-Curve, etc.).
  

How do I use this feature?
See MPIMotionPTF and MPIMotionPVTF.

Description:
The Capture source enum (MPICaptureSource) used to specify triggers sources for the capture engine.

The enumeration for the capture sources has been reordered so that the I/O sources are listed first. As a result, the value for MPICaptureSourceMOTOR_IO_0 will correspond with the value for MEIMotorIoConfigIndex0. In the future, we will improve the way I/O labels, masks, and sources are presented to the user. I/O capture sources will also be modified.

How do I use this feature?
This feature should be used to configure the capture engine. For more information, see MPICaptureSource.

Description:
In previous versions, velocity moves to zero velocity would cause the motion supervisor to remain in the MOVING state. The MPI library has been modified so velocity moves to zero velocity will cause the motion supervisor to go to the IDLE state (when the settling criteria has been met).

How do I use this feature?
This feature affects velocity move calls to mpiMotionStart() and mpiMotionModify().

Velocity moves to zero velocity will now result in an MPIStateIDLE state rather than MPIStateMOVING state at the end of motion. As a result, an MPIEventTypeMOTION_DONE will be generated now instead of an MPIEventTypeMOTION_AT_VELOCITY event.

The state and events generated when velocity moves of zero velocity are specified are different. You may have to modify how an application waits for these velocity moves to be completed.

See Also
mpiMotionStart, mpiMotionModify

Problem/Cause:
Intermittently, the latched capture position in either position or time mode would be incorrect. This failure typically occurred within 5,000 to 20,000 capture cycles. The capture problem was caused by incorrect ordering in the capture status and capture data packets, which would cause intermittent "stale" capture data. As a result, the latched capture position would use the previous captured value.

Fix/Solution:
Changes were made to the MPI to fix this problem.

Problem/Cause:
mpiFilterGainSet(...) returns an MPIMessagePARAM_INVALID message when run over client/server or when run on a ZMP-SynqNet controller.

Fix/Solution:
Changes were made to the MPI to fix this problem.

Problem/Cause:
If the old and new command positions have the same sign and the new position is a non-integer and closer to zero, then mpiAxisCommandPositionSet(...) would return MPIAxisMessageCOMMAND_NOT_SET.

Fix/Solution:
This problem has been fixed. mpiAxisCommandPositionSet(...) now truncates the new command position to an integer before sending the position to the controller. If a different type of rounding is desired, then it should be implemented by the application prior to calling mpiAxisCommandPositionSet(...).

Problem/Cause:
When VM3 was used to load a *.dmp, an assert was generated. VM3 was calling mpiControlInfo, which attempts to access T numbers and serial numbers from the board. When no controller was present, an unexpected error state was returned.

Fix/Solution:
If the control type is MPIControlTypeFILE, platform.c fills out the controller information with 0's. Dump files can now be loaded from ZMP's and XMP's.

Problem/Cause:
Multi-point moves with appends would get an unexpected error state. This problem occured when a velocity move with hold gate was commanded after a PVT move with an append was commanded. This problem was due to an uninitialized "stopper" frame, which was added to a multi-point move when the final points had not yet been loaded. The "stopper" frame is a safety measure, which ensures that if the host cannot load points to the controller for some reason, then the move will come to a controlled and known stopped state.

Fix/Solution:
This problem has been fixed.

Problem/Cause:
Step commands were incorrectly written to SynqNet packets. This was caused by big/little endian issues with the ZMP. As a result, the MPI was not correctly calculating the pulse output pointer. Also, the code in the firmware would not work for big endian hardware.

Fix/Solution:
The MPI was modified to correctly calculate the ZMP pulse output pointer. A new function was added that adjusts the pointer for the ZMP, but does not adjust the pointer for the XMP. The firmware was also modified to work properly for big endian hardware.

Problem/Cause:
Multi-point motion (such as PVT motion) does not work correctly with frame buffer sizes other than 128 frames. The problem is due to the internal axis frame buffer continuing to rollover at 128 frames even though the frame buffer is of another size.

Fix/Solution:
This problem has been fixed.

Problem/Cause:
The presence of the CAN Hardware is falsely reported if the XMP firmware does not match. The code to detect the presence of CAN hardware can sometimes falsely report that the CAN hardware exists with certain older versions of the XMP firmware.

Fix/Solution:
This problem has been fixed.

Problem/Cause:
Motor resources were being retrieved for a motor that did not exist. This problem occurred because there was no check for whether or not the capture motor existed.

Fix/Solution:
There was a check added to validate the motor being used. If a capture is being configured on a motor that does not exist, then an error is returned. See MPICaptureMessageMOTOR_INVALID for more information.

Problem/Cause:
If a capture engine was first configured to capture on the rising edge and then later configured to capture on the falling edge, the capture engine would capture on either edge.

The FPGA register used to configure the edge trigger also contains other configuration bits. Bits 0 and 1 were used to configure the edge. Values: 1 = rising, 2 = falling, 3 = both, and 0 = none. The configSet code was NOT clearing out these bits. As a result, the edge being configured was OR'ed into the register. Therefore, if it was configured for rising and then later configured for falling, both the 1 and 2 bits would be set in the register giving it a value of 3 so that the capture would look like was configured for both. The only way to clear out the register was to configure it for edgeNone.

Fix/Solution:
The FPGA Capture edge register is now cleared out before it is configured so that any old configurations are erased.

Problem/Cause:
The deceleration is incorrect if the velocity at the deceleration point does not match the maximum velocity specified in the path configuration.

In earlier version, the path module would compute the path (series of points equally spaced in time) using a two step process. First, the total length of the path was calculated by determining the locations of equally time-spaced points with no deceleration at the end of the path. Once the total path length was determined, the point along the path to start the deceleration was computed (decelPoint = total length - v*v/2*d). The velocity and deceleration used for this calculation was taken from the max velocity and deceleration in the path configuration. If the actual velocity at the decel point was lower than v, the distance needed to stop would be overestimated and the actual deceleration would be too low (lower than d). If the actual velocity was greater than v, the true deceleration would be higher than d. This could only happen if the velocity specified for an element was different that that of the path configuration.

Fix/Solution:
This problem has been fixed so that the actual deceleration at the end of a path matches what is specified in the path configuration. After the total length of the path has been determined, the deceleration point is now calculated by constantly comparing the v*v/2d with the distance left in the path, where v is the current velocity (velocity for the current time slice) and d is from the path config structure.

Problem/Cause:
If the CAN firmware is not loaded, then events are not serviced correctly in the mpiEventMgrService(...) method.

Fix/Solution:
No header files were changed.

Problem/Cause:
There was a possibility of accidentally confusing Trust I/O with MEI Dedicated I/O because of their similar naming conventions.

Fix/Solution:
Changed Trust I/O names from Hall A,B,C to Hall U,V,W to avoid confusion with MEI's dedicated I/O. Changed the I/O enumerations in trust.h

Problem/Cause:
MotionModify of velocity frames during the first sample of execution for the velocity frame will cause a position jump when the next frame (usually the accel frame) is executed. This problem was caused by a mismatch between time and position values in firmware during the first sample of a velocity frame.

Fix/Solution:
This problem was fixed by zeroing the time value in firmware when advancing from a frame (before the velocity frame) into the velocity frame, as long as the velocity frame is not being modified or has not been modified.

Problem/Cause:
The Axis object's Motion Supervisor pointer was not mapped to the parent Motion Supervisor before frames were loaded by the MPI during path motion. This meant that the pointer could be pointing to another Motion Supervisor. If this occured with two axes on one Motion Supervisor, it is possible that one of the axes will start executing frames early. This will cause the axis and Motion Supervisor state machines to lock up and motion to never start.

Fix/Solution:
MPI was modified to tell the firmware to map the axis object's Motion Supervisor pointer BEFORE bumping the frameIndex when loading frames for path motion.
In previous versions, MPI calls meiMotionXmpAction(...) with a bogus action. Firmware will map regardless of what action is used. For the main tree, MEIXmpActionMAP was created for the MPI to be used with meiMotionXmpAction(...). In all cases, the call to MeiMotionXmpAction(...) is made just before bumping the frameIndex.

Problem/Cause:
Path motion trajectories may have very small (~1E-10 c/sample) velocities for axes that are not moving in a multi-axis system. This is caused by computational roundoff and has no effect on the command position. However, the friction feedforward value will not be zero unless the command velocity is zero as well. This has caused oscillation in the DAC output as the velocity ranges between very small limits.

Fix/Solution:
The simple algorithm used for FFF calculation was:
     output = 0 if v == 0
     output = Kfff if v > 0
     output = -Kfff if v < 0

The algorithm used for FFF calculation was revised to:
     output = 0 if |v| <= 0.001 counts/sec
     output = Kfff if v > 0.001 counts/sec
     output = -Kfff if v < -0.001 counts/sec

Problem/Cause:
meiSqNodeDriveMonitor(...) was not returning the correct monitor values. The problem was caused by an unitialized variable, driveOffset, in meiSqNodeDriveMonitor(...).

Fix/Solution:
This problem was fixed by initializing the driveOffset. meiSqNodeDriveMonitor(...) now returns the correct monitor value.

Problem/Cause:
meiFilterConfigSet(...) did not write the MEIFilterConfig.PostFilterForm to the controller's memory.

Problem/Cause:
An internal, small constant (epsilon) was being used for both postfilter section conversion and identification. One operation favored a larger value while the other favored a smaller value.

Problem/Cause:
There are three new error codes related to the meiFilterPostfilter methods:      MPIFilterMessageCONVERSION_DIV_BY_0
     MPIFilterMessagePOSTFILTER_NOT_ENABLED
     MPIFilterMessageINVALID_FILTER_FORM

For more information, see MPIFilterMessage.

In the past, the conditions that caused these errors would return an ambiguous MPIMessageFATAL_ERROR error message.

Problem/Cause:
There was a previous bug in the device driver that had a workaround that avoided the problem. By disabling interrupts everytime the service thread (apputil/service.c) exited the bug was avoided.

But, this workaround had a negative effect where an exiting process using the service thread (interrupts) would potentially disable interrupts for another running process using interrupts. Certain combinations of processes beginning and exiting can cause bugchecks (BSOD) on Win32 systems.

Problem/Cause:
XMP addresses specified by the user of the MPI should always be interpreted as host addresses as opposed to firmware addresses. In previous versions, MEIMotorEncoder.reverseModulo.Ptr and MEISqNodeConfig.userFault.addr were interpreted as firmware addresses instead of host addresses.

Problem/Cause:
If the user tried to invert the feedback on an encoder type that did not allow for feedback inversion, an error message would not be returned. The problem occurred because mpiMotorConfigSet(...) did not have any encoderType checking.

Problem/Cause:
In previous versions, the brake would quickly toggle off/on during a controller reset after the topology had been saved. The toggle would occur once the SynqNet initialization process had been completed (after a controller reset). This unintended toggle of the brake was a result of the motor I/O having the brake RELEASE bit set as its default.

Since it takes a few samples before the background changes and turns OFF, the brake RELEASE bit would be a few samples after SynqNet initialization had been completed, where the brake RELEASE bit is set in the packet sent to the node. This resulted in the brake turning off for a few samples just after SynqNet initialization.

Problem/Cause:
If you type flash /erase and then type reset, the controller actually resets correctly instead of generating a no firmware found error message.

Problem/Cause:

Fix/Solution:
This problem was fixed by adding a check to firmware to verify that the motor is disabled AND the axis does not have the MOVE_IN_PROGRESS or MOVE_PENDING bits set before setting the cmd=act.

If a motor is disabled, the cmd=act. But, if a move is commanded and the cmd is no longer equal to the act, the cmd will follow the user defined profile. If and when the error limit triggers, the user defined event occurs. When the move finishes (either by completion or by event due to error limit), cmd will once again equal act.

Problem/Cause:
Using the sqCmd utility, sqCmd /control 0 /read works fine.
But, sqCmd /read /control 0 does not work.

Problem/Cause:
meiPlatformBoardInfoGet(...) would cause an assertion, thereby disabling the user from retrieving serial and t-level numbers. Board information was stored in flash memory in order to reduce the number of EEPROM accesses. However, if null firmware was loaded, the board information became inaccesible.

Problem/Cause:
Some capture objects default to not enabled.

Problem/Cause:
When performing a drive parameter read or write to a parameter that is unsupported by a drive, you get the non descriptive error message.

"ERROR 0x1c05: sqDispatch: Node specific command dispatch error"

The correct return value should actually be a "not supported" error.

Clarification:
getpid() is non-POSIX conformant for pre-2.6 Linux kernels. Currently, the MPI is not built with the 2.6 Linux kernel. This will affect any code dependent on meiPlatformProcessId(...).

By default, an MPIEventMgr will only retreive events set up by mpiObjectEventNotifySet(...) calls that report the same process Id. This means that within the same application, one thread calls mpiEventMgrCreate(...) and another thread calls mpiObjectEventNotifySet(...), then the events generated due to the call to mpiObjectEventNotifySet(...) will not be reported by the MPIEventMgr object.

Workaround:
The workaround for this limitation is to set MEIEventMgrServiceConfig.allProcesses to TRUE with a call to meiEventMgrServiceConfigSet(...). This will allow the MPIEventMgr object to accept all events.

Clarification:
If during motion, an error occurs that causes either a STOP or ESTOP, the Motion Supervisor decreases the feedrate until it is zero. When the feedrate is zero, motion stops. However, the command position at this time is still being calculated by the current frame and is still valid. If for some reason the user disables the axis, the command position will either track the actual position or it will continue to be calculated by using the current frame (default is to track the actual position). Now, since the frames are still valid, if the user reenables the motor, the command is calculated by the frames. This means that if the user moved the motor by hand while it was disabled, it will jump back to the position that it held when the STOP or ESTOP completed. This is not a bug.

If the user does not want the motor to jump back to the STOP/ESTOP position, then the user MUST call mpiMotionAction(....RESET). This will clear the STOP/ESTOP AND will also clear out the current frame list so that the current frame is a NULL frame. If the firmware is processing a NULL frame, it will not try to calculate a new command position based on frames. Once this is done, reenabling the axis will not cause the motor to jump.