.

Release Note
MPI Library Version 03.01.02

Release Type
MPI Version
Release Date
Patch Release
03.01.02
02Dec2004
Patch Release
03.01.01
20Sept2004
Production Release
03.01.00
30July2004

 

  Table of Contents
    Notes
      System Requirements
Software Installation Instructions
Important Things to Know - This section highlights the most important changes in this release.
     
    New Features
     

Version 03.01.01
     Support for AMC Drive DQ111RE - MPI1480

Version 03.01.00
     Support for AMC Drive DQ113EE - MPI1392
     Probe Support for Kollmorgen CD Drive - MPI1391
     Probe Support for the RMB-10V2 - MPI1355
     meiCanCommand supports NMT Protocol - MPI1354
     Addition of Configurable Axis Frame Buffers - MPI1353
     Support for auto-detect bit rate feature on CANopen nodes - MPI1351
     Version.exe reports CAN node version information - MPI1326
     Addition of CAN Node Version calls to the MPI - MPI1323
     Mapable Secondary Encoder Programming Interface - MPI1319
     Camming Support - MPI1300
     Manufacturer and User Fields added to the EEPROM - MPI1311
     Replacement of MEIControlVersion with MEIControlInfoX structures - MPI1294
     New Compensator object - MPI1287
     Encoder Filter Enable/Disable has been added to MEIMotorConfig - MPI1269
     An AmpWarning event has been added to MPIMotorConfig/Status - MPI1230
     ZMP Software Support - MPI1197

    General Changes
     

Version 03.01.00
     MoveID and ElementID changed to 16-bit resolution - MPI1434
     Changed meiSqNodeAnalogIn(...) to meiSqNodeAnalogInput(...) - MPI1428
     Changes to meiObject[Flash]ConfigGet and meiObject[Flash]ConfigSet - MPI1368
     New MPI Version Numbering - MPI1358
     Deletion of MEIXmpIOFrame - MPI1349
     MEI SLICE I/O using CANopen Interface reads digital I/O - MPI1325
     Allow MPI to set RESUME any time a STOP is in progress or finished - MPI1320
     MPIMotorEventTrigger.encoder should be MPIMotorEncoderFault - MPI1314
     Phase Reversal moved to MEIMotorEncoder - MPI1289
     Feedforward for PTF and PVTF improvements - MPI1286
     Reordered the Capture Source Enum - MPI1249
     Use zero velocity to generate a DONE status/event - MPI1202

    Fixed Bugs
     

Version 03.01.02
    mpiProbeCreate(...) fails after topology is saved - MPI1564
    Compensator range problem - MPI1554
    Saving sample rate to flash bug (ZMP only) - MPI1548
    MPICaptureStateInvalid should NEVER occur - MPI1541
    mpiFilterGainGet(...) returns ARG_INVALID with ZMP - MPI1536
    meiPlatformTimerCount(...) bug in Linux release - MPI1533
    Config.exe doesn't support individual objects - MPI1526
    Problem with Steppers when changing sample rate and saving topology - MPI1524
    Secondary Encoder Check fixed in CaptureConfigSet(...) - MPI1503

Version 03.01.01

    mpiAxisCommandPositionSet(...) returns MPIAxisMessageCOMMAND_NOT_SET - MPI1488
    VM3 does not work '-load' option - MPI1476
    Multi-point moves with appends get unexpected error state - MPI1473
    Step pulse width does not work for ZMP - MPI1471
    Multi-point motion bug with axisFrameCount <> 128 - MPI1470
    The presence of the CAN Hardware is falsely reported - MPI1464

Version 03.01.00
    Motor resource boundary check - MPI1441
    Capture Edge Trigger not configured correctly - MPI1440
    Path Motion has incorrect deceleration - MPI1431
    mpiEventMgrService(...) gets stuck in an infinite loop if CAN firmware not loaded - MPI1430
    Trust RMB Hall inputs don't show up in dedicated inputs - MPI1426
    Position jump during the motion modify of a velocity frame - MPI1425
    PT/PVT motion stuck in MOVING state - MPI1423
    Certain path motion moves cause friction feedforward noise - MPI1418
    Fixed meiSqNodeDriveMonitor(...) - MPI1412
    meiFilterConfigSet does not write MEIFilterConfig.PostFilterForm - MPI1397
    MPI recognizes a wider range of post filter settings - MPI1394
    New error messages to replace MPIMessageFATAL_ERROR - MPI1393
    After topology is saved, the motor input bits are potentially not returned to host - MPI1380
    Non Motion Actions after a Profile Not Supported is returned from a Motion - MPI1376
    Change INVALID enumerations to use some other defintion for -1 - MPI1372
    Moves using MEIMotionTypeFRAME do not start - MPI1350
    Topology Save fails with Trust Automation RMB - MPI1348
    Incorrect return value when using a CANopen analog input  - MPI1327
    XCVR D, E, F for RMB-10V2, 10V - MPI1322
    Recovery Mode was not being saved - MPI1316
    BSOD with multiple eventMgrs - MPI1312
    All XMP addresses should be host addresses - MPI1303
    Encoder type is checked before allowing the user to invert the feedback - MPI1301
    AMC node has busy timeout during initialization - MPI1295
    SynqNet topology saved status not updated properly in Motion Console - MPI1293
    Unnecessary "Save network topology to flash memory now?" popup window - MPI1292
    Brake toggles on/off during controller reset after topology is saved - MPI1291
    No firmware found message not returned - MPI1290
    mpiControlValidate causes unhandled exception - MPI1288
    Filter and Axis object deadlock in firmware - MPI1280
    Commanding a move with a disabled motor - MPI1273
    The order of arguments passed to sqCmd.exe is important - MPI1270
    Accessibility of Board Information - MPI1212
    Some capture objects default to not enabled - MPI1171
    Accessing unsupported drive parameters returns a non-descriptive error code - MPI1159

    Open Issues
      Existing Bugs
     Currently, there are no known bugs.
      Limitations
    Linux port of meiPlatformProcessId(...) uses the getpid() - MPI1362
    Motion Action RESET should be called before enabling motor - MPI1285
         

