Description:
The Brake option was added for the GPIO Output. This feature should be used to when there is no dedicated brake pin.

How do I use this feature?
Code has been added to kollmorgen_s200.c. If the user selects Brake as the source for the S200 GPIO Output, the dedicatedBrake output controlled by firmware will be mapped to this output.

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:
New parameters have been added to the firmware in order to smoothly (3rd order profile) transition the feedrate from one value to the next. The new parameters are accessed via memory set commands. Changes were made to the controller firmware and will not affect customer code.

There are three seperate feedrate goal values:

target - This feedrate goal value is used during normal operation and the feedrate change characteristics are controlled by the "resume" velocity and acceleration.
Valid values are 0-1 (float)

pause - This feedrate goal value is used during stop evants, and the feedrate change characteristics are controlled by the "pause" velocity and acceleration.
Valid values are 0-1 (float)

estop feedrate goal - This feedrate goal is used during estop events, and the feedrate change characteristics are controlled by the "eStop" velocity and acceleration.
Valid values are 0 (This value is hard-coded in the firmware).

If the velocity and acceleration values associated with the feedrate goals above are set to the same value, then feedrate change is linear. If the acceleration value is set to a value lower than the velocity, then smoothing of the feedrate will take place.

Order of registers in VM3 is:

ms[x].feedrate.current Default Value = 1
ms[x].feedrate.currentVel Default Value = 0
ms[x].feedrate.target Default Value = 1
ms[x].feedrate.pause Default Value = 0 
ms[x].feedrate.resumeRamp.vel Default Value = 1e-3
ms[x].feedrate.resumeRamp.accel Default Value = 1e-3
ms[x].feedrate.pauseRamp.vel Default Value = 1e-3
ms[x].feedrate.pauseRamp.accel Default Value = 1e-3
ms[x].feedrate.estopRamp.vel Default Value = 1e-2
ms[x].feedrate.estopRamp.accel Default value = 1e-2

current - the current feedrate value used by the motion supervisor.
currentVel - the current velocity of the feedrate ramp to the new goal value.

Description:
In previous versions, uploading runtime images to nodes with working boot images returned a misleading topology mismatch message. Changes were made to the internal MPI/MEI libraries and will not affect customer code. Uploading runtime images to nodes with working boot images will no longer return a topology mismatch message.

Description:
The I/O for the SGDZ-MD 2-axis motor has been improved. The new extended I/O is the default configuration for all SGDZ-MD 2-axis drives. The SGDZ-MD now supports the following I/O bits. Notice that the Rx and Tx are swapped for Axis 1.

NOTE: Opto In 0 was previously labeled Opto In. Opto Out 0 was previously labeled Opto Out. Tx was previously labeled Tx/Rx.

A new FPGA has been released to support the expansion of I/O for the SGDZ-MD, C0FE003F_xxx.sff.

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:
A limit that had a non-zero duration may have triggered the limit if the condition was met at the time the limit was configured. The state may have been calculated during configuration and if the state was 0x10 (triggered), it would override the newly calculated state during the first sample after configuration.

Fix/Solution:
The firmware code was modified to remove the possibility of false triggers.

Problem/Cause:
The s-curve jerk firmware (x21p and x22p firmware) did not properly execute a reduced velocity motion modify. In some cases the mpi would generate an error while in other cases, the reduced velocity command would be ignored by the firmware. This problem occurred because the firmware code was not handling the reduced velocity motion modify command.

Fix/Solution:
The firmware was modified to properly handle the reduced velocity motion modify. Reduced velocity motion modify commands will no longer generate mpi errors, or be ignored. The proper reduced velocity is acheived after a reduced velocity motion modify command is issued.

Problem/Cause:
If you are using a Yaskawa SGDS drive and run mtReset while Motion Console is open, mtReset will hang. When mtReset is run, it brings the network down and brings it back up. However, during network initialization, the SGDS was calling mpiMotorConfigSet(...), which takes a motor semaphore.

Fix/Solution:
It is not necessary for the SGDS drive to call mpiMotorConfigSet(...) during initialization. The problem was fixed by removing mpiMotorConfigSet(...).

