.

Release Note
MPI Library Version 03.03.01

Release Type
MPI Version
Release Date
Patch Release
03.03.01
26Aug2005
Production Release
03.03.00
29Jul2005

  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.03.00
     Data Recorder Trigger Enhancements - MPI1704
     Addition of 32 GPIO and 32 Dedicated I/O to MEIMotionAttrHoldType - MPI1686
     Check for infinite and NAN values in user defined path motion data - MPI1677
     Addition of Kollmorgen S200 Drive Parameters - MPI1671
     Addition of Probe for Kollmorgen PicoDAD Drive - MPI1668
     Support for AMC DQ115EE Drive - MPI1644
     Drive-based Phase Finding Support - MPI1636
     SynqNet Dual String Initialization - MPI1622
     Addition of mpiEventTypeName(...) to return string descriptions for event types - MPI1611
     eXMP temperature support for VxWorks, Linux, and XPe - MPI1609
     Addition of Host Interrupt to Apputil library - MPI1566
     Support for Glentek Drive Firmware Download - MPI1456
     Addition of abandoned recorder management methods - MPI1433
     Support for Slice I/O Nodes - MPI1409
     Reset CAN Interface without reseting the controller - MPI1405
     Multiple Drive Map Files - MPI1370
     Expand Motor I/O to 32 bits - MPI1361
     Addition of user labels to Config structures - MPI1310
     Addition of meiInfo.exe utility - MPI1305
     Triggerable MotionModify - MPI1284


    General Changes
     

Version 03.03.00
     Modification of MEIDriveMapParamValue - MPI1734
     Added MPIAxisMasterTypeNONE to the MPIAxisMasterType Enumeration - MPI1732
     SqNode I/O Method Optimization - MPI1699
     Change Sequence defines to support 32 Dedicated/GP I/O - MPI1685
     SynqNet Timing Schedule Improvement - MPI1681
     Faster FPGA/Drive Firmware download over a TCP/IP connection - MPI1676
     Brake cannot be activated by host, even when mode = NONE - MPI1673
     Reset Utility renamed meiReset - MPI1632
     Modification of I/O Interface for CAN and Controller Objects - MPI1585
     meiPlatformCreate and meiPlatformDelete methods are private - MPI1458


    Fixed Bugs
     

Version 03.03.01
    Save Topology causes demand mode 0 - MPI1926
    Possible Assertion Failure during Network Initialization - MPI1757
    ZMP-SynqNet Controller I/O Mapping Error - MPI1755

Version 03.03.00
    RinconZ Continuous Timer not equivalent to SamplePeriod on ZMP - MPI1745
    mpiMotionModify(...) with DELAY attribute - MPI1733
    Velocity moves using the Sequencer created motion with wrong parameters - MPI1728
    SqNode FPGA download failures with ZMP - MPI1727
    AT_TARGET axis and motion status bits do not come on until motion is complete - MPI1709
    mpiRecorderStart/Stop(...) fails to start/stop a recorder - MPI1683
    Axis and Motor do not receive events - MPI1674
    Glentek drive's default digital output states - MPI1670
    Trust analog configurations not included - MPI1669
    meiFilterPostfilterGet(...) with 6 sections causes MPIMessageFATAL_ERROR - MPI1665
    MPI Semaphore Deadlock - MPI1659
    SynqNet initialization errors can lead to dangerous SYNQ state - MPI1654
    mpiCaptureConfigSet(...) is disabled if Capture is armed - MPI1649
    Missing A/D Inputs with IO2kSQA2S - MPI1646
    VxWorks System-wide Lock bug - MPI1639
    Unable to run utilities more than once under VxWorks - MPI1638
    Missing foreground cycles on ZMP-SynqNet controllers - MPI1637
    SynqNet Initialization Errors can lead to a dangerous SYNQ state - MPI1635
    Startup script doesn't work when console cable is disconnected - MPI1629
    Possible Deadlock between Axis Object Methods - MPI1626
    Motion fails intermittently with OUT_OF_FRAMES - MPI1625
    Intermittent service command errors from mpiMotorEventConfigSet(...) - MPI1621
    Velocity Tolerance was returned with incorrect units - MPI1606
    Velocity Event not generated with Motion Modify - MPI1604
    Access violations in Filter Object over client/server - MPI1601
    mpiFilterGainSet(...) returns MPIMessagePARAM_INVALID - MPI1588
    mpiMotionStatus(...) is incorrect after mpiMotionStart(...) for PVT moves - MPI1587
    User Limit does not generate an event when MS is STOPPED - MPI1562
    meiMapNameToParams(...) now decodes Rincon Addresses - MPI1378


    Open Issues
      Existing Bugs
    Multiple eventMgr objects over client/server bug - MPI1578
    SqNode upStreamError limits not saved in flash - MPI1505

      Limitations
     Currently, there are no known limitations.
         

 

New Features

Version 03.03.00

  Data Recorder Trigger Enhancements
    Reference Number: MPI 1704
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
In previous versions, the data recorder triggers took too long to execute. They were confusing because both the start and stop triggers executed every sample. Under certain conditions, both the start and stop trigger could trigger simultaneously. Therefore, changes were made to the Data Recorder in order to optimize its functionality. There are two Data Recorder Triggers, one for starting the Data Recorder, and one for stopping it. In old firmware, both triggers were evaluated every sample. This took up time in the foreground loop and caused confusion because both triggers could trigger simultaneously.

   