New Features

Version 03.01.01

  Support for AMC Drive DQ111RE
    Reference Number: MPI 1480
    Type: New Feature
    MPI Version: 03.01.01
   

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.

 

Version 03.01.00

  Support for AMC Drive DQ113EE
    Reference Number: MPI 1392
    Type: New Feature
    MPI Version: 03.01.00
   

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.


  Probe Support for Kollmorgen CD Drive
    Reference Number: MPI 1391
    Type: New Feature
    MPI Version: 03.01.00
   

Description:
The Kollmorgen CD Drive now has Probe support.

   

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


  Probe Support for the RMB-10V2
    Reference Number: MPI 1355
    Type: New Feature
    MPI Version: 03.01.00
   

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.


  meiCanCommand supports NMT Protocol
    Reference Number: MPI 1354
    Type: New Feature
    MPI Version: 03.01.00
   

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.

    Code Interface:


can.h


OLD
typedef enum {
     MEICanCommandTypeSDO_READ,
     MEICanCommandTypeSDO_WRITE,
     MEICanCommandTypeCLEAR_STATUS_BITS,
     MEICanCommandTypeBUS_START,
     MEICanCommandTypeBUS_STOP,
     MEICanCommandTypeNMT_STOP,
     MEICanCommandTypeNMT_START

} MEICanCommandType;

NEW
typedef enum {
     MEICanCommandTypeSDO_READ,
     MEICanCommandTypeSDO_WRITE,
     MEICanCommandTypeCLEAR_STATUS_BITS,
     MEICanCommandTypeBUS_START,
     MEICanCommandTypeBUS_STOP,
     MEICanCommandTypeNMT_ENTER_PRE_OPERATIONAL,      MEICanCommandTypeNMT_START_REMOTE_NODE,      MEICanCommandTypeNMT_STOP_REMOTE_NODE,      MEICanCommandTypeNMT_RESET_NODE,      MEICanCommandTypeNMT_RESET_COMMUNICATION,
} MEICanCommandType;

For more information, see MEICanCommandType.

 


   

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.


  Addition of Configurable Axis Frame Buffers
    Reference Number: MPI 1353
    Type: New Feature
    MPI Version: 03.01.00
   

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.

    Code Interface:


control.h

NEW
#define MPIControlMAX_AXES (32)

typedef struct MPIControlConfig {
    ...
    long axisFrameCount[MPIControlMAX_AXES];
    ...
}MPIControlConfig;

For more information, see MPIControlConfig.

 


   

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.


  Support for auto-detect bit rate feature on MEI CANopen nodes
    Reference Number: MPI 1351
    Type: New Feature
    MPI Version: 03.01.00
   

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.


  Version.exe reports CAN node version information
    Reference Number: MPI 1326
    Type: New Feature
    MPI Version: 03.01.00
   

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?


C:\>version
MPI: version 03.01.00
MPI firmware: version 525 option 0
XMP firmware: version 525 revision B sub-revision 4 option 0
              branchId 0

Driver: version 3.00
PLD : version 0x0011 option 0x2192
Rincon: version 0x0218 package 0x9201
XMP : T014-0001 Serial Number 440060

CAN
Bootloader Version: 2
CAN Firmware: version 2 revision B sub-revision 1

CAN Node[4]
Type : 401 (IO Node)
Vendor ID : 0x014F (MEI)
Product Code : 0x0204
Version Number : 0x10030
Serial Number : 0x1234

CAN Node[5]
Type : 401 (IO Node)

NOTE: Node 4 is an MEI Slice I/O node and Node 5 is a CANOpen I/O node from a supplier that does not support reporting the vendor ID information.

 


  Addition of CAN Node Version calls to the MPI
    Reference Number: MPI 1323
    Type: New Feature
    MPI Version: 03.01.00
   

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.

    Code Interface:


can.h


NEW
typedef struct MEICanNodeInfo {
     MEICanNodeType      type;
     unsigned long       digitalInputCount;
     unsigned long       digitalOutputCount;
     unsigned long       analogInputCount;
     unsigned long       analogOutputCount;
     MEICanHealthType    healthType;
     unsigned long       vendorID;
     unsigned long       productCode;
     unsigned long       versionNumber;
     unsigned long       serialNumber;

} MEICanNodeInfo;

For more information, see MEICanNodeInfo.


   

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


  Mapable Secondary Encoder Programming Interface
    Reference Number: MPI 1319
    Type: New Feature
    MPI Version: 03.01.00
   

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.

    Code Interface:


sqNode.h


typedef struct MEISqNodeFeedbackSecondary {
    long   motorIndex;
} MEISqNodeFeedbackSecondary;

