.

Release Note
MPI Library Version 04.03.11

Release Type
MPI Version
Release Date
Production Release
04.03.11
19Sep2014
Production Release
04.03.10
2Aug2014
Production Release
04.03.09
20Jun2014
Production Release
04.03.08
21Mar2014
Production Release
04.03.07
30Dec2013
Production Release
04.03.06
18Oct2013
Production Release
04.03.05
1OCT2013
Production Release
04.03.04
27AUG2013
Production Release
04.03.03
23JUL2013
Production Release
04.03.02
10May2013
Production Release
04.03.01
5Apr2013
Production Release
04.03.00
11Mar2013

 

  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 04.03.10
    SynqNet Support for Yaskawa SGDV series drives - MPI2667

Version 04.03.00 – Version 04.03.09
    <none>


    General Changes
     

Version 04.03.02 – Version 04.03.09
    <none>

Version 04.03.01
    Flash.c replaced by flashSample.c - MPI2618

Version 04.03.00
    <none>

    Fixed Bugs
     

Version 04.03.11
   mpiCompareLoadStartStopPoints had a memory leak - MPI2676

Version 04.03.10
   The sqNodeFlash will report an error - MPI2670
   dumpEvents cannot correctly get all events - MPI2668

Version 04.03.09
   Position and Velocity data of PIV_GT are not outputting to the User Buffer - MPI2666
   PIV_GT Block Kvff Bug - MPI2665
   When the motor gear is saved, the encoder position may have error - MPI2658
   mpiCaptureConfigSet returns error: Capture is already armed - MPI2654

Version 04.03.08
    Incorrect alarm code check after SGDZBS pole detection - MPI2659
    mpiControlEventNotifyGet calls mpiPlatformObjectLockTake twice - MPI2656

Version 04.03.07
    meiAxisWait returns immediately if samplCounterSet is 0 - MPI2644
    Tolerance configuration is zero after reset when topology is saved - MPI2645
    Axis drift for Idle axes When Disable action is set to cmd=actual - MPI2650

Version 04.03.06
    UserVersion and UserLabel do not save to Flash - MPI2638
    UserBuffer and VolatileBuffer do not save to Flash - MPI2637
    sqToplogySave reports an error in systems with a lot of motors - MPI2632

Version 04.03.05
    The function of Home1.c returns error 0x631 - MPI2646
    The RecorderBuffer resource collides with CompareValueBuffer - MPI2634
    AKD-SQ Reduce Position Jump on Amp Enable - MPI2628

Version 04.03.04
    S200 invalid multi-turn feedback (AUXFB Endat or Mitutoyo) - MPI2630
    MPI reports copy64 error when running MoCon/motion4 sample program at high sample rates - MPI2629

Version 04.03.03
    S200 absolute multi-turn feedback invalid after mpiMotorConfigSet() - MPI2621
    64-bit driver performance degrades over time - MPI2626

Version 04.03.02
    mpiUserLimitConfigSet() returns timeout in multi-threaded application - MPI2619
    Coordinated motion does not set hold values proberly - MPI2622

Version 04.03.01
      <none>

Version 04.03.00
    mpiUserLimitConfig() hangs - MPI2616
    ControlConfigSet() overwrites Axis 2 gear config - MPI2615
    Dependent Objects memory leak - D-04233



    Open Issues
     

Existing Bugs
    <none>

Limitations
    Multiple Drive Map Files
    mpiFilterPostfilterSectionGet and mpiFilterPostfilterGet Unable to Identify Postfilter Types - MPI2284
    Single Thread Access to Interrupts per MPIControl Object - MPI2363
    sqNodeFlash Returns Timeout Error on eZMP server - MPI2512
    SimServer Still Under Development

         

New Features

Version 04.03.10

   SynqNet Support for Yaskawa SGDV series drives
    Reference Number: MPI 2667
    Type: New Feature
    MPI Version: 04.03.10
   

Description:
SynqNet is now supported on Yaskawa SGDV series drives.

   

How do I use this feature?:
Yaskawa drives (SGDV, SGDV-MD4 and MD8) are all available with SynqNet.

Version 04.03.00 – 04.03.09

<none>

General Changes

Version 04.03.02 – 04.03.09

<none>