How do I use this feature?
In the new enhanced firmware, only one trigger is evaluated every sample. The trigger that is evaluated depends on the state of the Data Recorder.
      If the Data Recorder is not enabled, then trigger 0 (start trigger) is evaluated.
      If the Data Recorder is enabled, then trigger 1 (stop) is evaluated.
This decreases the amount of time spent on Data Recorder triggers and decreases confusion about how the triggers work.

Recorder triggers are now a single shot. This means that the trigger disables itself by setting its type to MEIRecorderTriggerConditionNONE after it triggers. However, if the MEIRecorderTriggerConditionREPEAT bit is OR'd in with the trigger type, the trigger will not disable itself, it will continually evaluate the trigger condition.

There are now a few new types of Data Recorder Triggers. See MEIRecorderTriggerCondition.


  Addition of 32 GPIO and 32 Dedicated I/O to MEIMotionAttrHoldType
    Reference Number: MPI 1686
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
Support for 32 GPIO and 32 Dedicated I/O has been added to MEIMotionAttrHold. Before the 03.03.00 release, 16 bits of GPIO and 16 bits of Dedicated I/O lived in one 32 bit register.
Now there are in two 32 bit registers.

   

How do I use this feature?
Previously, the motion hold attribute MEIMotionAttrHoldTypeMotor covered both GPIO and Dedicated I/O. Since the I/O has been seperated into two 32 bit registers, they are also separated in the MotionHold interface. The new defines are:
      MEIMotionAttrHoldTypeMOTOR_GENERAL_IO
      MEIMotionAttrHoldTypeMOTOR_DEDICATED_IO


  Check for infinite and NAN values in user defined path motion data
    Reference Number: MPI 1677
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
A check has been added to the MPI to make sure that all data passed in by the user for path motion is valid (not infinite and not NAN).

   

How do I use this feature?
If the user passes in path data containing infinite or NAN values, then the MPI will return MEIMotionMessageBAD_PATH_DATA and will not load the move.


  Addition of Kollmorgen S200 Drive Parameters
    Reference Number: MPI 1671
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
New S200 drive parameters have been added to the MPI. There are 2 new parameters: VerLW and SerialNum. They are both strings. The scaling was also changed for a few drive parameters. Changes were made to the kollmorgen_s200.h and kollmorgen_s200.c files in the sqNodeLib library.

   

How do I use this feature?
VerLw is now reported as the firmware version. For more information about the Kollmorgen S200 Drive, please contact Kollmorgen.


  Addition of Probe for Kollmorgen PicoDAD Drive
    Reference Number: MPI 1668
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
Probe support has been added to the MPI for all motors on the Kollmorgen PicoDAD Drive.

   

How do I use this feature?
For more information about the Kollmorgen PicoDAD Drive, please contact Kollmorgen.


  Support for AMC DQ115EE Drive
    Reference Number: MPI 1644
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
Support has been added to the MPI for the AMC DQ115EE Drive.

   

How do I use this feature?
Please see SynqNet Drives and Drive FPGA Table: AMC DigiFlex DQ115EE.
For more information about the AMC DQ115EE Drive, please contact AMC.


  Drive-based Phase Finding Support
    Reference Number: MPI 1636
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
Phase Finding routines have been added to the MPI. Currently they are only supported by the Kollmorgen PicoDAD and CD drives. Support for the S600 drive is currently in progress. This feature should be used for drives that need SinCom initialization (also known as Wake-No-Shake and Phase Finding).

   

How do I use this feature?
After network initialization, the drive will indicate that Phase Finding is needed by setting a warning bit in the cyclic data. The user will need to call the following routines before the motor can be enabled: meiMotorPhaseFindStart(...), meiMotorPhaseFindStatus(...), meiMotorPhaseFindAbort(...).


  SynqNet Dual String Initialization
    Reference Number: MPI 1622
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
In previous versions, SynqNet was unable to detect a Dual String topology. Changes were made so that if the SynqNet network topology is NOT in a Ring topology, then the initialization routine will check both the OUT and IN ports for nodes.

   

How do I use this feature?
The new initialization routine will be done automatically. All nodes that are found will be addressed and initialized. See SynqNet Topologies to learn more about the types of supported topologies, and how nodes are discovered and addressed on the network.

To support Dual String networks, the MEINetworkType enumeration was changed. MEINetworkTypeSTRING_DUAL was added and MEINetworkTypeSTRING_TERMINATED was removed. Use meiSynqNetInfo(...) to determine the network type. If you want to determine whether a node is terminated or non-terminated, use the new method meiSqNodeNetworkObjectNext(...). You can use this method to traverse the ports on each node to determine what is connected. In the future, as more complex networks are supported, this method will allow you to identify the physical layout of the network and its components.


  mpiEventTypeName(...) returns string descriptions for event types
    Reference Number: MPI 1611
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
mpiEventTypeName(...) now returns a text description for MPI events. mpiEventTypeName(...) should be called when a text description is needed for an event type.

   

How do I use this feature?
See the EventLog.c sample application.


  eXMP temperature support for VxWorks, Linux, and XPe
    Reference Number: MPI 1609
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
It is now possible to read the temperature of an eXMP for VxWorks, Linux, and XPe operating systems.

   

How do I use this feature?
meiPlatformExmpTempGet | meiPlatformExmpTempInit


  HostService module added to apputil library
    Reference Number: MPI 1566
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
A new HostService object module was added to the apputil library. This "helper" module allows users to synchronize their application to the "heartbeat" of the controller. This is a feature that can be used to monitor the health of the DSP, as a deterministic, non-busy application delay, or even to modify SynqNet packets in real-time.

   