typedef struct MEISqNodeConfig {
    MEISqNodeConfigAlarm         nodeAlarm;
    MEISqNodeConfigIoAbort       ioAbort;
    MEISqNodeConfigPacketError   upStreamError;
    MEISqNodeConfigPacketError   downStreamError;
    MEISqNodeConfigUserFault     userFault;
    MEISqNodeFeedbackSecondary   feedbackSecondary
                                    [MEISqNodeMaxFEEDBACK_SECONDARY];

} MEISqNodeConfig;

For more information, see MEISqNodeFeedbackSecondary and MEISqNodeConfig.

 


   

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


  Manufacturer and User Fields added to the EEPROM
    Reference Number: MPI 1311
    Type: New Feature
    MPI Version: 03.01.00
   

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.

    Code Interface:


sqNode.h


NEW
typedef struct MEISqNodeUserData {
     char   data[MEISqNodeUserDATA_CHAR_MAX];
}MEISqNodeUserData

For more information, see MEISqNodeUserData.

 

typedef struct MEISqNodeInfoId {
     unsigned   long nodeType;   /* product/mfg code */
     char            *nodeName;  /* product/mfg string */
     unsigned   long option;     /* product option code*/
     unsigned   long switchId;   /* rotary switch id */
     unsigned   long unique;     /* unique id code */

     long            exactMatch; /* TRUE/FALSE */

     char            serialNumber[MEISqNodeID_CHAR_MAX];
     char            modelNumber[MEISqNodeID_CHAR_MAX];
     char            manufacturerData
                          [MEISqNodeManufacturerDATA_CHAR_MAX];

} MEISqNodeInfoId;

For more information, see MEISqNodeInfoId.

 


   

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


  Camming Support
    Reference Number: MPI 1300
    Type: New Feature
    MPI Version: 03.01.00
   

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.


  Replacement of MEIControlVersion with MEIControlInfoX structures
    Reference Number: MPI 1294
    Type: New Feature
    MPI Version: 03.01.00
   

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

    Code Interface:


stdmei.h


OLD - Deleted
typedef struct MEIControlVersion {
    struct { /* control.c */
        char *version; /* MEIControlVersionMPI (YYYYMMDD) */
    struct { /* xmp.h */
        long version; /* MEIXmpVERSION */
        long option; /* MEIXmpOPTION */ }
    firmware;
    } mpi;
    struct {
        long version; /* hardware version */
        struct { /* MEIXmpData.SystemData{} */
            long version; /* MEIXmpVERSION_EXTRACT(SoftwareID) */
            char revision; /* ('A' - 1) + MEIXmpREVISION_EXTRACT(SoftwareID) */
            long subRevision; /* MEIXmpSUB_REV_EXTRACT(Option) */
            long developmentId; /* MEIXmpDEVELOPMENT_ID_EXTRACT(Option) */
            long option; /* MEIXmpOPTION_EXTRACT(Option) */
            long userVersion;
            long branchId;
        } firmware;
        
        struct {
            struct {
                long version;
                long option;
            } PLD;
            struct {
                char number[10];
                char rev[5];
            } model;
            struct {
                long version;
            } FPGA;
        } board;
    } xmp;
    struct {
        char version[10]; }
    driver;
} MEIControlVersion;

typedef struct MEIControlInfo {
    char tNumberMEIControlSTRING_MAX;
    char serialNumber[MEIControlSTRING_MAX];
    char boardType[MEIControlSTRING_MAX];
}MEIControlInfo;

NEW - Added
typedef struct MEIControlInfo {
    MEIControlInfoMpi        mpi;
    MEIControlInfoFirmware   firmware;
    MEIControlInfoPld        pld;
    MEIControlInfoRincon     rincon;
    MEIControlInfoHardware   hardware;
    MEIControlInfoDriver     driver;
} MEIControlInfo;

For more information, see MEIControlInfo.

 


   

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


  New Compensator object
    Reference Number: MPI 1287
    Type: New Feature
    MPI Version: 03.01.00
   

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.


  Encoder Filter Enable/Disable has been added to MEIMotorConfig
    Reference Number: MPI 1269
    Type: New Feature
    MPI Version: 03.01.00
   

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.

    Code Interface:

stdmei.h:

NEW
typedef struct MEIMotorEncoder {
    MEIMotorEncoderType          type;
    long                         encoderPhase;
                                 /* 0 => normal, else reversed */
    long                         filterDisable;
                                 /* 0 => quad filter enabled,
                                 else not enabled */

    long                         countsPerRev;
    MEIMotorEncoderRatio         ratio;
    MEIMotorEncoderReverseModulo reverseModulo;
} MEIMotorEncoder;

See MEIMotorConfig and MEIMotorEncoder.

 


   

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


  An AmpWarning event has been added to MPIMotorConfig/Status
    Reference Number: MPI 1230
    Type: New Feature
    MPI Version: 03.01.00
   

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.

    Code Interface:


event.h
:

NEW
typedef enum {
     ...
     MPIEventTypeAMP_WARNING,   /* 9 */
     ...
} MPIEventType;

See MPIMotorConfig and MPIMotorEventConfig

 


   

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.


  ZMP Software Support
    Reference Number: MPI 1197
    Type: New Feature
    MPI Version: 03.01.00
   

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.

 

General Changes

Version 03.01.00


MoveID and ElementID changed to 16-bit resolution
    Reference Number: MPI 1434
    Type: General Change
    MPI Version: 03.01.00
   

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.