Version 04.03.01

  Flash.c replaced by flashSample.c
    Reference Number: MPI 2618
    Type: General Change
    MPI Version: 04.03.01
   

Description:
A new example program, flashSample.c, is available to demonstrate how to write the firmware into the controller's flash memory. flashSample.c should be used instead of flash.c. The flashSample.c utility is located in ../MPI/examples.

   

Affects to Application Code:
Flash.c will no longer be included in the MPI. Use flashSample.c instead of flash.c to flash the firmware.

Version 04.03.00

<none>

Fixed Bugs

Version 04.03.11

   mpiCompareLoadStartStopPoints had a memory leak
    Reference Number: MPI 2676
    Type: Fixed Bug
    MPI Version: 04.03.11
   

Problem:
mpiCompareLoadStartStopPoints function had a memory leak.

Cause:

This function did not release resources it acquired.

   

Fix/Solution:
The funcition's resources were deallocated and no longer has a memory leak.

Version 04.03.10

   The sqNodeFlash will report an error
    Reference Number: MPI 2670
    Type: Fixed Bug
    MPI Version: 04.03.10
   

Problem:
The sqNodeFlash reports an error if the FPGA or firmware is downloaded.

Cause:

A prior bugfix (MPI2658) was incorreclty implemented and its side effect was that the SynqNet network was not in SYNQ state causing this error.

   

Fix/Solution:
Tthe code was changed to sidestep the side effect of MPI2658 when SynqNet is not in SYNQ state.


   dumpEvents cannot correctly get all events
    Reference Number: MPI 2668
    Type: Fixed Bug
    MPI Version: 04.03.10
   

Problem:
Dumpevents occasionally does not print out all event data.

Cause

DumpEvents was not properly reading the circular event buffer when new events overflow and are queued at the beginning of the buffer.

   

Fix/Solution:
DumpEvents circular buffer handling was fixed and now prints out all data at all times.

Version 04.03.09

   Position and Velocity data of PIV_GT are not outputting to the User Buffer
    Reference Number: MPI 2666
    Type: Fixed Bug
    MPI Version: 04.03.09
   

Problem:
There were no output measurement data in the User Buffer. Therefore, the Bode tool was not receiving any data.

Cause:

1. There is no download method in the mechaware loader.
2. The firmware was using them as a floats and should be doubles.


   

Fix/Solution:
A download method was added to MwLoader.c and ModeUtils.c


   Incorrect Kvff calculation of PIV_GT
    Reference Number: MPI 2665
    Type: Fixed Bug
    MPI Version: 04.03.09
   

Problem:
For the PIV_GT block, when all gains are set to 0 and 1 is entered for Kvff, it commands a move of 1 rev/s and the motor runs away.

Cause:

Calculation of Kvff term was incorrect.

There was the following equation in the FF term:

Output += cv * Kvff;

It is not required since PIV has already calculated Vel FF.


   

Fix/Solution:
The equation was changed to the correct equation.


  When the motor gear is saved, the encoder position may have error
    Reference Number: MPI 2658
    Type: Fixed Bug
    MPI Version: 04.03.09
   

Problem:
When the motor gear is saved and an ABS motor is minus some distance, the initial position of an encoder may have an error.

Cause:

The cause of the problem is the firmware ratio module. The module cannot handle a large delta.


   

Fix/Solution:
The MPI was corrected and will recalculate the initial value.


   mpiCaptureConfigSet returns error: Capture is already armed
    Reference Number: MPI 2654
    Type: Fixed Bug
    MPI Version: 04.03.09
   

Problem:
When saving the topology in flash and CaptureConfigSet function is called afterwards, the function returns an error.

Cause:

The topology preservation function saves the Arming status of Capture. Therefore, Capture always enters the state of Arming, and the setting of Capture is obstructed.

   

Fix/Solution:
The MPI clears CaptureStatus before flash.

Version 04.03.08

   Incorrect alarm code check after SGDZBS pole detection
    Reference Number: MPI 2659
    Type: Fixed Bug
    MPI Version: 04.03.08
   

Problem:
MPI checks the wrong error code after pole detection of SGDZBS.

Cause:


   

Fix/Solution:
Correct error code is now checked.


   mpiControlEventNotifyGet calls mpiPlatformObjectLockTake twice
    Reference Number: MPI 2656
    Type: Fixed Bug
    MPI Version: 04.03.08
   