How do I use this feature?
See the following sample applications? hostservice1.c | hostservice2.c | syncInterrupt.c


  Support for Glentek Drive Firmware Download
    Reference Number: MPI 1456
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
Support has been added to the MPI for drive firmware download on a Glentek drive. The entire FPGA image is uploaded, the flash is erased, the Drive image is attached to the FPGA image, and then it is downloaded to the drive. Drive firmware download requires Glentek Omega hardware rev B (or higher). Previous hardware revs will only support FPGA image download. Please contact Glentek for more information.

   

How do I use this feature?
Please see SynqNet Drives and Motion Console.


  Addition of abandoned recorder management methods
    Reference Number: MPI 1433
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
Two control object methods have been added to help with the managment of abandoned recorders.
    - meiControlRecorderStatus(...) obtains the status of a given recorder.
    - meiControlRecorderCancel(...) allows the application to cancel the "reserved" status
      on the motion controller, which frees an abandoned recorder for reuse.

When a recorder object is created, the corresponding recorder on the motion controller is "reserved" so no other application can use the same recorder at the same time. If the recorder object is not properly deleted, the reserved recorder can no longer be used by any application on the system. This typically occurs when a motion application crashes or fails to clean up after itself.

   

How do I use this feature?
To reclaim abandoned recorders, one should use meiControlRecorderStatus(...) to determine if a recorder is abandoned. In most cases, the recorder may be abandoned:
       - if the recorder is reserved, but disabled
       - if the recorder is full and enabled
Once an abandoned recorder is identified, use meiControlRecorderCancel(...) to cancel the reserved status of the given recorder.


  Support for Slice I/O Nodes
    Reference Number: MPI 1409
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
SynqNet has been expanded to support slice digital and analog I/O nodes. Slice I/O nodes are modular, which makes it possible to scale the number of digital and analog I/O to fit your application. For more information, see the Slice I/O Hardware section.

Most of the MPI interface for Slice I/O uses the same MPI methods, structures, and defines that were introduced to support SQIO. However, there are a few features that are specific to Slice I/O that required the addition of other methods.

New Methods
meiSqNodeSegmentParamGet
meiSqNodeSegmentParamSet
meiSqNodeSegmentParamDefault
meiSqNodeSegmentParamStore
meiSqNodeSegmentParamClear
meiSqNodeSegmentMemoryGet
meiSqNodeSegmentMemorySet

New Data Types
MEISqNodeSEGMENT_MAX
MEISqNodeSEGMENT_PARAMS_MAX
MEISqNodeSEGMENT_MEMORY_MAX
MEIEventTypeSQNODE_IO_FAULT

   

How do I use this feature?
For more information please see the Slice I/O Hardware section and Overview of MPI I/O.


  Reset CAN Interface without resetting the controller
    Reference Number: MPI 1405
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
In previous MPI Releases, the only way to reset/restart the CAN network was to perform a controller reset. This was a problem because resetting the controller would also reset the SynqNet network. The network would start-up using the stored flash configuration. The new function meiCanInit(...) has been added to the MPI. This function will only reset the CAN interface and will NOT affect the rest of the controller or SynqNet.

   

How do I use this feature?
meiCanInit(...).


  Added user labels to Config structures
    Reference Number: MPI 1370
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
To allow each drive partner to independantly maintain the drive parameter information for their specific drivers, the drives.dm file has now been split into manufacture-specific files (ex: kollmorgen_cd.dm and yaskawa_sgds.dm).

   

How do I use this feature?
The utility sqDriveConfig.exe and the MPI meiDriveMap functions now accept a drive map filename with wild cards (ex: *.dm). These will now seach all files that match the drivemap filename for a drive definition.


  Expand Motor I/O to 32 bits
    Reference Number: MPI 1361
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
In previous MPI versions, the Motor I/O was limited to 16 bits for dedicated and 16 bits for general purpose. Since two new dedicated inputs were added, MPIMotorDedicatedInFEEDBACK_FAULT_PRIMARY and MPIMotorDedicatedInFEEDBACK_FAULT_SECONDARY, the Motor I/O was expanded to 32 bits for dedicated and 32 bits for general purpose. The SynqNet packets, controller, and MPI methods were updated to support the additional bits.

   

How do I use this feature?
mpiMotorDedicatedIn | MPIMotorDedicatedIn


  Added user labels to Config structures
    Reference Number: MPI 1310
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
User labels have been added to the Config structures. The maximum length of the user labels is 16 characters (+ NULL terminator). The labels are stored in firmware and are saveable to flash. There are no restrictions on the type of data that is stored, but the data type is char. This feature is useful for labeling objects.

   

How do I use this feature?
Added userLabel to the following config structures:
    MEIControlConfig
    MEIAxisConfig
    MEIMotorConfig
    MEISqNodeConfig
    MEIFilterConfig

The ConfigGet/Set routines are used for accessing and modifying the labels.


  Addition of meiInfo.exe utility
    Reference Number: MPI 1305
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
The meiInfo.exe can be used to collect information about a host PC, controller, and SynqNet network. It spawns the following utilities: version.exe, meiConfig.exe, memoryDump.exe, saves the output into files and then packs the data into a single file. The default output file is meiInfo.bin.

