Release Note
MPI Library Version 03.03.00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How do I use this feature?
meiPlatformExmpTempGet | meiPlatformExmpTempInit

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

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

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

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

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

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

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

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

New Methods
meiSqNodeSegmentParamGet
meiSqNodeSegmentParamSet
meiSqNodeSegmentParamDefault
meiSqNodeSegmentParamStore
meiSqNodeSegmentParamClear
meiSqNodeSegmentMemoryGet
meiSqNodeSegmentMemorySet

New Data Types
MEISqNodeSEGMENT_MAX
MEISqNodeSEGMENT_PARAMS_MAX
MEISqNodeSEGMENT_MEMORY_MAX
MEIEventTypeSQNODE_IO_FAULT

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

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

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

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

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

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

How do I use this feature?
mpiMotorDedicatedIn | MPIMotorDedicatedIn

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Use mpiMotorConfigGet/ Set(...) to set the brake mode to none:
   
      mpiMotorConfigGet(motor, &config, NULL);
      config.brake.mode = MPIMotorBrakeModeNONE;
      mpiMotorConfigSet(motor, &config, NULL);
   
2. Set or clear the brake bit with mpiMotorIoSet(...):
      /* set the brake */
      mpiMotorIoGet(motor, &io);
      io.output |= MEIMotorDedicatedOutBRAKE_RELEASE;
      mpiMotorIoSet(motor, &io);
   
   If the brake mode is NONE, then the user can set or clear the brake bit at any time.
   
   If the brake mode is not NONE, then the user can set or clear the brake bit only when the motor is disabled, because the firmware ORs the user's command with its own command to create the brake bit sent to the FPGA/Drive. Since the firmware clears the brake bit (setting the brake) when the motor is disabled, the user can either set or clear the same bit and have it propagate through to the FPGA/Drive. If the firmware sets the bit (releasing the brake), then the user has no control over the state of the bit.
   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fix/Solution:
This problem was fixed.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fix/Solution:
This problem has been corrected.

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

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

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

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

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

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

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

Fix/Solution:
This problem has been corrected.

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

Fix/Solution:
This problem has been corrected.

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

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

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

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

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

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

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

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

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:
The MEISqNodeConfig.upStreamError configuration is not stored in the controller's flash memory by meiSqNodeFlashConfigSet(...). If you change the upStreamError value, try to save it to flash and reset the controller. The upStreamError will revert back to the default value.