Changed meiSqNodeAnalogIn(...) to meiSqNodeAnalogInput(...)
    Reference Number: MPI 1428
    Type: General Change
    MPI Version: 03.01.00
   

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.

    Code Interface:


sqNode.h
:

OLD
long meiSqNodeAnalogIn(MEISqNode    node,
                       long         channel,
                       double       *state);

NEW
long meiSqNodeAnalogInput(MEISqNode    node,
                          long         channel,
                          double       *state);




  Changes to meiObject[Flash]ConfigGet and meiObject[Flash]ConfigSet
    Reference Number: MPI 1368
    Type: General Change
    MPI Version: 03.01.00
   

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.

 

    Code Interface:


The following specific interface changes were made:

meiMotorDacConfigGet/Set
   removed flash parameter

meiMotorDacFlashConfigGet/Set
   added new methods

meiSynqNetConfigGet/Set
   removed flash parameter

meiSynqNetFlashConfigGet/Set
   reordered config and flash parameters

meiSynqNetPacketConfigSet
   removed flash parameter

meiSqNodeConfigGet/Set
   removed flash parameter

Addition of the following methods:
meiSqNodeFlashConfigGet/Set
meiSynqNetPacketFlashConfigGet/Set
   get routine currently not supported.

Deprecated of the following method:
meiCanFlashNodeConfigGet/Set
While these methods are still supported, MEI reserves the right to remove deprecated methods. Your application should use the new meiCanNodeFlashConfigGet/Set methods if you plan to upgrade to future versions of the MPI.



  New MPI Version Numbering
    Reference Number: MPI 1358
    Type: General Change
    MPI Version: 03.01.00
   

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.

    Code Interface:


control.h
:
The version defines were expanded and changed to support the new version numbering.

OLD
#define MPI_VERSION "20040330"
#define MPI_INTERFACE_VERSION "20040330"

NEW
#define MPI_VERSION_MAJOR    "02"
#define MPI_VERSION_MINOR    "01"
#define MPI_VERSION_RELEASE  "Dev0"
#define MPI_VERSION MPI_VERSION_MAJOR"."MPI_VERSION_MINOR"."MPI_VERSION_RELEASE
#define MPI_INTERFACE_VERSION MPI_VERSION_MAJOR"."MPI_VERSION_MINOR



  Deletion of MEIXmpIOFrame
    Reference Number: MPI 1349
    Type: General Change
    MPI Version: 03.01.00
   

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.

    Code Interface:


stdmei.h
:

OLD
typedef struct MEIMotionAttrOutput {
    MEIMotionAttrOutputType type;
    union {
        long   *output;
        long   motor;
    } as;
    long   mask;
    long   pattern;
    long   pointIndex; /* MEIMotionAttrMaskOUTPUT for path motion - point index for turning on output - used with point lists */
} MEIMotionAttrOutput;

NEW
typedef struct MEIMotionAttrOutput {
    MEIMotionAttrOutputType type;
    union {
        long   *output;
        long   motor;
    } as;
    long   offMask;
    long   onMask;
    long   pointIndex; /* MEIMotionAttrMaskOUTPUT for path motion - point index for turning on output - used with point lists */
} MEIMotionAttrOutput;

For more information, see MEIMotionAttrOutput.


   

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.


  MEI SLICE I/O using CANopen Interface reads digital I/O
    Reference Number: MPI 1325
    Type: General Change
    MPI Version: 03.01.00
   

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.

    Code Interface:


can.h
:

typedef struct MEICanNodeInfo {
     MEICanNodeType      type;
     unsigned long       digitalInputCount;
     unsigned long       digitalOutputCount;
     unsigned long       analogInputCount;
     unsigned long       analogOutputCount;
     MEICanHealthType    healthType;
     unsigned long       vendorID;
     unsigned long       productCode;
     unsigned long       versionNumber;
     unsigned long       serialNumber;
} MEICanNodeInfo;

For more information, see MEICanNodeInfo.


   

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.

 


  Allow MPI to set RESUME any time a STOP is in progress or finished
    Reference Number: MPI 1320
    Type: General Change
    MPI Version: 03.01.00
   

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.

 


  MPIMotorEventTrigger.encoder should be MPIMotorEncoderFault
    Reference Number: MPI 1314
    Type: General Change
    MPI Version: 03.01.00
   

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

    Code Interface:


motor.h
:

OLD

typedef union {
   long     polarity; /* 0 => active low, else active high */
   long     position; /* MPIEventTypeLIMIT_SW_[POS|NEG] */
   float    error;    /* MPIEventTypeLIMIT_ERROR */
   long     encoder;  /* MPIEventTypeENCODER_FAULT */
} MPIMotorEventTrigger;

NEW
typedef union {
   long                 polarity; /* 0 => active low,
                                  else active high */
   long                 position; /* MPIEventTypeLIMIT_SW_[POS|NEG] */
   float                error;    /* MPIEventTypeLIMIT_ERROR */
   MPIMotorEncoderFault encoder;  /* MPIEventTypeENCODER_FAULT */
} MPIMotorEventTrigger;


   

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

 


  Phase Reversal moved to MEIMotorEncoder
    Reference Number: MPI 1289
    Type: General Change
    MPI Version: 03.01.00
   

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.

    Code Interface:


motor.h
:

OLD