Problem:
mpiControlEventNotifyGet had a problem in object lock operation.

Cause:
The method call to Control object LockTake twice, however it will release Lock only once.
This generates the mismatch of the lock.

   

Fix/Solution:


Version 04.03.07

   Axis drift for Idle axes when Disable action is set to cmd=actual
    Reference Number: MPI 2650
    Type: Fixed Bug
    MPI Version: 04.03.07
   

Problem:
When axes are idle the position will drift when the disable action is set to cmd=actual. This occurs with various rmbs.

Cause:
The problem is caused by the fact that amp active was improperly supported by various rmbs (gms, soonhan, and Yaskawa). Also it is possible to set the amp disable action to cmd=actual for stepper axes.

   

Fix/Solution:
The MPI was modified so that these rmb's are not identified as supporting amp active. Also it is not possible to set the amp disable action to cmd=actual for stepper motors.

There is no drift when axes are idle for these rmb's when the amp disable action is set to cmd=actual. In addition no drift will occur for stepper axes because the amp disable action cannot be set to cmd=actual for stepper axes.



   Tolerance configuration is zero after reset when topology is saved
    Reference Number: MPI 2645
    Type: Fixed Bug
    MPI Version: 04.03.07
   

Problem:
Tolerance configuration is lost after reset when topology saved. Therefore, the tolerance status is unstable because firmware compares the position tolerance with zero.

Cause:
The firmware compares the tolerance with actual position and axisData.Tolerance. Beccuase MPI did not backup the axisData values, axisData.Tolerance will be zero after the reset when the topology is saved.


   

Fix/Solution:
The firmware will copy the tolerance data from axisConfig to axisData when restarted. When Topology is preserved, this operation is effective.



   meiAxisWait Returns Immediately if samplCounterSet is 0
    Reference Number: MPI 2644
    Type: Fixed Bug
    MPI Version: 04.03.07
   

Problem:
The mpiAxisOriginSet is called when sample counter = 0. Read command or actual position immediately. The origin value is not accurately reflected.

Cause:
Wait is determined by whether the samplecounter value in the axis structure is 0 or not 0.

   

Fix/Solution:
If the function needs to wait, set sample counter value and wait flag.



Version 04.03.06


   UserVersion and UserLabel do not save to Flash
    Reference Number: MPI 2638
    Type: Fixed Bug
    MPI Version: 04.03.06
   

Problem:
In prior versions of MPI 04.xx UserVersion and UserLabel do not save to flash.

Cause:
This feature was not ported over from MPI 03.xx.

   

Fix/Solution:
The functionality was ported from MPI 03.xx to MPI 04.03.06.

   

Affects to Application Code:
This feature is now supported in MPI 04.03.06. UserVersion and UserLabel will save to flash as intended.



   UserBuffer and VolatileBuffer do not save to Flash
    Reference Number: MPI 2637
    Type: Fixed Bug
    MPI Version: 04.03.06
   

Problem:
In prior versions of MPI 04.xx UserBuffer and VolatileBuffer do not save to flash.

Cause:
This feature was not ported over from MPI 03.xx.

   

Fix/Solution:
The functionality was ported from MPI 03.xx to MPI 04.03.06.

   

Affects to Application Code:
This feature is now supported in MPI 04.03.06. UserBuffer and VolatileBuffer will save to flash as intended.



   sqTopologySave(…) fails to properly save to flash on large motor counts (greater than 8)
    Reference Number: MPI 2632
    Type: Fixed Bug
    MPI Version: 04.03.06
   

Problem:
For large systems with lots of configuration data, the MPI improperly calculates the total amount of flash required to save the configuration. Additionally, the ZMP controller did not have enough flash to contain all of this data, but this error was not reported correctly.

Cause:
This error is caused by exceeding the flash memory capacity. On systems with lots of motors, the dynamic memory size is larger than the flash memory on the ZMP, causing sqTopologySave to fail.


   

Fix/Solution:
After correcting the memory calculation, we reviewed and optimized the objects being saved; removing some unnecessary data structures from the objects. This gives save to flash a much larger memory buffer, preventing errors on larger systems.

   

Affects to Application Code:
sqTopologySave()has been tested on systems having 64 motors with no capacity problems.

