Release Note
MPI Library Version 03.02.10

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.

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.

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.

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

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.

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 2³¹, then the points list is adjusted by 2³² 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 (2³¹) 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 (2³¹ - 10)
First Position in Point List = 2147483658 ((2³¹ + 10)
or First Position in Point List = -2147483638 ((2³¹ + 10) - 2³²)

From the controller's point of view, both first positions are the same value, but from the MPI's point of view, they are 2³² 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.

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.

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.

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.

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.

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.

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.

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.

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.

See Also:
MPIControlStatus | MPIControlFanStatusFlag | MPIControlFanStatusMask

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

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.

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.

Description:
Applications may need to synchronize with the controller every N^th 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

Description:
The SynqNet packet schedule algorithm was improved for RMB-only systems with sample rates = 16kHz or higher. 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.

How do I use this feature?
This feature is beneficial for RMB-only systems, running at 16 kHz or higher. The changes were made to the internal MPI/MEI libraries. No application changes are required.

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

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.

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

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.

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

See Also:
meiControlIoBitGet | MEIControlIoBit

Problem/Cause:
When crossing the rollover position using a multi-point motion (PT, PVT, SPLINE, etc.) the command position could have been calculated improperly if the origin was non-zero. The MPI was using an incorrect entry in an array when calculating the initial delta between the current command position and the first point in the path move. The MPI was unable to adjust the origin value and subsequently miscalculated the move parameters for the first frame.

Fix/Solution:
This problem has been corrected. The MPI now calculates the acceleration parameter for the first frame correctly.

Problem/Cause:
Occasionally, a VELOCITY move followed by a mpiMotionModify(...) with an S_CURVE move would cause a command position discontinuity. This problem was caused by an incorrect time value that was used to calculate the position, velocity, and acceleration.

Fix/Solution:
The firmware has been modified so that the correct time value is used for a velocity frame.

Problem/Cause:
During SynqNet initialization, the MPI's timer functions were not working properly for the ZMP-Series controllers. The problem may have caused occassional "timeout" errors during SynqNet initialization, as well as failure of node firmware download.

Fix/Solution:
The DMA_Continuous_Timer value is now set to the equivalent value of the SystemData.SamplePeriod at the start of SynqNet initialization, so the MPI's timer functions work properly.

Problem/Cause:
Under specific conditions, loading node FPGAs on a ZMP-SynqNet series controller would fail using Motion Console and sqNodeFlash.exe. This problem occurred when updating a Yasawaka SGDS drive from FPGA version x103 to x346.

Fix/Solution:
This problem has been corrected.

Problem/Cause:
mpiRecorderStart/Stop(...) 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 would write the enable and count words, and then they would be overwritten by the controller. This caused intermittent failure of a data recorder start/stop from the host.

Fix/Solution:
The start was corrected by closing the race condition for recorder start in firmware version 561C3. The stop will be corrected in a future release, firmware version 571A1 and later (MPI 03.03.xx).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.