typedef struct MPIMotorConfig {
    MPIMotorType         type; /* Event configuration,
                            ordered by MPIEventType */
    MPIMotorEventConfig  event[MPIEventTypeMOTOR_LAST];
    long                 encoderPhase; /* 0 => normal,
                                        else reversed */
    long                 secondaryEncoderPhase; /* 0 => normal,
                                                else reversed */

    float                abortDelay;
    float                enableDelay;
    MPIMotorBrake        brake;    
    MPIObjectMap         filterMap;
} MPIMotorConfig;

NEW
typedef struct MEIMotorEncoder {
    MEIMotorEncoderType          type;
    long                         encoderPhase; /* 0 => normal,
                                        else reversed */

    long                         filterDisable; /* 0 => quad filter                                         enabled, else not enabled */
    long                         countsPerRev;
    MEIMotorEncoderRatio         ratio;
    MEIMotorEncoderReverseModulo reverseModulo;
} MEIMotorEncoder;

For more information, see MPIMotorConfig and MEIMotorEncoder.


mpiMotorConfigGet/Set

 


   

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


  Feedforward for PTF and PVTF improvements
    Reference Number: MPI 1286
    Type: General Change
    MPI Version: 03.01.00
   

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.).
    Code Interface:

motion.h:

NEW
typedef struct MPIMotionPTF {
    long           pointCount;
    double         *position;
    double         *feedForward;
    double         *time;
    MPIMotionPoint point;
} MPIMotionPTF;

typedef struct MPIMotionPVTF {
    long           pointCount;
    double         *position;
    double         *velocity;
    double         *feedForward;
    double         *time;
    MPIMotionPoint point;
} MPIMotionPVTF;

See MPIMotionPTF and MPIMotionPVTF

 


   

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


  Reordered the Capture Source Enum
    Reference Number: MPI 1249
    Type: General Change
    MPI Version: 03.01.00
   

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.

    Code Interface:


capture.h
:

OLD

typedef enum MPICaptureSource {
   MPICaptureSourceINVALID = -1,

   MPICaptureSourceHOME,
   MPICaptureSourceINDEX,
   MPICaptureSourceLIMIT_HW_NEG,
   MPICaptureSourceLIMIT_HW_POS,
   MPICaptureSourceGLOBAL,
   MPICaptureSourceMOTOR_IO_0,
   MPICaptureSourceMOTOR_IO_1,
   MPICaptureSourceMOTOR_IO_2,
   MPICaptureSourceMOTOR_IO_3,
   MPICaptureSourceMOTOR_IO_4,
   MPICaptureSourceMOTOR_IO_5,
   MPICaptureSourceMOTOR_IO_6,
   MPICaptureSourceMOTOR_IO_7,
   MPICaptureSourceINDEX_SECONDARY,

   MPICaptureSourceLAST,
   MPICaptureSourceFIRST = MPICaptureSourceINVALID + 1,

   MPICaptureSourceCOUNT = MPICaptureSourceLAST,
} MPICaptureSource;

NEW
typedef enum MPICaptureSource {
   MPICaptureSourceINVALID = -1,

   MPICaptureSourceMOTOR_IO_0,
   MPICaptureSourceMOTOR_IO_1,
   MPICaptureSourceMOTOR_IO_2,
   MPICaptureSourceMOTOR_IO_3,
   MPICaptureSourceMOTOR_IO_4,
   MPICaptureSourceMOTOR_IO_5,
   MPICaptureSourceMOTOR_IO_6,
   MPICaptureSourceMOTOR_IO_7,

   MPICaptureSourceHOME,
   MPICaptureSourceINDEX,
   MPICaptureSourceLIMIT_HW_NEG,
   MPICaptureSourceLIMIT_HW_POS,
   MPICaptureSourceGLOBAL,
   MPICaptureSourceINDEX_SECONDARY,

   MPICaptureSourceLAST,
   MPICaptureSourceFIRST = MPICaptureSourceINVALID + 1,

   MPICaptureSourceCOUNT = MPICaptureSourceLAST,
} MPICaptureSource;

See MPICaptureSource.

 


   

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

 


  Use zero velocity to generate a DONE status/event
    Reference Number: MPI 1202
    Type: General Change
    MPI Version: 03.01.00
   

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).

    Code Interface:


event.h
:

NEW
typedef enum {
     ...
     MPIEventTypeMOTION_DONE,        /* 10 */
     MPIEventTypeMOTION_AT_VELOCITY, /* 11 */
     ...
} MPIEventType;

See mpiMotionStart and mpiMotionModify


   

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

 

Fixed Bugs

Version 03.01.02

  mpiProbeCreate(...) fails after topology is saved
    Reference Number: MPI 1564
    Type: Fixed Bug
    MPI Version: 03.01.02
   

Problem/Cause:
mpiProbeCreate(...) returned an MPIProbeMessagePROBE_INVALID message after the SynqNet topology had been saved to flash using meiSynqNetFlashTopoogySave(...). This problem was caused by some internal probe resource information that was not being saved during the topology save routine.

   

Fix/Solution:
This problem has been fixed.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Compensator Range Problem
    Reference Number: MPI 1554
    Type: Fixed Bug
    MPI Version: 03.01.02
   

Problem/Cause:
The range required by the compensator object interface was larger than the actual range of compensation.

   

Fix/Solution:
The compensator interface has been adjusted to accept actual compensation range. See Determining Required Compensator Table Size for details.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Saving sample rate to flash bug (ZMP only)
    Reference Number: MPI 1548
    Type: Fixed Bug
    MPI Version: 03.01.02
   