When reporting problems to MEI, use this utility to automatically collect data about the system. Send MEI the output file (default filename is meiInfo.bin). Also, be sure to follow the guidelines for Reporting Bugs.

   

How do I use this feature?
See meiInfo Utility and meiConfig Utility.


  Triggerable MotionModify
    Reference Number: MPI 1284
    Type: New Feature
    MPI Version: 03.03.00
   

Description:
A MotionModify can now be triggered from any limit (dedicated or user). Motion parameters for a MotionModify are preloaded onto the controller. The MotionModify can be triggered by any limit (dedicated or user). The motion parameters can be used for any type of move (s-curve, trapezoidal, velocity, etc.). For example, this feature can be configured to do a velocity move to zero and set the ESTOP_TRIGGERED_MODIFY status bit. If the bit is set, then the controller and MPI will recognize the triggered modify as an ERROR like ESTOP or ABORT.

   

How do I use this feature?
MPIAxisEstopModify has been added to MPIAxisConfig. This structure is used to configure the ESTOP Modify. MPIActionE_STOP_MODIFY has been added to MPIAction, which is used to trigger the ESTOP.

 

General Changes

Version 03.03.00

  Modification of MEIDriveParamValue
    Reference Number: MPI 1734
    Type: Change Feature
    MPI Version: 03.03.00
   

Description:
In previous versions, the string field in MEIDriveMapParamValue was declared as a character pointer, which caused problems when support was added for a SynqNet drive that supported string drive parameters. The string field is now defined as an array of characters.


  Added MPIAxisMasterTypeNONE to the MPIAxisMasterType Enumeration
    Reference Number: MPI 1732
    Type: Change Feature
    MPI Version: 03.03.00
   

Description:
When using the default firmware configuration, some internal variables would change when calling mpiAxisConfigGet(...) followed by an mpiAxisConfigSet(...). The new enumeration, MPIAxisMasterTypeNONE, has been added to the MPIAxisMasterType structure to indicate that the master source is configured to the default value.


  SqNode I/O Method Optimization
    Reference Number: MPI 1699
    Type: Change Feature
    MPI Version: 03.03.00
   

Description:
In previous versions, accessing the I/O on a SQID or Slice-I/O node would take nearly 100µs. The I/O functions have been optimized so that execution time is now within 20µs.

   

How do I use this feature?
SqNode I/O methods | Overview of MPI I/O


  Change Sequence defines to support 32 Dedicated/GP I/O
    Reference Number: MPI 1685
    Type: Change Feature
    MPI Version: 03.03.00
   

Description:
Motor I/O changed from 32 bits to a total of 64 bits: 32 bits of dedicated I/O and 32 bits of general I/O. In previous versions, there was only one MPIIoType define (MPIIoTypeMOTOR) that indicated that the sequencer should use motor I/O. However, you could not specify the type of motor I/O. This limitation prevented a user from telling the Sequencer which I/O bits (general or dedicated) to use. The MPIIoType structure has been modified so that you can now specify which type of motor I/O (dedicated or general) to use with the Sequencer.

   

How do I use this feature?
The functionality has not changed. Simply replace MPIIoTypeMOTOR with either MPIIoTypeMOTOR_DEDICATED or MPIIoTypeMOTOR_GENERAL to specify the type of motor I/O. See MPIIoType.


  SynqNet Timing Schedule Improvement
    Reference Number: MPI 1681
    Type: Change Feature
    MPI Version: 03.03.00
   

Description:
The SynqNet packet schedule algorithm was improved for systems with sample rates = 16kHz or higher, where all the nodes on the system are RMBs (not drive nodes). For information about each node type, please refer to the Drive Update Frequency and Period table. Previously, the timing schedule restricted one step in the timing calculation to a multiple of the 62.5 microsecond drive update period. By removing this restriction, the improved schedule reduces the control latency and increases the maximum possible sample rate. This feature is beneficial for RMB-only systems, running at 16 kHz or higher.

   

How do I use this feature?
The following changes were made to the internal MPI/MEI libraries.

WARNING: The SynqNet packet scheduling algorithm changes may affect the control latency with systems at 16kHz or higher. You may need to adjust the closed-loop filter tuning parameters.


  Faster FPGA/Drive Firmware download over a TCP/IP connection
    Reference Number: MPI 1676
    Type: Change Feature
    MPI Version: 03.03.00
   

Description:
In previous versions, the FPGA/Drive Firmware download over a TCP/IP connection was very slow. The download process required thousands of service commands. Since each service command required 10-15 memory writes, it generated a lot of network traffic over the client/server, which drastically slowed down the download process.

   

How do I use this feature?
New client/server routines were added so that a majority of the download is done on the server-side. Although downloading firmware over a TCP/IP connection still takes a bit longer, it is much faster than before.


  Brake cannot be activated by host, even when mode = NONE
    Reference Number: MPI 1673
    Type: Change Feature
    MPI Version: 03.03.00
   

Description:
In previous versions, mpiMotorIoSet(...) (from meiDeprecated.h) did not allow the user to set or clear the brake bit. The brake logic was changed so that the brake bit can be set or cleared by the user.

   

