.

Release Note
MPI Library Version 03.02.06

Release Type
MPI Version
Release Date
Patch Release
03.02.06
29Apr2005
Patch Release
03.02.03
10Mar2005
Patch Release
03.02.02
25Feb2005
Patch Release
03.02.01
01Feb2005
Production Release
03.02.00
16Dec2004

  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.02.04
     Addition of Kollmorgen S200 Drive Parameters - MPI1647

Version 03.02.00
     Support for Kollmorgen S200 Drive - MPI1512
     Addition of Probe for Yaskawa SGDS Drive - MPI1499
     SynqNet High Bandwidth Schedule Improvements - MPI1498
     Support for FPGA Branch Information - MPI1483
     Path Moves and Shortest Path - MPI1482
     Support for AMC Drive DQ111RE - MPI1479
     eXMP-VxWorks now supports VxWorks 5.5 - MPI1457
     Support for VxWorks 5.5 Operating System - MPI1454
     Addition of missing meiCanControl and meiCanNumber methods - MPI1446
     New FPGA for Kollmorgen CD Drive (2 motors, one w/pulse) - MPI1445
     Support for PicoDAD drive - MPI1444
     Kollmorgen CD and PicoDAD Drive FW download - MPI1443
     Fan controller support for ZMP - MPI1419
     Support for SynqNet I/O Nodes - MPI1408
     New Motor I/O functions - MPI1359
     Support for programmable inputs ranges for ADCs on RMB-10V2 nodes - MPI1214
     Host Interrupt Modification: SyncInterrupt - MPI1205

    General Changes
     

Version 03.02.00
     Changed number of compensators to 8 - MPI1537
     Changes to MPICanMessage - MPI1494
     Addition of MEIControlIoBitXESTOP to meiControlIoBitGet - MPI1416

    Fixed Bugs
     

Version 03.02.06
    Missing foreground cycles on ZMP-SynqNet controllers - MPI1666
    meiFilterPostfilterGet(...) with 6 sections causes MPIMessageFATAL_ERROR - MPI1664
    No Analog I/O for Trust TA805-D - MPI1660
    MPI Semaphore Deadlock - MPI1655

Version 03.02.05
    SynqNet Initialization Errors can lead to a dangerous SYNQ state - MPI1651

Version 03.02.04
    Glentek drive's default digital ouptuts state - MPI1648
    Missing A/D inputs with IO2KSQA2S - MPI1645

Version 03.02.03
    Startup script doesn't work when the console cable is disconnected - MPI1628

Version 03.02.02
    Motion fails intermittently with OUT_OF_FRAMES - MPI1624
    Possible deadlock between Axis object methods - MPI1623
    Intermitent service command errors from mpiMotorEventConfigSet(...) - MPI1619

Version 03.02.01
    Access violations in Filter object over client/server - MPI1600
    meiSqNodeAnalogInput(...) returns incorrect data - MPI1594
    Drive Monitors not configurable through MPI - MPI1586
    mpiMotorEventConfigSet(...) has incorrect data size for control memory read - MPI1584
    mpiFilterGainSet(...) returns MPIMessagePARAM_INVALID - MPI1583
    Bug when calling mpiAxisEventNotifySet(...) and mpiMotorEventNotifySet(...) - MPI1577
    SynqNet Lock is now released in the Kollmorgen Drive Download Routine - MPI1576
    Velocity Tolerance was returned with incorrect units - MPI1575

Version 03.02.00
    mpiProbeCreate(...) fails after topology is saved - MPI1565
    mpiFilterGainGet(...) returns ARG_INVALID with ZMP - MPI1560
    Compensator Range Problem - MPI1553
    Saving sample rate to flash bug (ZMP only) - MPI1545
    MPICaptureStateInvalid should NEVER occur - MPI1539
    meiCanNodeInfo(...) application error when MEICanNodeInfo == NULL - MPI1538
    Index is not in the Event Status for Data Recorders - MPI1521
    Trace module was not thread safe - MPI1462
    Saving topology to flash causes amplifiers to be disabled - MPI1427
    mpiMotionStatus(...) does not report OUT_OF_FRAMES errors - MPI1421
    MEIFilterGainPIVCoeff missing an enum for KA2 - MPI1213
    meiPlatformTimerCount() bug in Linux release - MPI1207
    Irregular motion for PVT/Host frame moves - MPI1067; MPI1069

    Open Issues
      Existing Bugs
    Compatibility check for client/server - MPI1684
    Multiple eventMgr objects over client/server bug - MPI1578
    Recorder does not stop when stop count > 0 - MPI1573

      Limitations
     Currently, there are no known limitations.
         

 