Version 04.03.05

   AKD NO brake I/O on Motion console
    Reference Number: MPI 2646
    Type: Fixed Bug
    MPI Version: 04.03.05
   

Problem:
There is NO brake mode in the I/O Window on the Motion Console. The function of Home1.c returns 0x631.

Cause:
The Axis and Motion objects were created before mpiControlConfigSet().

   

Fix/Solution:
The code was changed so that Axis and Motion objects are created after mpiControlConfigSet().


   

Affects to Application Code:
The same problem was also fixed in dmc_capture1.c, dmc_capture2.c, schall1.c seq1.c and watchdog3.c.



   The RecorderBuffer resource collides with CompareValueBuffer
    Reference Number: MPI 2634
    Type: Fixed Bug
    MPI Version: 04.03.05
   

Problem:
Compare and Recorder will overwrite each other causing the features to crash.

Cause:
This was caused by a resource misalignment. The MPI assigns the same memory address to CompareValueBuffer and RecorderBuffer.

   

Fix/Solution:
The memory address assigned to RecorderBuffer was changed so that it no longer conflicts with CompareValueBuffer.

   

Affects to Application Code:
Compare and Recorder should no longer have conflicts when used at the same time.



   AKD-SQ Reduce Position Jump on Amp Enable
    Reference Number: MPI 2628
    Type: Fixed Bug
    MPI Version: 04.03.05
   

Problem:
When the amplifier was enabled there was a jump in position.

Cause:
A delay occured between the amp enable signal and the amp actually becoming active. The delay can be up to 25 milliseconds. During this time the command position is no longer set to the actual position so position errors can build up while the servo is unable to correct for this position error.

   

Fix/Solution:
A change was made to the firmware and the MPI so that the command position will remain set equal to the actual position until the amp active signal is true. This will prevent position error build-up while the amp is inactive and unable to servo properly.

   

Affects to Application Code:
When the amp is enabled, the command position will continue to be set equal to the actual position until the amp active bit is true. Once the amp active is true, the servo will be able to run properly and reduce the position error before a large error can build up, and cause jump in position.


Version 04.03.04

   S200 invalid multi-turn feedback (AUXFB Endat or Mitutoyo)
    Reference Number: MPI 2630
    Type: Fixed Bug
    MPI Version: 04.03.04
   

Problem:
The S200 initial absolute position was incorrect for certain feedback values if the primary feedback was selected via the AUXFB (J14) connector. This includes Endat2.1 sin/cos feedback and Mitutoyo feedback. This particular issue did NOT apply to any base unit feedback (J3) such as SFD.

Cause:
At SynqNet discovery, the initial 64-bit feedback requires sign extension from the multi-turn count MSB. For primary feedback on AUXFB, the MPI accidently used the wrong bit (bit 23) to trigger sign extension. So for some feedback values, there was no sign extension and initial position was correct. For other feedback values, sign extension corrupted the multi-turn count.

   

Fix/Solution:
The MPI code was modified to correct this sign extension.

   

Affects to Application Code:
The MPI now allows for 12 bits of multi-turn count for primary feedback on AUXFB (36 bits of total absolute resolution).



   MPI reports copy64 error when running MoCon/motion4 sample program at high sample rates
    Reference Number: MPI 2629
    Type: Fixed Bug
    MPI Version: 04.03.04
   

Problem:
When running an application like MoCon or motion4 sample program (esp using AKD at high sample rates), occasaionally, this error surfaces. If a customer application sees this, it will likely stop their application. However, it is hard to reproduce.

Cause:
Double comparison checked for 3 consecutive memory reads, which essentially needed to be the same. At high sample rates, and with doubles which change values (because of high-resolution encoders), this is error is likely to happen. It is also more likely in a loaded system.


   

Fix/Solution:
On modern PCI systems, one read suffices because PCI reads use burst-reads which can read both 32-bit words atomically. Thus, one double read was sufficient, no comparison between successive reads necessary. For older systems which did not support burst 2-word reads, double comparison used 2 consecutive matches which have a much higher probablity of succeeding.

   

Affects to Application Code:
No copy64 error will result in modern PCI systems, and for older systems, the error will only arise in failure cases (e.g. when the sample rate is too high to be supported by the system).