How do I use this feature?
For example, to set the brake bit from the host application:

  1. Use mpiMotorConfigGet/ Set(...) to set the brake mode to none:

       mpiMotorConfigGet(motor, &config, NULL);
       config.brake.mode = MPIMotorBrakeModeNONE;
       mpiMotorConfigSet(motor, &config, NULL);
  2. Set or clear the brake bit with mpiMotorIoSet(...):
       /* set the brake */
       mpiMotorIoGet(motor, &io);
       io.output |= MEIMotorDedicatedOutBRAKE_RELEASE;
       mpiMotorIoSet(motor, &io);

    If the brake mode is NONE, then the user can set or clear the brake bit at any time.

    If the brake mode is not NONE, then the user can set or clear the brake bit only when the motor is disabled, because the firmware ORs the user's command with its own command to create the brake bit sent to the FPGA/Drive. Since the firmware clears the brake bit (setting the brake) when the motor is disabled, the user can either set or clear the same bit and have it propagate through to the FPGA/Drive. If the firmware sets the bit (releasing the brake), then the user has no control over the state of the bit.

  Reset Utility renamed meiReset
    Reference Number: MPI 1632
    Type: Change Feature
    MPI Version: 03.03.00
   

Description:
The Reset Utility was renamed to meiReset. The utility was renamed because there was a conflict with an XP utility that was named Reset.

   

How do I use this feature?
The meiReset Utility is used the same way as the previous Reset Utility. See meiReset Utility.


  Modification of I/O Interface for CAN and Controller Objects
    Reference Number: MPI 1585
    Type: Change Feature
    MPI Version: 03.03.00
   

Description:
The I/O interface for the CAN and Controller objects are now consistent with the Motor I/O interface introduced in the 03.02.00 MPI release. MPI releases prior to the 03.03.00 version did not provide any functions that explained what controller I/O was available on the motion controller. The MEIControlInfoIo structure has been added to provide this information.

   

How do I use this feature?
Transitioning to the New Motor I/O Functions | Controller Digital I/O Overview | Controller Digital I/O Functions


  meiPlatformCreate and meiPlatformDelete methods are private
    Reference Number: MPI 1458
    Type: Change Feature
    MPI Version: 03.03.00
   

Description:
The meiPlatformCreate/Delete methods have been removed from the MPI. Motion applications should use mpiControlPlatform(...) as an alternative to obtain a handle to the Control object's internal Platform object. Previous versions of the MPI allowed for the creation and deletion of the Controller object's internal Platform object. Deleting the Control object's internal Platform object caused unpredictable behavior of the motion system.

 

Fixed Bugs

Version 03.03.01

  Possible Assertion Failure during Network Initialization
    Reference Number: MPI 1757
    Type: Fixed Bug
    MPI Version: 03.03.01
   

Problem/Cause:
A bug existed where an assertion failure could have occurred at serviceCmd.c (line 115) upon SynqNet Network Initialization. The problem was caused by a topology mismatch error that was not being reported by the MPI when an extra node was added to the network. A topology mismatch would occur because the blockCount had changed. However, the topology mismatch was not being reported on the second pass because the blockCount from the first pass was written to the blockCount value in the firmware. When that blockCount was compared to the number of discovered blocks, it was the same, so no error was reported. As a result, when the MPI attempted to operate with the mismatched topology, an assertion failure would occur.

   

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.

  Save Topology causes demand mode 0
    Reference Number: MPI 1926
    Type: Fixed Bug
    MPI Version: 03.03.01
   

Problem/Cause:
If the topology was saved and the controller was reset, the demand mode would be zero. Demand mode 0 is defined as debug mode. SynqNet drives would not respond to demand mode 0. Thus, motors could not be servoed and torque demands would be ignored. For the S1800 drive, it would incorrectly interpret demand mode 0 as velocity and incorrectly rotate the motor based on the torque demand. The problem was caused by an internal value (modePtr) not being initialized during SynqNet initialization.

   

Fix/Solution:
The problem was corrected by changing the SynqNet initialization routines in the MPI to set the modePtr based on the saved topology information.

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

  ZMP-SynqNet Controller I/O Mapping Error
    Reference Number: MPI 1755
    Type: Fixed Bug
    MPI Version: 03.03.01
   

Problem/Cause:
A bug existed in the meiControlInfo(...) function that would incorrectly return the labels for the digital inputs on a ZMP-SynqNet controller. However, the information for an XMP-SynqNet controller was reported correctly.

   

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

  RinconZ Continuous Timer not equivalent to SamplePeriod on ZMP
    Reference Number: MPI 1745
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
Occasional "timeout" errors with the ZMP-Series controllers during SynqNet initialization and/or node FPGA/firmware download.

For the XMP, the SystemData.SamplePeriod is used to set an internal timer. When the internal timer expires, the Sharc processor is interrupted and the foreground cycle starts.

For the ZMP, the foreground cycle interrupt comes from an external source, the RinconZ FPGA. The RinconZ timer is set to the DMA_Continuous_Timer value. When the RinconZ timer expires, it interrupts the 8245 to start the foreground cycle. For the ZMP, there is no hardware connection between the SystemData.SamplePeriod and the RinconZ DMA_Continuous_Timer value.
The MPI uses the SystemData.SamplePeriod value to determine the sample rate for the controller. This works for the XMP, but is not valid for the ZMP.

   

Fix/Solution:
The DMA_Continuous_Timer value is now set to the equivalent value of the SystemData.SamplePeriod at the start of SynqNet initialization (either by the firmware or the MPI), so the MPI's timeout functions will work properly.

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

  mpiMotionModify(...) with DELAY attribute
    Reference Number: MPI 1733
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
In previous versions, the MPI and Firmware allowed the user to call mpimotionModify(...) (while the motor was moving) with a non-zero delay value, which would cause a discontinuity in the motion profile.

   