New Features

Version 03.02.04

  Addition of Kollmorgen S200 Drive Parameters
    Reference Number: MPI 1647
    Type: New Feature
    MPI Version: 03.02.04
   

Description:
The new S200 drive specification has 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.

 

Version 03.02.00

  Support for Kollmorgen S200 Drive
    Reference Number: MPI 1512
    Type: New Feature
    MPI Version: 03.02.00
   

Description:
Support has been added to the MPI for the Kollmorgen S200 Drive. Support includes drive-specific error codes, monitor configuraion, and drive parameters. kollmorgen_s200.h and kollmorgen_s200.c were added to the sqNodeLib library.

   

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


  Addition of Probe for Yaskawa SGDS Drive
    Reference Number: MPI 1499
    Type: New Feature
    MPI Version: 03.02.00
   

Description:
Probe support has been added to the MPI for the Yaskawa SGDS Drive. Changes were made to the sqNodelib.h and mei_rmb.c drive modules.

   

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


  SynqNet High Bandwidth Schedule Improvements
    Reference Number: MPI 1498
    Type: New Feature
    MPI Version: 03.02.00
   

Description:
The SynqNet packet scheduling algorithms were improved to handle high sample rate (16kHz and higher) systems. The improvements included optimizations and adjustments to the timing algorithms. If you are upgrading from a previous software release, you should check the total control latency between the old and new software. If there is a difference in the control latency, then you can determine if you need to adjust your closed-loop servo tuning parameters. The total control latency can be read with the meiSynqNetTiming(...) method.

   

How do I use this feature?
See meiSynqNetTiming


  Support for FPGA Branch Information
    Reference Number: MPI 1483
    Type: New Feature
    MPI Version: 03.02.00
   

Description:
FPGA branch support has been added to MEISqNodeInfoFPGA and will be reported in the version.exe utility. The FPGA branch version was added in FPGAs with SqMac version 0x0230 (and greater). If the SqMac version is 0x0230 (or greater), then the branch version will properly show the revision information. If the SqMac version is less than 0x0230, then the branch version will show 0xFF.

   

How do I use this feature?
The FPGA's now support branching, and the branch information should be used to determine if the correct FPGA is being used. FPGA branch information is now returned by MEISqNodeInfoFPGA and is reported by the version.exe utility.


  Path Moves and Shortest Path
    Reference Number: MPI 1482
    Type: New Feature
    MPI Version: 03.02.00
   

Description:
Shortest path algorithm is applied to the difference between the last loaded point and the first point of the path move being loaded. If the difference exceeds 231, then the points list is adjusted by 232 so that the calculated velocity, accel, and jerk will not cause the motor to take off. This applies to all path motion (PT, PVT, PVTF, etc...).

   

How do I use this feature?
If the current position is near the rollover (231) and the first point in the next point list is past the rollover, the user could specify the first point two different ways.

Example