Version 04.03.03

   S200 absolute multi-turn feedback invalid after mpiMotorConfigSet()
    Reference Number: MPI 2621
    Type: Fixed Bug
    MPI Version: 04.03.03
   

Problem/Cause:
With MPI 04.xx.xx, primary feedback selected from the S200 option card connector (Aux connector J14) has an invalid absolute position after the mpiMotorConfigSet() function is called. The absolute feedback will be CORRECT after node initialization (controller reset, or network reset).

The issue has existed since MPI 04.00.00 and still exists as of MPI 04.03.01.

This was an issue with MPI mapping pointers inside the SynqNet controller (not in the S200 drive hardware).

   

Fix/Solution:
A workaround using application code will be investigated. An MPI update is expected for the final solution.

   

Affects to Application Code:
With either the workaround solution, or the MPI fix, absolute feedback remains valid after mpiMotorConfigSet().


   64-bit driver performance degrades over time.
    Reference Number: MPI 2626
    Type: Fixed Bug
    MPI Version: 04.03.03
   

Problem/Cause:
After running MoCon overnight in a system with several nodes, the host computer seemed very sluggish. This behaviour was not seen in 32-bit systems.

The device driver has a list of treads waiting for interrupts. This list contains a unique 64-bit identifier for each thread that is assigned by the driver. The identifier is passed back to the thread and expected to be used but that thread for all interrupt calls (wait, pend, wake). Due to a mistake in the function mpiPlatformOSInterruptWaitPend(), the identifier was truncated to 32 bits by the MPI which caused the driver to allocate a new identifier for each mpiPlatformOSInterruptWaitPend() call. Since each new identifier was added to the list of known identifiers, the list would grow each time the function was called. After an overnight run the list would be large enough (>1,000,000 entries) that searching it in the driver was impacting performance.

   

Fix/Solution:
The truncation of the identifier was removed from the MPI. The search would now correctly find an identifier previously issued so each thread would only have one identifier.

   

Affects to Application Code:
The performance no longer degrades with time.

Version 04.03.02

   mpiUserLimitConfigSet() returns timeout in multi-threaded application
    Reference Number: MPI 2619
    Type: Fixed Bug
    MPI Version: 04.03.02
   

Problem/Cause:
mpiUserLimitConfigSet() times out when called repeatedly from different threads.

Two threads writing into the firmware's limit enable queue would cause occasional missing entries in the queue. In that case, the thread waiting for the enable would time out.

   

Fix/Solution:
A lock was used to control access to the firmware's limit enable queue by different threads.

   

Affects to Application Code:
The enabling of the limits is assured for all threads.


   Coordinated motion does not set hold values proberly
    Reference Number: MPI 2622
    Type: Fixed Bug
    MPI Version: 04.03.02
   

Problem/Cause:
If you do a coordinated motion with hold values set, the hold condition value and timeout value will be word-swapped in axis 1, but OK in axis 0 (assuming a 2-axis motion).

   

Fix/Solution:
Word-swapping was fixed.

   

Affects to Application Code:
Coordinated motion with holds work correctly for release holds correctly on all axes.

Version 04.03.01

<none>

Version 04.03.00

  mpiUserLimitConfig() hangs
    Reference Number: MPI 2616
    Type: Fixed Bug
    MPI Version: 04.03.00
   

Problem/Cause:

Repeated calls to mpiUserLimitConfig() were causing the MPI to go into an infinite loop.

A race condition caused a limit disable call to fail. As a result, a loop in userlimit.c, which waits for the limit to disable, continued looping without an exit.

   

Fix/Solution:
The wait loop was revised to timeout and exit if the limit did not disable.

The race condition causing the disable failure was also removed.

   

Affects to Application Code:
Repeated mpiUserLimitConfig() calls will execute properly.


  ControlConfigSet() overwrites Axis 2 gear config
    Reference Number: MPI 2615
    Type: Fixed Bug
    MPI Version: 04.03.00
   

Problem/Cause:

The Axis 2 gear ratio parameters are corrupted after calling mpiControlConfigSet() to increase the number of allocated Motion Supervisors.

The recent changes in how user limits are enabled (list rather than count) caused limits to be active durning the allocation process. Since the data for the limits was no longer valid, some limits would trigger and their outputs would overwrite the Axis 2 (or other) Gear Config variables.

   