Fix/Solution:
The firmware has been modified to check for the DELAY attribute if an mpimotionModify(...) is going to take place. If the DELAY attribute is set when a motionModify is going to occur, the firmware will now ignore the motionModify and return an error code via the motion status (MEIXmpActionStatusILLEGAL_DELAY). The MPI will then convert it to MPIMotionMessageILLEGAL_DELAY and pass it up to the caller. The MPI was also modified to turn off the MPIMotionAttrMaskDELAY attribute if all of the delay values for the motion object are equal to 0.0.

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

  Velocity moves using the Sequencer creates motion with wrong parameters
    Reference Number: MPI 1728
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
In previous versions, using a sequence to create velocity moves resulted in a move with the wrong parameters (accel is used for velocity). The MPI miscalculated the destination pointer for the sequencer command that loaded the velocity, accel, and decel values into the axis' point buffer on the board.

   

Fix/Solution:
This problem has been fixed. The destination pointer is now correctly calculated and velocity moves created by using a sequence now use the correct move parameters.

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

  SqNode FPGA download failures with ZMP-SynqNet controller
    Reference Number: MPI 1727
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
When using a ZMP-SynqNet controller under specific conditions, downloading node FPGAs would fail using Motion Console and sqNodeFlash.exe.

   

Fix/Solution:
This problem was fixed.

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

  AT_TARGET axis and motion status bits do not come on until motion is complete
    Reference Number: MPI 1709
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
Although the firmware properly set the AT_TARGET bit, the MPI would report that the AT_TARGET bit was not set if the state of the axis was not IDLE. This meant that the MPI would wait until the state of the axis changed back to IDLE before allowing the true state of the AT_TARGET bit to be passed to the user.

This problem was caused by a code segment in the MPI that cleared the AT_TARGET bit if the state of the axis was not IDLE.

   

Fix/Solution:
The AT_TARGET bit is no longer masked off by the MPI.

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

  mpiRecorderStart/Stop(...) fails to start/stop a recorder
    Reference Number: MPI 1683
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
mpiRecorderStart(...) and mpiRecorderStop(...) would occasionally fail to start or stop the data recorder. The problem was created during firmware optimization. The Enable and Count words are shared by the host and firmware. The bug was caused by a race condition where the host could write the Enable and Count words and be overwritten by the controller. This caused intermittent failure of a data recorder start/stop from the host.

   

Fix/Solution:
This problem was corrected by closing the race condition for the recorder. This bug was corrected in firmware version 571A1 and later.

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

  Axis and Motor do not receive events
    Reference Number: MPI 1674
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
In previous versions, the mpiAxisEventNotifySet(...) and mpiMotorEventNotifySet(...) functions were not working properly and were putting the handle in info[1] instead of info[0] like all the other objects in the MPI.

   

Fix/Solution:
Changes were made to motor.c and axis.c. The handle is now placed in info[0] like all other MPI objects.

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

  Glentek drive's default digital output states
    Reference Number: MPI 1670
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
The Glentek drives' default opto-output state after a SynqNet initialization was "current-running." So, whenever a SynqNet initialization or reset occurred, the state of the opto-outputs would toggle. This severely limited applications for the opto-outputs.

   

Fix/Solution:
This problem has been corrected. The opto-outputs no longer toggle. After SynqNet initialization, before the FPGA I/O registers have been configured, the state of the Cyclic Output is changed to 1, which means "no current running" for the Glentek drives.

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

  Trust analog inputs not included
    Reference Number: MPI 1669
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
When SqNode I/O was implemented in the 03.02.00, the TRUST analog configurations were lost and not included in the MPI.

   

Fix/Solution:
The Trust analog inputs have been put back in the 03.03.00.

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

  meiFilterPostfilterGet(...) with 6 sections causes MPIMessageFATAL_ERROR
    Reference Number: MPI 1665
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
Attempting to use meiFilterPostfilterGet(...) when 6 sections were enabled on the controller produced the following error code: MPIMessageFATAL_ERROR.

   

Fix/Solution:
This problem has been corrected. An error message is no longer returned under these conditions.

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

  MPI Semaphore Deadlock
    Reference Number: MPI 1659
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
A possible deadlock condition existed when one application was running and another application was initializing the controller. The problem was caused by internal MPI locks that were processed in the incorrect order.

   

Fix/Solution:
This problem has been corrected. There is no longer a risk for a deadlock condition under these circumstances.

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

  SynqNet initialization errors can lead to dangerous SYNQ state
    Reference Number: MPI 1654
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
If SynqNet initialization successfully brings up the SynqNet network, but fails to initialize a drive, the initialization routine will return an error before completing the initialization on the remaining drives. This can be very dangerous because if the error happens in one application, subsequent applications will not detect the error. Also, attempts to enable the amplifier on a drive that is not fully initialized can lead to the motor running away.

   

Fix/Solution:
If any errors occur during SynqNet initialization, an error code will be returned and the network will be left in ASYNQ mode. For a review of the SynqNet initialization process, see the Overview of SynqNet Network Initialization.

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

  mpiCaptureConfigSet(...) is disabled if Capture is armed
    Reference Number: MPI 1649
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
Capture configurations could be changed while the Capture is armed. mpiCaptureConfigSet(...) was not checking the state of the Capture being configured.

   