Problem/Cause:
The mpiMotionStart and mpiMotionModify may have incorrectly returned MEIMotionMessageBAD_PATH_DATA with multi-dimensional PT, PTF, PVT, PVTF, Spline, BSpline, BSpline2, and Bessel moves.

Fix/Solution:
Checks for finite values in motion code have been modified to only check valid elements for the time-delta array.

Problem/Cause:
The ampEnable bit on the Kollmorgen Stepper Drives (Kollmorgen CD) was not turning on when the Amp Enable bit was set in the software because the AMP enable polarity was incorrectly inverted.

Fix/Solution:
This problem was fixed by changing the FPGA configuration so that the the ampEnable bit turns on when the Amp Enable bit is set in the software. The AMP enable should now function properly.

Problem/Cause:
Calls to mpiMotionStart(...) with a HOLD attribute would intermittently cause an Out of Frames status. This was caused by the control word from a motion frame being OR'd into the axis status. A small timing window could allow the motion status to interpret the axis status with an Out of Frames.

Fix/Solution:
The problem was corrected by eliminating the control word ORing with the axis status.

Problem/Cause:
In firmware version 580A7, if the topology was saved and the controller was reset, SynqNet Fault Recovery would fail. When SynqNet tried to recover from a fault, it would get stuck in the SYNQ_RECOVERING state. The problem was caused by the Tx Enable INPORT bit not being set in Rincon's DMA Tx Control word.

Fix/Solution:
The problem was corrected in firmware version 580B1 by setting the Tx Enable INPORT bit in Rincon's DMA Tx Control word when initializing the network after a topology save.

Problem/Cause:
If the HOLD trigger was released before the designated timeout for the HOLD frame, a position jump could have occurred. For HOLD frames that contained a timeout, the frameType had the TimeAdvance and FrameAdvance bits set. This meant that the internal frame time value increased by the feedrate value every sample. If the internal frame time value exceeded or equaled the frame's time value, the frame's time value was subtracted from the internal frame time value (should make it 0) and the next frame would start processing.

Fix/Solution:
This problem was fixed by setting the internal frame time value to zero before processing the next frame in the list (if the HOLD frame was released by the HOLD trigger conditions being met).

Problem/Cause:
As a result of the incorrect functions, compiler warnings were generated on some platforms when passing types of "char*[]" to the apputil argument parsing module.

Fix/Solution:
The functions have been corrected.

Problem/Cause:
The GPIO brake output was not working properly. The Brake Output was defined as SOURCE5, instead of SOURCE6.

Fix/Solution:
The Brake Output define has been changed from SOURCE5 to SOURCE6. The Brake Output is now properly defined.

Problem/Cause:
An mpiControlInit error occurred when trying to initialize three or more nodes on a SynqNet network when using the controller's IN port. If nothing was connected to the controller's OUT port, the node enumeration was backwards on the IN port. The problem was caused by code in the firmware and MPI that enumerated discovered nodes on the IN port starting with 0 and increasing the index if no nodes were discovered on the OUT port.

Fix/Solution:
Modifications have been made to the code so that it always enumerates the discovered nodes on the IN port in decreasing order.

Problem/Cause:
Using save topology with ZMP-SynqNet series controllers caused the frame buffer for axes 8 to 31 to be corrupted. This would cause the upper axes to have incorrect status bits.

Fix/Solution:
The problem was corrected in the controller's firmware by clearing all the axes' frame buffers during a save topology.

Problem/Cause:
A sequencer could not perform motion modification with the MPIMotionAttrMaskAUTO_START mask. The sequencer could modify a currently executing motion, but could not start a new motion if motion was not currently being performed.

Fix/Solution:
A sequencer can now perform a motion modification with the MPIMotionAttrMaskAUTO_START mask. This will allow the sequencer to start motion even if motion is not currently being performed.

Problem/Cause:
Postfilter methods did not work over a client-server connection.

Fix/Solution:
In previous versions, using postfilter methods over a client-server connection would result in a memory access violation. This problem has been corrected and the postfilter methods now work over client-server connections.

The postfilter methods are:

meiFilterPostfilterGet
meiFilterPostfilterSet
meiFilterPostfilterSectionGet
meiFilterPostfilterSectionSet

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

Fix/Solution:
This problem has been fixed.

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

Fix/Solution:
This problem has been fixed.

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