Fix/Solution:
Any limit with a limit number greater than MfwBufferData,SystemConfig.Enabled.UserLimits
is not processed. The MPI sets MfwBufferData,SystemConfig.Enabled.UserLimit to 0 during allocation.

   

Affects to Application Code:
The user limits are disabled during initialization/reallocation so no data is corrupted by their outputs.


  Dependent Objects Memory Leak
    Reference Number: D-04233
    Type: Fixed Bug
    MPI Version: 04.03.00
   

Problem/Cause:

If ControlConfigSet is called after MPI objects are allocated and if those MPI objects are used, it:
- leaks memory for every MPI call using that object
- it prints on the console

   

Fix/Solution:
MPI objects allocated prior to an mpiControlConfigSet call, in which dynamic reallocation is performed, will be considered "obsoleted". The user will have to delete these objects and reallocate them.

   

Affects to Application Code:
If it is desired to capture the configuration of these objects, the user will have to retrieve the configuration using, say, mpiAxisConfigGet on an MPIAxis object, PRIOR to calling mpiControlConfigSet. The stored configuration can be applied on the newly obtained MPIAxis object AFTER calling mpiControlConfigSet.

If an "obsoleted" object as described above is used in an MPI method, the error returned is:
ERROR 0x631: Control: Object cannot be used after reallocation

Open Issues

Existing Bugs

Limitations

  Multiple Drive Map Files
    Reference Number: N/A
    Type: Limitation
    MPI Version: 04.02.xx
   

Problem:

Multiple *.dm files in the node directory may cause unexpected results when using meiConfig. It is recommended that you only have one file in this directory with the .dm extension per drive type. When multiple drive map files are present, it is possible that meiConfig will use the wrong one or an out of date .dm file.

Cause:

MeiConfig expects a clean directory and doesn’t know about copies and test DM files. MeiConfig reads every  file with a .dm extension, and uses the first instance where the CONTENTS of the drive map file match the drive type.


  mpiFilterPostfilterSectionGet and mpiFilterPostfilterGet Unable to Identify Postfilter Types
    Reference Number: MPI 2284
    Type: Limitation
    MPI Version: 04.02.xx
   

Problem:

When postfilters are set to the controller by using mpiFilterPostfilterSectionSet(...) or mpiFilterPostfilterSet(...) and a variable representing a frequency is close to zero or the Nyquist frequency, mpiFilterPostfilterSectionGet, mpiFilterPostfilterGet are unable to identify the postfilter type.

Cause:

This limitation occurs because the postfilter type is not stored on the controller. Instead the MPI attempts to identify the postfilter type. However, when a specified frequency is close to zero or the nyquist frequency, the precision needed to correctly identify the postfilter type exceeds the precision of the variables on the controller resulting in the inability to correctly identify the postfilter type.

Indentification problems occur when a specified frequency is within 0.5% of the Nyquist frequency of zero. For a sample rate of 2 kHz, the Nyquist frequency is 1 kHz resulting in identification problems occurring when specified frequencies are in the range of 0-5 Hz or 995-1000 Hz.


  Single Thread Access to Interrupts per MPIControl Object
    Reference Number: MPI 2363
    Type: Limitation
    MPI Version: 04.02.xx
   

Description:

Two built-in MPI features use interrupts: the event service routine and the SyncInterrupt feature. However, only one thread may access interrupts when accessing a controller over a client-server connection.

The controller event service routine started by mpiControlEventServiceStart(...) uses interrupts when MPIWaitFOREVER is specified for the sleep parameter. Other values for the sleep parameter allows the event service thread to run in polling mode. In order to use the SyncInterrupt feature, the event collection thread must use polling or the SyncInterrupt routine must call mpiControlProcessEvents(...).


  sqNodeFlash Returns Timeout Error on eZMP server
    Reference Number: MPI 2512
    Type: Limitation
    MPI Version: 04.02.xx
   

Description:

While running server.exe on the eZMP with S200, a timeout error occurs when sqNodeFlash.exe is run on the client PC.


  SimServer Still Under Development
    Reference Number: N/A
    Type: Limitation
    MPI Version: 04.02.xx
   

Description:

At the time of the release, the development of SimServer had not been completed. This feature is released as a standalone package and is not included in the MPI distributables. SimServer is planned to be completed and supported in the next MPI release (04.02.01).

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