Problem/Cause:
In specific conditions, the ZMP will run at an unexpected sample rate. This condition occurs when topology has been saved to flash (meiSynqNetFlashTopologySave) while the controller is at one sample rate and then the sample rate of a different value is saved to flash (using mpiControlConfigSet). This sequence of events causes a mismatch in the network timing calculations and the controller sample rate, thus causing the actual controller sample rate to be different than expected.

   

Fix/Solution:
The MPI has been modified to prevent a mismatch between the controller's sample rate and the network timing calculations.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  MPICaptureStateInvalid should NEVER occur
    Reference Number: MPI 1541
    Type: Fixed Bug
    MPI Version: 03.01.02
   

Problem/Cause:
In the MPI there was a "while loop" that timed out after 100 samples. The while loop was waiting for the HomeLimit to trigger. This problem existed because the firmware could not finish the capture handshaking until the home limit had seen the capture status go high and trigger an event. Since the limits are processed in the background and the captures are done in the foreground, this can be problematic.

   

Fix/Solution:
Changes have been made so that when the MPI reads the capture state and realizes that the firmware is in the "captured and waiting for home limit" state, it waits in a while loop for firmware to finish processing. This while loop was hard coded to timeout after 100 samples. The timeout is now taken from the limit duration.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  mpiFilterGainGet(...) returns ARG_INVALID with ZMP
    Reference Number: MPI 1536
    Type: Fixed Bug
    MPI Version: 03.01.02
   

Problem/Cause:
mpiFilterGainGet(...) would return an ARG_INVALID error when used with a ZMP-Series controller. It would also generate an application error when used via client/server. The problem was caused by improper order of operations when reading the filter gains.

   

Fix/Solution:
The problem was corrected by changing the order of operations.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  meiPlatformTimerCount(...) bug in Linux release
    Reference Number: MPI 1533
    Type: Fixed Bug
    MPI Version: 03.01.02
   

Problem/Cause:
A bug exisited that returns MPIMessageFATAL_ERROR from meiPlatformTimerCount(...) every 45 days. This problem was caused by a logic error.

   

Fix/Solution:
This problem has been fixed.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Config.exe doesn't support individual objects
    Reference Number: MPI 1526
    Type: Fixed Bug
    MPI Version: 03.01.02
   

Problem/Cause:
The config.exe utility displayed the "usage" information when an individual object was specified on the command line.

   

Fix/Solution:
The problem was corrected by removing an incorrect command line parameter check.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Problem with Steppers when changing sample rate and saving topology
    Reference Number: MPI 1524
    Type: Fixed Bug
    MPI Version: 03.01.02
   

Problem/Cause:
Steppers did not work properly after changing the sample rate and saving to flash memory, and then saving topology and resetting the controller. The pupCycle value (internal variable) is calculated during synq initialization. The MPI did not save this value to flash. So, after the reset, the old default value (sample rate = 2000) was loaded into working memory. This caused a mismatch between the fpga and the firmware.

   

Fix/Solution:
The MPI was modified so that the pupCycle value is now stored in flash memory (if flash parameter is valid during initialization). In other words, when topology is saved, the pupCycle is also saved.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Secondary Encoder Check Fixed in CaptureConfigSet(...)
    Reference Number: MPI 1503
    Type: Fixed Bug
    MPI Version: 03.01.02
   

Problem/Cause:
Secondary Encoder was being reported as unsupported. Previously, if the encoder was set to secondary, it was assumed that the encoder was located on the same node that had the captureMotor. This is not necessarily the case with time-based capture.

   

Fix/Solution:
The secondary encoder check was fixed in mpiCaptureConfigSet(...). It now checks for the encoder being used for a trigger and also for the encoder being used for feedback.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

 

Version 03.01.01

  mpiAxisCommandPositionSet(...) returns MPIAxisMessageCOMMAND_NOT_SET
    Reference Number: MPI 1488
    Type: Fixed Bug
    MPI Version: 03.01.01
   

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(...).

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  VM3 -load is now supported by the XMP and ZMP
    Reference Number: MPI 1476
    Type: Fixed Bug
    MPI Version: 03.01.01
   

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.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Multi-point moves with appends get unexpected error state
    Reference Number: MPI 1473
    Type: Fixed Bug
    MPI Version: 03.01.01
   

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.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Step pulse width does not work for ZMP
    Reference Number: MPI 1471
    Type: Fixed Bug
    MPI Version: 03.01.01
   

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.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Multi-point motion bug with axisFrameCount <> 128
    Reference Number: MPI 1470
    Type: Fixed Bug
    MPI Version: 03.01.01
   

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.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  The presence of the CAN Hardware is falsely reported
    Reference Number: MPI 1464
    Type: Fixed Bug
    MPI Version: 03.01.01
   

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.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

 

Version 03.01.00

  Motor resource boundary check
    Reference Number: MPI 1441
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Capture Edge Trigger not configured correctly
    Reference Number: MPI 1440
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Path Motion has incorrect deceleration
    Reference Number: MPI 1431
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  mpiEventMgrService(...) gets stuck in an infinite loop if CAN firmware not loaded
    Reference Number: MPI 1430
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Trust RMB Hall inputs don't show up in dedicated inputs
    Reference Number: MPI 1426
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Position jump during the motion modify of a velocity frame
    Reference Number: MPI 1425
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  PT/PVT motion stuck in MOVING state
    Reference Number: MPI 1423
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Certain path motion moves cause friction feedforward noise
    Reference Number: MPI 1418
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Fixed meiSqNodeDriveMonitor(...)
    Reference Number: MPI 1412
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  meiFilterConfigSet does not write MEIFilterConfig.PostFilterForm
    Reference Number: MPI 1397
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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

    Fix/Solution:
meiFilterConfigSet(...) was modified to write the MEIFilterConfig.PostFilterForm to controller memory (or flash memory, if specified).
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  MPI recognizes a wider range of post filter settings
    Reference Number: MPI 1394
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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.

    Fix/Solution:
The solution was to use two different values for the different operations. The MPI now recognizes a wider range of post filter settings.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  New error messages to replace MPIMessageFATAL_ERROR
    Reference Number: MPI 1393
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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.

    Fix/Solution:
This problem was fixed internally.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  After topology is saved, the motor input bits are potentially not returned to host
    Reference Number: MPI 1380
    Type: Fixed Bug
    MPI Version: 03.01.00
    Problem/Cause:
In situations where a node with a lower motor count resided on the network before a node with a higher motor count, the motor input bits would not be returned to the host. This only occurred after topology had been saved to flash.
    Fix/Solution:
This problem was fixed internally.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Non motion actions after a "profile not supported" is returned from a motion
    Reference Number: MPI 1376
    Type: Fixed Bug
    MPI Version: 03.01.00
    Problem/Cause:
Firmware just checked the mode instead of also checking the action. So if a S_Curve Jerk or Velocity Jerk move is commanded, the mode is S_Curve Jerk or Velocity Jerk. The firmware returns a "Profile Not Supported." Then, if the user tries another action that is not a start or modify, "Profile Not Supported" is returned again.
    Fix/Solution:
Firmware has been modified to check the action, as well as the mode before returning "Profile Not Supported."
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Change INVALID enumerations to use some other defintion for -1
    Reference Number: MPI 1372
    Type: Fixed Bug
    MPI Version: 03.01.00
    Problem/Cause:
Under the Linux Motion Programming Interface (MPI) the PVT frames were not correctly written to the firmware. A data misalignment of one word for every frame loaded was observed. This problem was caused by the MEIXmpFrameType{} member of the MEIXmpFrame structure and the possibility of varying storage class sizes of enumerators across different compilers. Due to the range of values in the MEIXmpFrameType{} enumeration, the GCC compiler was promoting the storage class size from 32bits to 64bits, thus causing a shift in the MEIXmpFrame{} structure.
    Fix/Solution:
All enumerations in the MPI, which are explicitly set with hexadecimal values, have been cast to integers to ensure a predictable storage class size.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Moves using MEIMotionTypeFRAME do not start
    Reference Number: MPI 1350
    Type: Fixed Bug
    MPI Version: 03.01.00
    Problem/Cause:
mpiMotionStart(...) would not start motion when motion type MEIMotionTypeFRAME was used. The Control and Reserved fields were zeroed when frames were loaded using MEIMotionTypeFRAME. This caused start frames to malfunction because their status fields were zero.
    Fix/Solution:
This problem was fixed by changing the copying method of frames for MEIMotionTypeFRAME to a straight structure copy. The previous version zeroed out the last two fields of each frame.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Topology Save fails with Trust Automation RMB
    Reference Number: MPI 1348
    Type: Fixed Bug
    MPI Version: 03.01.00
    Problem/Cause:
When using the sqTopologySave.exe utilitity with a Trust Automation I/O node connected to the network, it would fail and return the following error message: "SynqNet: node specific initialization failed"
    Fix/Solution:
This problem was fixed internally.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Incorrect return value when using a CANopen analog input
    Reference Number: MPI 1327
    Type: Fixed Bug
    MPI Version: 03.01.00
    Problem/Cause:
When using a CANOpen analog input to monitor a voltage of –10V, it would return a value slightly less than –1 from meiCanNodeAnalogInputGet. This has been fixed to return a number correctly scaled between +/–1.
    Fix/Solution:
This problem was fixed internally.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  XCVR D, E, F, for RMB-10V2, 10V
    Reference Number: MPI 1322
    Type: Fixed Bug
    MPI Version: 03.01.00
    Problem/Cause:
Motion Console displays motor I/O XCVRs D,E,F for RMB-10v2 / 10v, but the hardware does not support these bits.
    Fix/Solution:
Changes were made to mei_rmb.h. All masks, enumerations, and text strings associated with XCVR D, E, and F were taken out.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Recovery Mode was not being saved
    Reference Number: MPI 1316
    Type: Fixed Bug
    MPI Version: 03.01.00
    Problem/Cause:
SynqNet Recovery Mode was not being saved to controller flash memory.
    Fix/Solution:
This problem was fixed internally. SynqNet Recovery Mode will now be saved to controller flash memory.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  BSOD with multiple eventMgrs
    Reference Number: MPI 1312
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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.

    Fix/Solution:
The service thread no longer disables interrupts on exit. Since this bug fix is in the static AppUtil library, to take advantage of this fix you must recompile your application with provided AppUtil library from this release. This fix is only necessary if you have a multi-process application or run multiple processes where more than one application uses the interrupt enabled EventMgr object.
    Affects to Application Code:
Since this bug fix is in the static AppUtil library, to take advantage of this fix you must recompile your application with provided AppUtil library from this release. This fix is only necessary if you have a multi-process application or run multiple processes where more than one application uses the interrupt enabled EventMgr object.

  All XMP Addresses Should Be Host Addresses
    Reference Number: MPI 1303
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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.

    Fix/Solution:
All XMP addresses are now interpreted as host addresses including the MEIMotorEncoder.reverseModulo.Ptr and MEISqNodeConfig.userFault.addr.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Encoder type is checked before allowing the user to invert the feedback
    Reference Number: MPI 1301
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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.

    Fix/Solution:
The encoderType is now being checked in mpiMotorConfigSet(...) before one can invert the feedback. An error message is now returned if phaseInvert is set for any encoderType besides quadrature.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  AMC node has busy timeout during initialization
    Reference Number: MPI 1295
    Type: Fixed Bug
    MPI Version: 03.01.00
    Problem/Cause:
AMC DQ111EE drives with firmware version 8.2 intermittently fail initialization with a "node busy" timeout error message (MEISqNodeMessageREADY_TIMEOUT) during network initialization.
    Fix/Solution:
This problem has been fixed.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  SynqNet topology saved status not updated properly in Motion Console
    Reference Number: MPI 1293
    Type: Fixed Bug
    MPI Version: 03.01.00
    Problem/Cause:
Motion Console is not updated when the topology is saved to flash. This problem was caused by a bug in the meiSynqNetTopologyStatus(...) routine.
    Fix/Solution:
The bug in meiSynqNetTopologyStatus(...) has been fixed.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Unnecessary "Save network topology to flash memory now?" popup window
    Reference Number: MPI 1292
    Type: Fixed Bug
    MPI Version: 03.01.00
    Problem/Cause:
A bug existed in the 20030620.1.10 release where saving a motor configuration to flash memory for the first time would always prompt Motion Console's "Save network topology to flash memory now?" popup window. Saving topology is not required unless a motor configuration has been changed, which would also require a service command to be sent to a SynqNet node.
    Fix/Solution:
The bug has been fixed.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Brake toggles on/off during controller reset after topology is saved
    Reference Number: MPI 1291
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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.

    Fix/Solution:
The problem was fixed by modifying the default motor I/O word so that the brake RELEASE bit is cleared, instead of set.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  No firmware found message not returned
    Reference Number: MPI 1290
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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.

    Fix/Solution:
Code was added to the flash utility function.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  mpiControlValidate causes unhandled exception
    Reference Number: MPI 1288
    Type: Fixed Bug
    MPI Version: 03.01.00
   

Problem/Cause:

    Fix/Solution:

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Filter and Axis object deadlock in firmware
    Reference Number: MPI 1280
    Type: Fixed Bug
    MPI Version: 03.01.00
    Problem/Cause:
If an axis was prevented from completing a motion by a Stop, E-Stop, or Abort action, and then the network was shutdown and re-initialized, the controller's axis and filter objects would have corrupt calculation values. For example, the TC.Velocity and TC.Accel values would be: -1.QNAN. This problem was caused by an improper frame load due to the initial frameLoad and frameIndex value differences.
    Fix/Solution:
This problem was corrected in the MPI by disabling axes during network shutdown and enabling the axes during network initialization. Now, when a Stop, E-Stop, or Abort action is used to stop motion on an axis, and the network is shutdown and re-initialized, the Axis and Filter objects will receive correct calculation values.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Commanding a move with a disabled motor
    Reference Number: MPI 1273
    Type: Fixed Bug
    MPI Version: 03.01.00
    Problem/Cause:
When a motor was disabled, the axis would set cmd=act. As a result, if a move was commanded, the cmd would remain equal to the actual. Although no motion would result, the move would still go through its cycle. Then the move would be completed and return a DONE event, etc. So, it would appear as though the move completed, even though nothing really happened; the motor never moved and the cmd still equaled the actual.
   

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.

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Some capture objects default to not enabled
    Reference Number: MPI 1270
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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

    Fix/Solution:

    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Accessibility of board information
    Reference Number: MPI 1212
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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.

    Fix/Solution:
Board information is now always retrieved from the EEPROM for the XMP, and the Boot0 page for the ZMP. Retrieving board information (i.e. serial number, t-level number) is no longer dependent on functioning firmware.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Some capture objects default to not enabled
    Reference Number: MPI 1171
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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

    Fix/Solution:
All capture trigger inputs are defaulted to not enabled when the capture is created first. After the capture has been used, the old configuration will remain in place through captureCreate's and captureDelete's. To reset the capture configuration, the application must call the mpiCaptureConfigReset function.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

  Accessing unsupported drive parameters returns non-descriptive error code
    Reference Number: MPI 1159
    Type: Fixed Bug
    MPI Version: 03.01.00
   

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.

    Fix/Solution:
This error message has been modified so that when performing a drive parameter read or write to a parameter that is unsupported by a drive, a "not supported" error message will be returned.
    Affects to Application Code:
The following changes were made to the internal MPI/MEI libraries and will not affect customer code.

 

Open Issues

Existing Bugs

Currently, there are no known bugs.

 

Limitations

  Linux port of meiPlatformProcessId(...) uses the getpid()
    Reference Number: MPI 1362
    Type: Limitation
   

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.


  Motion Action RESET should be called before enabling motor
    Reference Number: MPI 1285
    Type: Limitation
   

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.

 


       Legal Notice  |  Tech Email  |  Feedback
      
Copyright ©
2001-2021 Motion Engineering