Fix/Solution:
This problem has been corrected. Before Capture configurations are sent down to the FPGA, the state of the Capture is checked.

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

  Missing A/D Inputs with IO2KSQA2S
    Reference Number: MPI 1646
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
The A/D inputs were missing from the SynqNet node I/O info structure and were not accessible from meiSqNodeAnalogIn(...) method. The problem was caused by an incorrect value in a resource table.

   

Fix/Solution:
The problem was corrected by updating the SqNodeLib's resource table to include 4 A/Ds.

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

  VxWorks System-wide Lock bug
    Reference Number: MPI 1639
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
A bug existed in the VxWorks support platform code that left the motion control system in an "unlocked" state during a controller reset. As a result, you could access the motion controller even though it was in an unknown state.

   

Fix/Solution:
This problem has been fixed. The motion controller system is now locked during a controller reset.

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

  Unable to run utilities more than once under VxWorks
    Reference Number: MPI 1638
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
In previous versions, you could not run utilities more than once under a VxWorks system. For example, if you run a -download parameter followed by an -upload parameter in the Flash utility, the file would not be properly uploaded. This problem was caused by the fact that the command line parameters in all utilities are global variables. In VxWorks, the variables are initialized only once (at load time, not at each run time) and would retain their values from a previous run.

   

Fix/Solution:
All utilities have been modified to initialize the command-line variables at run-time. You can now properly run utilities more than once.

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

  Missing foreground cycles on ZMP-SynqNet controllers
    Reference Number: MPI 1637
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause: (ZMP-SynqNet controllers only)
Depending on the sample rate and firmware load, the ZMP-SynqNet controller could miss processing the foreground code for one sample. Evidence of a missed sample can be seen in a Motion Scope graph as spikes of the actual velocity that are twice the true actual velocity. This problem was caused by an interrupt in the ZMP-SynqNet controller. The interrupt coming from Rincon was used to set a bit, which indicated that an interrupt had occurred. The background task would periodically check the interrupt bit. If it was set, then the foreground task was called via a function call. In order to reproduce this problem, the check for the interrupt bit had to occur at least once per cycle (Rincon timer expiration). If not, then it was possible to "miss" the interrupt. This problem occurred in firmware versions 561B5 and earlier.

   

Fix/Solution:
This problem has been corrected. The Rincon interrupt was modified to directly invoke the foreground task, thus eliminating the chance of missing an interrupt. This change was added to the 569A1 firmware. Firmware versions 569A1 and later require Boot0 version 1.002. Boot0 version 1.002 is NOT compatible with firmware earlier than 561C3 and 569A1. Similarly, Boot0 versions 1.001 and earlier are NOT compatible with firmware 561C3 and 569A1 and later. For Boot0 upgrade, please contact MEI.

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

  SynqNet Initialization Errors can lead to a dangerous SYNQ state
    Reference Number: MPI 1635
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
If SynqNet Initialization successfully brings up the SynqNet network, but fails to initialize a drive, the initialization routine will return an error before completing the initialization on remaining drives. This can be very dangerous because if the error happens in one application, subsequent applications will not detect the error. Also, attempts to enable the amplifier on a drive that is not fully initialized can lead to the motor running away.

   

Fix/Solution:
This problem has been corrected. If any errors occur during the initialization of the network, an error code will be returned and the network will be left in ASYNQ mode.

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

  Startup script doesn't work when console cable is disconnected
    Reference Number: MPI 1629
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
Under certain conditions, when no VxWorks console was present, applications failed to execute from the startup script that was specified in the VxWorks boot parameters. This problem occurred when the console cable was not attached to the eXMP console port. It was caused by bugs in the MPI-VxWorks library and standard eXMP VxWorks boot image.

   

Fix/Solution:
This problem has been fixed, but requires the 1.2/5 version of the VxWorks image. Please contact MEI for more information.

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

  Possiible Deadlock between Axis Object Methods
    Reference Number: MPI 1626
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
A deadlock situation between mpiAxisConfigSet(...) and mpiAxisMotorMapGet(...) is possible when these calls are made from separate threads.

   

Fix/Solution:
This problem has been corrected.

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

  Motion fails intermittently with OUT_OF_FRAMES
    Reference Number: MPI 1625
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
When commanding multi-point path motion with mpiMotionStart(...), occasionally the Motion Supervisor, under the Status tab, would incorrectly report an OUT_OF_FRAMES. The OUT_OF_FRAMES status bit would cause an E-Stop action, halting the motion. This problem occurred with fast host PCs (2.0 GHz and higher). The problem was caused by a small timing window, where the MPI would write the frame buffer empty limit before the controller read the frame index and load index. The timing window was caused by a firmware optimization problem.

   

Fix/Solution:
This problem has been corrected. The firmware logic was modified to read the frame index and load index before the empty limit to prevent an incorrect OUT_OF_FRAMES status. The variables in the firmware were changed to be declared with volatile storage so that the compiler would not optimize out the logic.

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

  Intermittent service command errors from mpiMotorEventConfigSet(...)
    Reference Number: MPI 1621
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
When running applications in a multi-threaded environment, the following service command errors could have been returned from mpiMotorEventConfigSet(...): "service command response timeouts" and "service command unsupported." This problem was caused by an inappropriately placed service channel lock.

   