Current Position = 2147483638 (231 - 10)
First Position in Point List = 2147483658 ((231 + 10)
or First Position in Point List = -2147483638 ((231 + 10) - 232)

From the controller's point of view, both first positions are the same value, but from the MPI's point of view, they are 232 apart. With the shortest path algorithm, -2147483638 is converted to 2147483658 so that the motion between the current position and the first position is smooth and does not cause excessive acceleration or velocity.

NOTE: The shortest path algorithm only applies to the delta between the current position and the first point in a points list (path motion). It DOES NOT apply to points within the points list.


  Support for AMC Drive DQ111RE
    Reference Number: MPI 1479
    Type: New Feature
    MPI Version: 03.02.00
   

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 DQ113EE, please contact Advanced Motion Controls.


  eXMP-VxWorks now supports VxWorks 5.5
    Reference Number: MPI 1457
    Type: New Feature
    MPI Version: 03.02.00
   

Description:
Support has been added for VxWorks 5.5 on eXMP-VxWorks controllers. Please contact MEI Sales for more information.

   

How do I use this feature?
For more information please contact MEI Sales or go to the eXMP-SynqNet Hardware section.


  Support for VxWorks 5.5 Operating System
    Reference Number: MPI 1454
    Type: New Feature
    MPI Version: 03.02.00
   

Description:
The VxWorks 5.5 operating system is now supported by the MPI.

   

How do I use this feature?
For more information go to the eXMP-SynqNet Hardware section.


  Addition of missing meiCanControl and meiCanNumber methods
    Reference Number: MPI 1446
    Type: New Feature
    MPI Version: 03.02.00
   

Description:
Addition of missing xxxControl and xxxNumber methods have been added to the MPI library.
    meiCanControl
    meiCanNumber

   

How do I use this feature?
See meiCanControl and meiCanNumber.


  New FPGA for Kollmorgen CD Drive (2 motors, one w/pulse)
    Reference Number: MPI 1445
    Type: New Feature
    MPI Version: 03.02.00
   

Description:
A new FPGA has been added to the Kollmorgen CD family that supports 2 motors, one of which is pulse. For details, see C0FE0034_0345.

   

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


  Support for PicoDAD Drive
    Reference Number: MPI 1444
    Type: New Feature
    MPI Version: 03.02.00
   

Description:
Support has been added for the Kollmorgen PicoDAD Drive. kollmorgen_picodad.c and kollmorgen_picodad.h were added to the sqNodeLib library.

   

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


  Kollmorgen CD and PicoDAD Drive FW download
    Reference Number: MPI 1443
    Type: New Feature
    MPI Version: 03.02.00
   

Description:
Drive Firmware download has been added for the CD and PicoDAD. However, the DASA drive does not support the downloading of firmware over SynqNet.

   

How do I use this feature?
This feature should be used to upgrade the drive firmware on Kollmorgen Drives. Downloading drive firmware can be done through the sqNodeFlash Utility or through the meiSqNodeDownload(...) method in the MPI.


  Fan controller support for ZMP
    Reference Number: MPI 1419
    Type: New Feature
    MPI Version: 03.02.00
   

Description:
Support has been added for monitoring the fan operation on a ZMP controller.
For ZMP only: A systemData(controller).Status bit is set if the Fan Controller detects an error (over temp, etc...). This status bit can be configured to interrupt the host. The host can use a new MPI function to read the fan controller's status words to determine the cause of the alarm.

    How do I use this feature?
Interrupt code in firmware is always active, so if a problem occurs, the interrupt will also occur and the firmware will set the appropriate systemData.Status bit. If the user wants the firmware to notify the host, the user can use the ControlNotify functions in the MPI. The user can use the ControlStatus functions in the MPI to check the fan controller status.
   

See Also:
MPIControlStatus | MPIControlFanStatusFlag | MPIControlFanStatusMask


  Support for SynqNet I/O Nodes
    Reference Number: MPI 1408
    Type: New Feature
    MPI Version: 03.02.00
   

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

New MPI methods, structures, and defines have been added to support SynqNet Node I/O. During SynqNet initialization, the nodes, the number of I/O modules (segments), and I/O bits on the modules are discovered. A new MEISqNodeInfoIo{...} structure has been added to the MEISqNodeInfo{...} structure. This structure contains the number of digital inputs, digital outputs, analog inputs, analog outputs, and number of segments. The digital and analog inputs/outputs can be accessed with the following methods:

MEISqNodeInfo

meiSqNodeSegmentDigitalIn
meiSqNodeSegmentDigitalOutGet /Set
meiSqNodeSegmentAnalogIn
meiSqNodeSegmentAnalogOutGet /Set

   

How do I use this feature?
For more information see SynqNet I/O Hardware and Overview of MPI I/O


  New Motor I/O functions
    Reference Number: MPI 1359
    Type: New Feature
    MPI Version: 03.02.00
   

Description:
New methods and bit defines have been added to read, write, and identify the motor object's digital I/O. The new methods were added to allow future expansion for the dedicated and general purpose digital I/O and to provide a consistent interface for all digital I/O (Control, Can, SynqNet, and Motor). The MEIMotorInfo{...} structure was expanded to provide information about which I/O bits are supported, text labels, and supported sources for general purpose I/O. The old motor I/O methods and defines have been moved to meiDeprecated.h for backwards compatibility. In future releases, new methods will be added for Control and Can I/O.

For more information, please see Transitioning to the New Motor I/O Functions.

The following functions have been added to the MPI :
     mpiMotorDedicatedIn
     mpiMotorDedicatedOutGet
     mpiMotorGeneralIn
     mpiMotorGeneralOutGet
     mpiMotorGeneralOutSet

These functions replaced mpiMotorIoGet/Set, which are now in meiDeprecated.h.

   

How do I use this feature?
See MPIMotor for more information.


  Support for programmable inputs ranges for ADCs on RMB-10V2 Nodes
    Reference Number: MPI 1214
    Type: New Feature
    MPI Version: 03.02.00
   

Description:
RMB-10V2 nodes support programmable input ranges for the ADC channels. Software support has been added to allow the input range to be selected.

The following functions have been added to the MPI in mei_rmb.h:
     rmbAnalogInRangeGet
     rmbAnalogInRangeSet

   

How do I use this feature?
See rmbAnalogInRangeGet and rmbAnalogInRangeSet.
See Accessing Analog Data.


  Host Interrupt Modification: SyncInterrupt
    Reference Number: MPI 1205
    Type: New Feature
    MPI Version: 03.02.00
   

Description:
Applications may need to synchronize with the controller every Nth sample. The MPI and firmware have been modified to allow the user to define a controller synchronization interrupt period.

If the Period == 0, then no SyncInterrupts are generated.
If the Period == N, then there will be 1 SyncInterrupt generated every N samples.

Interrupts caused by background status changes (events, limits, etc...) are not affected by this change, although the time at which the interrupt is generated is now much more predictable.

   

How do I use this feature?
SyncInterrupts should be used if the user needs a regular interrupt every sample or every N samples. The interrupt could be used to signal the user's code to process some piece of data. The syncInterruptPeriod can be configured with mpiControlConfigSet(...), using the MEIControlConfig{...} structure.

In the case where N = 1 (interrupt every sample), the user's code could wake, process data, and write some command (i.e. DAC output) to the controller. New functionality has been added to make sure that the user's code has finished executing before the foreground starts SynqNet transmission. If the user wants the firmware to monitor whether or not the user's code finished before the foreground starts SynqNet transmission, then the user's code should set the SyncInterrupt.HostProcessFlag upon entry to its routine. It should then process the data. When it has finished, it should clear the SyncInterrupt.HostProcessFlag. If the SyncInterrupt.HostProcessFlag is still set when the firmware starts SynqNet transmission, then the firmware will set a SystemData.Status bit indicating that the host did not finish its process in time. Like all status bits, it can then interrupt the host and be handled by a second interrupt handler.

   

See Also
Sync Interrupt | syncInterrupt.c

 

 

General Changes

Version 03.02.00


Changed number of compensators to 8
    Reference Number: MPI 1537
    Type: General Change
    MPI Version: 03.02.00
   

Description:
To accomodate customer needs for more compensators, the define for MEIXmpMAX_Compensators was changed from 4 to 8.

   

How do I use this feature?
The user can now use up to 8 compensators.



Changes to MPICanMessage
    Reference Number: MPI 1494
    Type: General Change
    MPI Version: 03.02.00
   

Description:
Changed error message "MPICanMessageINTERFACE_NOT_FOUND" to "MEICanMessageINTERFACE_NOT_FOUND." MEICanMessageCAN_INVALID was also added.

    Code Interface:


can.h


NEW
typedef enum {
     MEICanMessageFIRMWARE_INVALID,
     MEICanMessageFIRMWARE_VERSION,
     MEICanMessageNOT_INITIALIZED,
     MEICanMessageCAN_INVALID,
     MEICanMessageIO_NOT_SUPPORTED,
     MEICanMessageFILE_FORMAT_ERROR,
     MEICanMessageUSER_ABORT,
     MEICanMessageCOMMAND_PROTOCOL,
     MEICanMessageINTERFACE_NOT_FOUND,
     MEICanMessageNODE_DEAD,
     MEICanMessageSDO_TIMEOUT,
     MEICanMessageSDO_ABORT,
     MEICanMessageSDO_PROTOCOL,
     MEICanMessageTX_OVERFLOW,
     MEICanMessageRTR_TX_OVERFLOW,
     MEICanMessageRX_BUFFER_EMPTY,
     MEICanMessageBUS_OFF,
     MEICanMessageSIGNATURE_INVALID,
} MEICanMessage;

For more information, see MEICanMessage.

   

How do I use this feature?
MEICanMessageCAN_INVALID was added to validate the Can network.
When an invalid Can number is specified, it will return the MEICanMessageCAN_INVALID error.


  Addition of MEIControlIoBitXESTOP to meiControlIoBitGet
    Reference Number: MPI 1416
    Type: New Feature
    MPI Version: 03.02.00
   

Description:
The MEIControlIoBitXESTOP has been added to MEIControlIoBit. It was previously missing from the enum.

    How do I use this feature?
You can now check the XESTOP bit by the meiControlIoBitGet function. Because MEIControlIoBitXESTOP has input attributes, the meiControlIoBitSet is not supported.
   

See Also:
meiControlIoBitGet | MEIControlIoBit


 

Fixed Bugs

Version 03.02.06

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

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 fixed. Another interrupt bit check was added (it was previously left out) to the 561B6 firmware in the AxisStatus loop. Changes were also made to the foreground/background interaction in order to get the Rincon interrupt to call the foreground code. Theses changes were added to the 561C2 and 569A1 firmware.

In firmware versions 561B6, the background frequently checks for the interrupt bit, thereby decreasing the chances of "missing" an interrupt.
In firmware versions 561C2 and 569A1, the interrupt structure was changed so that the Rincon interrupt directly called the foreground task, thus eliminating the need to check for the interrupt bit and the chance of "missing" an interrupt.

Firmware versions 561C2, 569A1 and later require Boot0 version 1.002.
Boot0 version 1.002 is NOT compatible with firmware earlier than 561C2 and 569A1.
Similarly, Boot0 versions 1.001 and earlier are NOT compatible with firmware 561C2 and 569A1 and later.

    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 1664
    Type: Fixed Bug
    MPI Version: 03.02.06
   

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

  No Analog I/O for Trust TA805-D
    Reference Number: MPI 1660
    Type: Fixed Bug
    MPI Version: 03.02.06
   

Problem/Cause:
When SqNode I/O was first implemented, the Trust analog configurations were not included.

   

Fix/Solution:
The analog configurations have been added for the Trust TA805-D.

    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 1655
    Type: Fixed Bug
    MPI Version: 03.02.06
   

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

 

Version 03.02.05

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

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

 

Version 03.02.04

  Glentek drive's default digital ouptuts state
    Reference Number: MPI 1648
    Type: Fixed Bug
    MPI Version: 03.02.04
   

Problem/Cause:
On Glentek drives, the default opto-out state after a SynqNet initialization was "current-running." This means that whenever a SynqNet initialization or reset occurred, the state of the opto-outputs would toggle, which severely limited the applications for the opto-outputs. This problem was caused by old hardware specifications for the opto-outputs.

   

Fix/Solution:
This problem has been fixed. The opto-outputs no longer toggle. After Synqnet initialization and 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.

  Missing A/D inputs with IO2KSQA2S
    Reference Number: MPI 1645
    Type: Fixed Bug
    MPI Version: 03.02.04
   

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

   

Fix/Solution:
This 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.

 

Version 03.02.03

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

Problem/Cause:
Under some conditions, when no VxWorks console was present, applications would not 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. This problem was caused by a bug in the MPI-VxWorks library and a bug in the standard eXMP VxWorks boot image.

   

Fix/Solution:
This problem has been fixed, but requires 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.

 

Version 03.02.02

  Motion fails intermittently with OUT_OF_FRAMES
    Reference Number: MPI 1624
    Type: Fixed Bug
    MPI Version: 03.02.02
   

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

  Possible deadlock between Axis object methods
    Reference Number: MPI 1623
    Type: Fixed Bug
    MPI Version: 03.02.02
   

Problem/Cause:
A deadlock situation between meiAxisConfigSet(...) and mpiAxisMotorMapGet(...) was possible when these calls were made from separate threads.

   

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.

  Intermitent service command errors from mpiMotorEventConfigSet(...)
    Reference Number: MPI 1619
    Type: Fixed Bug
    MPI Version: 03.02.02
   

Problem/Cause:
A customer reported "service command response timeouts" and "service command unsupported" errors from mpiMotorEventConfigSet(...) running in a multi-threaded environment. The problem was due to an inappropriately placed service channel lock.

   

Fix/Solution:
This problem has been fixed. It is recommended that all customers running applications in a multi threaded environment upgrade to a release containing this fix (03.02.02 and newer).

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

 

Version 03.02.01

  Access violations in Filter object over client/server
    Reference Number: MPI 1600
    Type: Fixed Bug
    MPI Version: 03.02.01
   

Problem/Cause:
Using any of the following filter methods over client/server would potentially cause memory access violations:
     mpiFilterGainSet(...)
     meiFilterConfigSet(...)
     meiFilterPostfilterSet(...)
     meiFilterPostfilterSectionSet(...)
This bug was caused by an internal memory managment problem.

   

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.

  meiSqNodeAnalogInput(...) returns incorrect data
    Reference Number: MPI 1594
    Type: Fixed Bug
    MPI Version: 03.02.01
   

Problem/Cause:
The deprecated function meiSqNodeAnalogInput(...) does not return the state of the selected analog input correctly. A workaround is to use the new MPI function meiSqNodeAnalogIn(...). This bug was caused by an error in the MPI function.

   

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.

  Drive Monitors not configurable through MPI
    Reference Number: MPI 1586
    Type: Fixed Bug
    MPI Version: 03.02.01
   

Problem/Cause:
meiSqNodeDriveMonitorConfigSet(...) would always configure Drive 0 regardless of the drive specified. The driveIndex was not getting passed through the dispatch, so all the service commands were going to Drive 0.

   

Fix/Solution:
driveIndex is now being included in the service command that configures the monitor. All Drive Monitors are now configurable through the MPI library.

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

  mpiMotorEventConfigSet(...) has incorrect data size for control memory read
    Reference Number: MPI 1584
    Type: Fixed Bug
    MPI Version: 03.02.01
   

Problem/Cause:
If mpiMotorEventConfigSet(...) was used to configure the Encoder Fault Event, the Encoder Type would change from Drive to Quad AB after the configuration was done. This problem was caused by a control memory read with an invalid data size.

   

Fix/Solution:
The MPI now has the correct data size for the memory read.

    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 1583
    Type: Fixed Bug
    MPI Version: 03.02.01
   

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

   

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.

  Bug when calling mpiAxisEventNotifySet(...) and mpiMotorEventNotifySet(...)
    Reference Number: MPI 1577
    Type: Fixed Bug
    MPI Version: 03.02.01
   

Problem/Cause:
When mpiAxisEventNotifySet(...) and mpiMotorEventNotifySet(...) were called, host processes were unable to receive axis and motor events. Only mpiMotionEventNotifySet(...) allowed the host process to receive axis and motor events.

   

Fix/Solution:
This problem has been fixed. It is no longer necessary to call mpiMotionEventNotifySet(...) to receive axis and motor events.

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

  SynqNet Lock is now released in the Kollmorgen Drive Download Routine
    Reference Number: MPI 1576
    Type: Fixed Bug
    MPI Version: 03.02.01
   

Problem/Cause:
Drive download would freeze all subsequent tasks under Linux. (This problem could also exist in other systems.) In the Kollmorgen drive download routine, a SynqNet Lock was being taken, but not released.

   

Fix/Solution:
This problem has been fixed. SynqNet Lock now released in the Kollmorgen drive download routine.

    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 1575
    Type: Fixed Bug
    MPI Version: 03.02.01
   

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.

 

Version 03.02.00

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

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.

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

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.

  Compensator Range Problem
    Reference Number: MPI 1553
    Type: Fixed Bug
    MPI Version: 03.02.00
   

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 the 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 1545
    Type: Fixed Bug
    MPI Version: 03.02.00
   

Problem/Cause:
In specific conditions, the ZMP would run at an unexpected sample rate. This condition occurred when topology had been saved to flash (meiSynqNetFlashTopologySave) while the controller was at one sample rate and then the sample rate of a different value was saved to flash (using mpiControlConfigSet). This sequence of events caused 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 1539
    Type: Fixed Bug
    MPI Version: 03.02.00
   

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.

  meiCanNodeInfo(...) application error when MEICanNodeInfo == NULL
    Reference Number: MPI 1538
    Type: Fixed Bug
    MPI Version: 03.02.00
   

Problem/Cause:
With NULL argument values passed into meiCanNodeInfo, default values were not filled in for the MEICanNodeInfo structure.

   

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.

  Index is not in the Event Status for Data Recorders
    Reference Number: MPI 1521
    Type: Fixed Bug
    MPI Version: 03.02.00
   

Problem/Cause:
Index information was not included in the signal sent to the host. Index info is needed to know which data recorder signaled the host.

   

Fix/Solution:
Index info is now included in the signal sent to the host.

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

  Trace module was not thread safe
    Reference Number: MPI 1462
    Type: Fixed Bug
    MPI Version: 03.02.00
   

Problem/Cause:
Previous versions of the MPI did not use a mutex to protect internal trace data.

   

Fix/Solution:
The trace module now uses a mutex to prevent internal data from being corrupted before the trace data is written. As a consequence, all calls from the MPI to custom trace functions, specified by meiPlatformTraceFunction(...), are also protected with a mutex.

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

  Saving topology to flash causes amplifiers to be disabled
    Reference Number: MPI 1427
    Type: Fixed Bug
    MPI Version: 03.02.00
   

Problem/Cause:
When saving objects to flash, the motors would normally stay enabled and run correctly. However, when saving topology to flash, the motor amplifiers would be unexpectedly disabled. A topology save or clear command affected low-level controller configuration, which required re-initializing the network and as a result, disabled all controller amplifiers.

   

Fix/Solution:
An error check has been placed into meiSynqNetFlashTopologySave/Clear routines to avoid an unexpected disabling of motor amplifiers. If either low-level routines are called with any amplifiers enabled, a return value of MEISynqNetMessageTOPOLOGY_AMPS_ENABLED, will be returned and the method call will fail.

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

  mpiMotionStatus(...) does not report OUT_OF_FRAMES errors
    Reference Number: MPI 1421
    Type: Fixed Bug
    MPI Version: 03.02.00
   

Problem/Cause:
mpiMotionStatus(...) does not report OUT_OF_FRAMES errors. MPI reads axis and motor status for all of the Motion Supervisor subobjects and creates a motion status when mpiMotionStatus(...) is called. OUT_OF_FRAMES errors only exist in the Motion Supervisor status and not in the Axis (or Motor) status words.

   

Fix/Solution:
Modifications were made to mpiMotionStatus(...) in the MPI to also read the Motion Supervisor status from the board and/or in those bits that do not exist in the axis status when creating the motion status. mpiMotionStatus(...) now returns a status that reflects the state of the OUT_OF_FRAMES bit.

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

  MEIFilterGainPIVCoeff missing an enum for KA2
    Reference Number: MPI 1213
    Type: Fixed Bug
    MPI Version: 03.02.00
   

Problem/Cause:
MEIFIlterGainPIVCoeff was missing an enum of Ka2.

   

Fix/Solution:
Added PIV coefficient Ka2 to MEIFilterGainTypePIV.

Added Ka2 coefficient to the structure MEIFilterGainPIVCoeff as MEIFilterGainPIVCoeffNOISE_FILTERFFT, and changed Ka1 filter name to be MEIFilterGainPIVCoeffSMOOTHINGFILTER_GAIN.

Added Ka2 coefficient to the MEIFilterGainPIV structure as filterFFT, and renamed Ka1 coefficient to smoothingFilterGain, since it is the gain of the PIV feedback velocity smoothing filter.
      0 = no smoothing
      1 = maximum smoothing

    Code Interface:


stdmei.h


NEW
static MEIDataType MEIFilterGainTypePIV[MPIFilterCoeffCOUNT_MAX] =
{
    ...
    MEIDataTypeFLOAT, /* Ka0 */
    MEIDataTypeFLOAT, /* Ka1 */
    MEIDataTypeFLOAT  /* Ka2 */
};

For more information, see MEIFilterGainTypePIV.

 

typedef enum {
    ...
    MEIFilterGainPIVCoeffNOISE_POSITIONFFT,    /* Ka0 */
    MEIFilterGainPIVCoeffSMOOTHINGFILTER_GAIN, /* Ka1 */
    MEIFilterGainPIVCoeffNOISE_FILTERFFT,      /* Ka2 */

} MEIFilterGainPIVCoeff;

For more information, see MEIFilterGainPIVCoeff.

 

typedef struct MEIFilterGainPIV {
    ...
    struct {
          float positionFFT; /* Ka0 */
          float smoothing;   /* Ka1 */
          float filterFFT;   /* Ka2 */
     } noise;
} MEIFilterGainPIV;

For more information, see MEIFilterGainPIV.

    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 1207
    Type: Fixed Bug
    MPI Version: 03.02.00
   

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.

  Irregular motion for PVT/Host frame moves
    Reference Number: MPI 1067; MPI1069
    Type: Fixed Bug
    MPI Version: 03.02.00
   

Problem/Cause:
For PVT/Host frame moves, motionStart followed by another motionStart caused irregular motion. This occurred with PVT/Host frame moves in motionStart where the frame Buffer was flushed, followed quickly by another motionStart with the APPEND attribute. The result was that the MPI loaded the second motionStart's frames on top of the first motionStart's frames. The MPI used the FrameIndex instead of the LoadIndex to determine the starting point for the new frame list.

   

Fix/Solution:
The MPI was modified to check for the APPEND attribute. If the APPEND attribute was set, then the MPI used the LoadIndex instead of the FrameIndex to determine the starting point for the new frame list. This problem has been fixed. The second motionStart no longer loads its frames on top of the first motionStart.

    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

  Compatibility check for client/server
    Reference Number: MPI 1684
    Type: Existing Bug
    MPI Version: 03.02.00
   

Problem/Cause:
When using the MPI via client/server there is no compatibility checking between the MPI library on the client and the library on the server. As long as you use the same MPI version on the client and server side, there will be no problems. In future versions, a client/server compatibility check will be added to prevent use with incompatible versions.


  Multiple eventMgr objects over client/server bug
    Reference Number: MPI 1578
    Type: Existing Bug
    MPI Version: 03.02.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.


  Recorder does not stop when stop count > 0
    Reference Number: MPI 1573
    Type: Existing Bug
    MPI Version: 03.02.00
   

Problem/Cause:
When the Recorder trigger conditions are configured for a start trigger count = –1 and a stop trigger count > 0, the data recorder continues to collect data after the stop trigger condition has been exceeded.

 

Limitations

Currently, there are no limitations.

 

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