Fix/Solution:
This problem has been corrected. It is recommended that all customers running applications in a multi-threaded environment upgrade to the 03.03.00 release and later.

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

  Velocity Tolerance was returned with incorrect units
    Reference Number: MPI 1606
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
The Velocity Tolerance was listed in Motion Console in counts/sec. But, the firmware used Velocity Tolerance in counts/sample. The MPI did not convert the value when reading or writing from firmware. This meant that the value in Motion Console was really in counts/sample.

   

Fix/Solution:
The default Velocity Tolerance in the firmware is now 5 counts/sample. The MPI has been modified to make the proper conversions between the firmware and Motion Console. Motion Console correctly reports the value in counts/sec and the value in firmware is in counts/sample.

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

  Velocity Event not generated with Motion Modify
    Reference Number: MPI 1604
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
If the current velocity at the time of the motion modify is within the velocity tolerance of the new target velocity, then the firmware does NOT turn off the AT_VELOCITY status bit. This problem existed in earlier versions because the firmware evaluated AT_VELOCITY based on the current velocity and target velocity. It did not check to see if a new target velocity had been loaded.

   

Fix/Solution:
A handshake has been added to the firmware between the foreground and background. When a motion modify occurs, the modifyId frame sets a bit in the axis' MoveStatus. If the bit is set, then the background will not process AT_VELOCITY and the bit will turn off. Once the bit is off, the foreground will turn off the bit in the axis' MoveStatus. AT_VELOCITY turns off whenever a motionStart or motionModify begins execution. Evaluation of AT_VELOCITY normally occurs 1 sample after being recognized that it is off by the foreground.

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

  Access violations in Filter Object over client/server
    Reference Number: MPI 1601
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
Using any of the following filter methods over client/server may have caused memory access violations:
      mpiFilterGainSet(...)
      mpiFilterConfigSet(...)
      meiFilterPostfilterSet(...)
      meiFilterPostfilterSectionSet(...)
This was problem was caused by an internal memory managment problem.

   

Fix/Solution:
This problem has been corrected.

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

  mpiFilterGainSet(...) returns MPIMessagePARAM_INVALID
    Reference Number: MPI 1588
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
mpiFilterGainSet(...) returned MPIMessagePARAM_INVALID when run over client/server or on a ZMP-SynqNet controller. This problem was caused by an internal error in the MPI.

   

Fix/Solution:
This problem has been corrected.

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

  mpiMotionStatus(...) is incorrect after mpiMotionStart(...) for PVT moves
    Reference Number: MPI 1587
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
When checking motion status right after a motion start had been called with a PVT move, it showed that the motion had not started. This problem was caused by outdated code in MS.c in the firmware that threw out RESUME commands if the current frame was <= frameTypeID.

   

Fix/Solution:
Changes have been made so that the RESUME always takes place. The RESUME will NOT be cleared until motion actually starts and the state changes. So, when control is returned to the MPI from the motionStart(PVT) call, motion will occur and the state will be updated appropriately.

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

  User Limit does not generate an event when MS is STOPPED
    Reference Number: MPI 1562
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
When an ERROR or STOP occurred on an Axis/MS, the corresponding motor's limits did not generate interrupts to the host. If the motor status in the motor's domain (usually comes from the parent axis status and has a 1-to-1 mapping) has an ERROR (defined by ERROR_MASK) or STOP, then any bit set in the motor's status word was preserved even if the limit that set the bit was no longer triggering. Therefore, you could tell which limits triggered the action even if the limits were no longer triggering.

This caused a problem because any limit that did not cause an error type of action would also get preserved if it was triggered. This meant that if an ERROR or STOP was active and a limit that did not cause the ERROR or STOP was triggered, then the corresponding bit in the motor's limit was set and preserved until the ERROR or STOP was cleared.

In order for a limit to generate an event, there must be a transition of its corresponding bit in the motor's status word. If the limit's bit is set and preserved because of an ERROR or STOP, then there is no way for a transition of the bit to occur no matter how many times the limit is triggered and cleared.

   

Fix/Solution:
Changes have been made so that if an ERROR or STOP is active, only limits that could have caused the ERROR or STOP will be preserved if they are set. Those limits can also generate interrupts to the host.

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

  meiMapNameToParams(...) now decodes Rincon Addresses
    Reference Number: MPI 1378
    Type: Fixed Bug
    MPI Version: 03.03.00
   

Problem/Cause:
meiMapNameToParams(...) was unable to properly decode the rincon addresses from the rincon memory strings. The algorithm used to go from address-to-string and string-to-address did not work with dynamic memory locations since there were no static structures.

   

Fix/Solution:
The map module now goes through and builds its symbol list based on what resources are located on the node. meiMapNameToParams(...) now properly decodes rincon addresses.

    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

  Multiple eventMgr objects over client/server bug
    Reference Number: MPI 1578
    Type: Existing Bug
    MPI Version: 03.03.00
   

Problem/Cause:
While MEI discourages the use of multiple eventMgrs objects for one controller, some customers still use multiple eventMgrs in specific situations. A problem has been found while running multiple eventMgr objects over client/server. This problem can cause the loss of events and will deadlock the system in certain situations.


  SqNode upStreamError limits not saved in flash
    Reference Number: MPI 1505
    Type: Existing Bug
    MPI Version: 03.03.00
   

Problem/Cause:
The MEISqNodeConfig.upStreamError configuration is not stored in the controller's flash memory by meiSqNodeFlashConfigSet(...). If you change the upStreamError value, try to save it to flash and reset the controller. The upStreamError will revert back to the default value.

 

Limitations

Currently, there are no known limitations.

 

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