Description:
The Kollmorgen SqDC drive will generate a Axis Current Limit Fault when the axis current exceeds the programmed current limit value.

How do I use this feature?
Support has been added to the MPI for the Axis Current Fault.

Description:
The mpiMotorPositionFeedbackOffsetSet(...) and mpiMotorPositionFeedbackOffsetGet(...) methods were added to the MPI to allow user applications the ability to store and read back an absolute position offset value. This value will be stored in the EEPROM on the motor itself. This feature will be supported through the drive interface on selected drives only. These methods can directly access storage on the EEPROM, allowing a position offset to be stored from session to session. In conjunction with mpiAxisOriginSet(...), this feature replicates the ability of certain drives to reset the zero position on absolute encoders.

How do I use this feature?
This feature can only be used with a Kollmorgan S200 drive and an EnDat 2.1-capable motor. The S200 must have AuxFB set to "EnDat 2.1" in order for this feature to work correctly.

Description:
Previous MPI versions would not support local controller I/O for ZMP models T115-0001 and T127-0001. Support has now been added to the MPI for the T115-0001 and T127-0001.

How do I use this feature?
The MPI uses the model numbers to decode the local controller digital I/O bit availability. The local controller I/O can be identified via meiControlInfo(...) and accessed with mpiControlDigitalIn(...), mpiControlDigitalOutGet(...), or mpiControlDigitalOutSet(...).

Description:
Support has been added to the MPI for the following Yaskawa SGDZ-BS Series Drives: SGDZ-BS61, SGDZ-BS62, SGDZ-BS63.

How do I use this feature?
For more information, please contact Yaskwawa (www.yaskawa.com).

Description:
The Kollmorgen CD drive with DSP rev G has a new drive firmware download sequence. To support the DSP rev G, the drive firmware download method was modified and a new kollmorgen_ember.a00 file was updated. The support for the drive firmware download feature on the DSP rev G is not backwards compatible with older MPI versions.

How do I use this feature?
For more information, please see the Kollmorgen CD drive.

Description:
The Kollmorgen SqDC and SqStep drives now support warning codes/messages. Support has also been added for the SqDC2 model.

How do I use this feature?
For more information, please see the Kollmorgen SqDC and SqStep drives.

Description:
The Sanyo Denki R-Series is now supported. The Q-Series support has been expanded to include service channel, drive faults/warnings, drive parameters, etc. In previous MPI versions, the Q-Series support was minimal. If you have a Q-Series drive and upgrade the MPI, please contact Sanyo Denki (www.sanyodenki.com) for the latest drive firmware.

How do I use this feature?
For more information, please contact Sanyo Denki (www.sanyodenki.com).
See also, Sanyo Denki Q-Series and R-Series drives.

Description:
New functions were added to get the lower 32 bits of actual and command position data.

mpiAxisActualPositionGet32(...)
mpiAxisCommandPositionGet32(...)

If only the lower 32 bits of position data need to be read, it's faster to use these new functions instead of using the standard -Get position functions.

How do I use this feature?
For descriptions and sample code, see the links to the function pages above.

Description:
The following drive update rate options are now available on the Glentek Omega Drive. EEPROM option numbers 4-7 were added.

How do I use this feature?
See the Glentek Omega Drive. To determine the update rate or period for the drive, use MEISynqNetTiming.node[].updateFreq or MEISynqNetTiming.node[].updatePeriod.

Description:
Support was added to the MPI for the Kollmorgen SqDC drive.

How do I use this feature?
See Kollmorgen SqDC Drive for more details.

Description:
In a ring topology, SynqNet allows the remaining nodes to operate if one or more nodes fail. Previously, the only way to restore normal operation for all nodes was to reinitialize the entire network, which would disrupt any operating node. In cases of modular machines, it may be necessary to service one or more nodes while the other nodes are actively controling motion and I/O. The new SynqNet HotReplace feature allows one or more nodes to be shut down, serviced, and then brought back to normal operation without affecting the operation of other nodes.

How do I use this feature?
See SynqNet HotReplace for more details.

Description:
Support was added for the Pn600 "Regenerative Resistor Capacity" drive parameter for the SGDS-72/75 drives.

How do I use this feature?
To access the Pn600 drive parameter, use the methods meiSqNodeDriveParamGet(...) and meiSqNodeDriveParamSet(...), or meiSqNodeDriveParamListGet(...) and meiSqNodeDriveParamListSet(...). See the Yaskawa SGDS Drive.

Description:
New methods were added to read and write the axis origin to/from the controller's flash memory. This feature is useful for applications that use ABS encoders. However, you cannot save the ABS encoder offset to the drive's flash memory.

How do I use this feature?
To write the origin to the controller's flash memory, use mpiAxisFlashOriginSet(...).
To read the origin from the controller's flash memory, use mpiAxisFlashOriginGet(...).
NOTE: These methods do not access the origin value of the axis in the controller's dynamic memory.

Description:
The FPGA that is used with SQID nodes, C0FE0030_xxxx.sff, has been extended to detect errors communicating with any of the I/O modules (e.g. DIN32DOU32). The MPI has been extended to report these new error conditions.

How do I use this feature?
See the I/O Faults section. See MEISqNodeStatusIoFaults and MEISqNodeStatus.

Description:
Configurable Demand Modes have been added to the MPI. The new feature should be used when it is appropriate for a drive to change its demand mode. Currently, only the S300, S600, and S1800 drives support multiple demand modes. Check with the drive manufacturer for possible settings. Nodes that do not support a drive interface (ex: RMB-SynqNet) should use ANALOG or use ANALOG_DUAL_DAC for nodes with two DAC's per axis.

How do I use this feature?
See MEIMotorDemandMode and MEIMotorConfig. A drive will default to an appropriate demand mode. Use mpiMotorConfigGet/Set(...) to change the demand mode. See SynqNet Demand Modes.

Description:
The controller's command and actual position registers have been expanded to 64 bit. The MPI uses doubles for command and actual positions, which are limited to 1.7E+/-308 (at least 15 digits precision).

How do I use this feature?
See the "Position Resolution Extended" section of the Important Things to Know page.

Description:
Support was added to the MPI for the Kollmorgen S1800 drive.

How do I use this feature?
See Kollmorgen S1800 Drive for more details.

Description:
The maximum number of controllers supported using a particular OS is now available from a macro, MEIPlatformControlCountMax, in platform.h.

How do I use this feature?
This macro should only be used to determine the maximum number of controllers supported on a single system. See MEIPlatformControlCountMax.

Description:
Support was added to the MPI for the Yaskawa SGDS75A drive.

How do I use this feature?
See Yaskawa SGDS Drive for more details.

Description:
It is now possible to determine whether a non-idle axis and motion supervisor state was caused by an application on the host computer or by a controller action. It is useful to know whether a non-IDLE state was caused by a controller event or a user action. If the action source was the controller, the controller may be queried to find out what event caused the error state. In a multi-threaded or multi-process environment, it can also be useful to know if a another thread or process commanded an action that placed the motion supervisor or axis into a non-idle state.

How do I use this feature?
The action source can be obtained by calling mpiMotionStatus(...) or mpiAxisStatus(...) and then reading the MPIStatus.actionSource value. Use the enumeration, MPIActionSource, to decode the value.

Description:
The XmpBufferData.VolatileBuffer was added to the controller's external memory. This volatile memory buffer is initialized to zero after a controller reset or power-up cycle.

How do I use this feature?
The volatile memory buffer can be useful for setting application flags, which can denote that certain operations have taken place. For example, once an axis has been successfully homed, a flag can be set in the volatile buffer. However, after a controller reset, the flag will be reset to zero, indicating that the axis is no longer homed.

Description:
The following functions have been added to sqNode.h to assist the setup of recorders and user limits with I/O on SynqNet nodes.

sqNodeDigitalInPtr(...)
sqNodeDigitalOutPtr(...)
sqNodeAnalogInPtr(...)
sqNodeAnalogOutPtr(...)

How do I use this feature?
For descriptions and sample code, see the links to the function pages above.

Description:
The meiSqNodeDriveMonitorInfo(...) method was added to the MPI for retrieving drive monitor information. This method retrieves the number of supported drive monitors, the firmware locations of the monitors, a mask and shift value for retrieving the monitors, and a list of possible monitor configurations.

How do I use this feature?
This feature should be used when configuring drive monitors. The sqDriveMonitor utility contains an example of how to read and display the monitor information.

Description:
The compatibility of a client object to a server is now verified by meiClientValidate(...). Compatibility is based on MPI_INTERFACE_VERSION and the equality of members of the MEIRemoteMethod enumeration.

How do I use this feature?
The compatibility check feature is automatically invoked when the client object is validated.

Description:
Support was added to the MPI for the Kollmorgen S600 drive.

How do I use this feature?
See Kollmorgen S600 Drive for more details.

Description:
Support was added to the MPI for the Kollmorgen S300 drive.

How do I use this feature?
See Kollmorgen S300 Drive for more details.

Description:
A new function has been added to the MPI which can be used to determine the size of the controller's frame buffer and how many frames are currently in the frame buffer for a particular axis.

How do I use this feature?
See meiAxisFrameBufferStatus(...) for sample code and implementation details.

Description:
The controller firmware performance can be measured with meiControlStatistics(...). This method will read the maximum and average times for the foreground and background controller firmware tasks. The controller performance counters can be cleared with meiControlStatisticsReset(...). This feature is useful for determining the controller processor load. It can also help determine the maximum sample rate and number of available resources. For more details, see Sample Rate and SynqNet Controller Performance.

How do I use this feature?
meiControlStatistics(...) | meiControlStatisticsReset(...) | MEIControlStatistics
See the XmpStats1.c sample application.

Description:
In previous versions, the drive firmware for the Yaskawa SGDS and SGDZ drives did not allow the multi-turn reset command to be executed while the network was in SYNQ mode. It required the SynqNet network to be shutdown when performing an mtreset. The multi-turn reset function for the Yaskawa SGDS and SGDZ-MD drives has been modified to perform an mtreset without shutting down the whole SynqNet network. Now, when the multi-turn reset is requested, only the node associated with the drive is shutdown (ASYNQ mode) and restarted. Upon successful completion of the multi-turn reset, the node will be brought back to SYNQ mode.

Description:
The SFD device contains useful information about the motor that is connected to the drive. This information is now available as new S200 Drive read-only parameters.

Description:
For path motion (Splines, PVT, PT, etc.), the MPI creates the frames used by the motion and then writes them to the controller. Typically, each point in the path has a corresponding frame for each axis of motion. For path segments with a large number of points (large number of frames), there is an initial group of frames loaded when the motion is started. More frames are loaded as a result of interrupts (events) generated when the axes' frame buffers run low on frames.

In previous versions, the number of frames loaded was always half the capacity of the frame buffer and the "low frame" trigger was hard coded at 32 frames. Although this limit is usually sufficient for the default buffer size of 128 frames, larger buffers could benefit from increasing these limits. In addition, in cases where a backup on path was not needed, the number of initially loaded frames could be larger.

This change will be most useful for customers streaming path (PVT, etc.) points at a high rate. To take advantage of this feature the frame buffers for the axes involved in the streaming motion should have increased frame buffer sizes (larger than the default of 128 frames). Increase the axes' frame buffer sizes with mpiControlConfigSet(...) or the meiConfig utility. Be sure to retain the parameter for path motion as FALSE.

Description:
The AmpNotPowered fault was added into the default MEIMotorFaultConfig.faultMask logic due to changes in the S200 FPGA brake logic. The "Amp Not Powered" fault bit will now trigger the motor's AmpFault when the Brake is applied directly by the drive. See FPGA issue FP523 for details.

Description:
The motor configuration provides a "Brake" source for the general purpose I/O for MEI RMB node types. The Brake logic for the following node type was incorrect: MEI RMB-10V2-SSI with C0FE002C FPGA

For product consistency, the MEI RMB-10V2-SSI was changed to have the same polarity as the standard RMB-10v2 (C0FE002C FPGA).

WARNING: If you are upgrading from a previous MPI software release where you're using an RMB-10V2 with C0FE002C, and are using a Brake source for a general purpose motor I/O, the logic will be opposite in 03.04.00 and later releases.

Description:
In previous versions, the cable length discovery technique was inaccurate for networks with 6 or more nodes. The inaccuracies were caused by an incorrect measurement and calculation. The addition of more nodes to the network caused additional uncertainty in the time measurement, which caused inaccuracies in the cable length calculations. To reduce the inaccuracies, the cable length time measurements now occur between the controller and node or between two nodes. Thus, adding nodes to a network will no longer cause additional inaccuracies to the cable length calculations.

Description:
A potential problem existed with the Control word in frames being or'd into the axis status. Some frames are not meant to have Control words and are supposed to execute in one sample. However, there are strange cases where the user can get the axis to stop on a frame with no Control word and have that frame be active during the background cycle. When this happens, the axis status code OR's in the data in the place where a Control word would be. So, depending on the data at that location, anything could happen. As a precautionary measure, the Control word in the frame to be OR'd with Axis.Status was eliminated.

Description:
A check has been put into place to ensure that Pulse engines are present before configuring a Motor type to Stepper.

Description:
To be consistent with the rest of the MPI the data types for specifying positions for cam moves have been changed from a long to a double.

See MPIMotionCam and MPIMotionAttributes.

Description:
The S200's default secondary feedback was changed from MEIMotorEncoderTypeQUAD_AB to MEIMotorEncoderTypeDRIVE. The default for the S200's Aux Feedback is now Drive Feedback instead of Quadrature.

Description:
The MEIEventStatusInfo structure was expanded to handle 64 bit data. New default data structures were added and defined to overlay the 10 word data buffer that is returned by an event. By default, the new addressing was designed to match the new overlays.

NOTE: If the defaults are changed, the MPI overlays will not be accurate and cannot be used to extract data from the buffer.

See MEIEventStatusInfo.

NEW:
typedef typedef struct MEIEventStatusInfo {
    union {
        MPIHandle  handle;  /* generic */
        MPIAxis    axis;    /* MEIEventTypeAXIS_FIRST ... 
                               MEIEventTypeAXIS_LAST - 1 */
        long       node;    /* MEIEventTypeCAN_FIRST... 
                               MEIEventTypeCAN_LAST - 1  */
        long       number;  /* MPIEventTypeMOTION 
                                    MPIEventTypeMOTOR_FIRST... 
                               MPIEventTypeMOTOR_LAST - 1

                                    MEIEventTypeMOTOR_FIRST ...
                               MEIEventTypeMOTOR_LAST - 1 */
        long       value;   /* MPIEventTypeEXTERNAL */
           } type;

           MEIXmpSignalID signalID;

           /* Contents of addresses specified 
           by MEIEventNotifyData{} */
    union {
        long sampleCounter;
        struct {
           long sampleCounter;
        } motion;
        struct {
           long       sampleCounter;
           long       positionError;
           MEIInt64   actualPosition;
           MEIInt64   commandPosition;
        } axis;
        struct {
           /* Data associated with the CAN event. */
           long data[4];
        } can;
        struct {
           long      sampleCounter;
           long      dedicatedIn;
           MEIInt64  encoderPosition;
        } motor;
        long word[MEIXmpSignalUserData];
     } data;
} MEIEventStatusInfo;

Description:
SynqNet Timing improvements were made to improve node control latency. For 16 kHz drives (the majority of SynqNet nodes), the new scheduling algorithm results in control latency times identical to previous MPI releases. For other drive update rates, and for non-periodic nodes (RMBs), control latency may change.

Since a change in control latency may affect system performance, special attention is recommended for these node types when upgrading from previous MPI releases.

Please see the SynqNet Performance Compatibility section of the online documentation for more information.

The controlLatency sub-structure in MEISynqNetTiming was removed. The calculationTime and calculationSlack were promoted to the MEISynqNetTiming structure.

OLD:
MEISynqNetTiming.controlLatency.calculationTime
MEISynqNetTiming.controlLatency.calculationSlack

NEW:
MEISynqNetTiming.calculationTime
MEISynqNetTiming.calculationSlack

The demandLatency and feedbackLatency were moved to the new per node sub-structure of the MEISynqNetTiming structure.

OLD:
MEISynqNetTiming.controlLatency.demandLatency
MEISynqNetTiming.controlLatency.feedbackLatency

NEW:
MEISynqNetTiming.node[].demandLatency
MEISynqNetTiming.node[].demandLatency

The total latency was promoted and renamed to controlLatency and the latencySlack was promoted and renamed to latencyOverhead.

OLD:
MEISynqNetTiming.controlLatency.total
MEISynqNetTiming.controlLatency.latencySlack

NEW:
MEISynqNetTiming.controlLatency
MEISynqNetTiming.latencyOverhead

Problem/Cause:
meiSqNodeDriveParamGet(...) could not read a string parameter from the Yaskawa SGDS and SGDZ-MD drives.

Fix/Solution:
This problem was corrected.

Problem/Cause:
meiSqNodeDownload(...) did not work with the Yaskawa SGDZ-BS drive when downloading drive firmware. The problem was caused by improper transmit and receive buffer configuration.

Fix/Solution:
This problem was corrected.

Problem/Cause:
mpiMotorEventConfigSet(ENCODER_FAULT) would fail with a service command unsupported error code. This problem was caused by an improper service command configuration in the MPI library.

Fix/Solution:
This problem was corrected.

Problem/Cause:
If the encoder ratio was configured with mpiMotorConfigSet(...), there was a possibility of a hang. The problem was caused by non-atomic 64-bit position reads from the controller. If the feedback values are changing across the 32-bit boundary during the position reads, the calculations in the MPI would not work correctly and the MPI would get stuck in a while loop.

Fix/Solution:
The problem was corrected by changing the position reads and calculations so that they do not require 64-bit atomicity. Additionally, a timeout was added to the while loop, so if the controller fails during the calculations, a TIMEOUT error will be returned.

Problem/Cause:
meiSqNodeDriveParamGet(...) was unable to read the following Yaskawa SGDS and SGDZ-BS drive parameters: MotorCapacity, MotorType, SerialNumber, EncoderType, Customize number, and Electric angle. The problem was caused by an incorrect parameter addresses in the MPI library.

Fix/Solution:
The MPI library parameter addressing was corrected.

Problem/Cause:
The MPI would hang during SynqNet initialization if the controller's motorCount was less than the physical number of motors on the network AND if the physical motor had ABS feedback AND was connected to a Kollmorgen S200 drive. The problem was caused by initializing an ABS feedback device on an S200 with a controller motor object that was not enabled. The MPI code has a while loop that waits for the firmware to update values. Since the motor was not enabled, the values were not updated and the MPI was stuck in the while loop.

Fix/Solution:
The problem was corrected by adding a timeout to the while loop. If the motor ABS initialization does not have a controller motor object, the MPI will return a TIMEOUT. To avoid the TIMEOUT error, make sure to set the motorCount with mpiControlConfigSet(...) to the number of physical motors.

Problem/Cause:
Several new SynqNet timing parameters are calculated when the sample rate is changed. These new timing parameters were not being saved in flash memory by mpiControlFlashConfigSet(...) if the current running sample rate matched the new sample rate. Only the value in dynamic memory (not the flash value) of the sample rate was compared to the new sample rate. The timing values were not written to flash becuase the MPI library function, mpiControlFlashConfigSet(...), did not detect a change.

Fix/Solution:
The value of the sample rate stored in flash is now checked and if the new sample rate is different, all the timing parameters are written to flash. When a new sample rate is set (the flash value is changed) the network is re-initialized and all the new parameters are stored in flash.

Problem/Cause:
If the topology was saved and the controller was powered off/on, the SynqNet network initialization would fail. The problem will not occur on ZMP-SynqNet series controllers. The cause of the problem was that the ASYNQ config buffer and the packet config buffer were not restored from flash during reset. As a result, the firmware was not be able to bring the network to SYNQ mode after a hard reset (power down).

In the case of a soft reset, the data in the ASYNQ config and packet buffers would still be there and things would appear to work normally.

Fix/Solution:
The ASYNQ config and packet config buffers are now explicitly restored from flash during boot up.

Problem/Cause:
If Motion Console was open while another application performed a meiSynqNetNodeRestart(...), certain SynqNet nodes (S200, S1800, and Slice I/O) may have failed to restart. This problem was caused by missing node locks during the restart.

Fix/Solution:
To correct this problem, node locks were added to meiSynqNetNodeRestart(...).

Problem/Cause:
The S200 drive sends the absolute encoder data on both the primary and the secondary encoder. However, in previous versions the primary encoder data did not have the absolute multi-turn data. Instead it had relative multi-turn data. Only the Aux encoder would have the correct absolute multi-turn feedback data. There was a previous initialization fix (MPI 2022) in the 03.04.02 release, which switched the S200 secondary encoder pointer to be the primary encoder value and set the encoder counter to 1 in the controller. As a result, the drive module switched the pointer on the firmware memory. Therefore, when the mpiMotorConfigSet(...) function was called, it overwrote the changed pointer to the default stored in the MEIXMPBuffer memory.

Fix/Solution:
Changes have been made so that the drive module changes the default value stored in the MEIXMPBuffer memory. This will ensure that when the mpiMotorConfigSet(...) function is called, the correct Encoder pointer mapping will occur.

Problem/Cause:
Types of motion that needed frame-low events to reload the frame buffers were causing protection faults (access violation errors). The MPI relied on a valid motion handle being returned for frame low events. An incorrect (or missing) initialization of the event data could have caused an invalid handle to be returned by the event. Access to a motion object using this handle would cause a protection fault.

Fix/Solution:
The MPI now writes the correct motion handle every time the motion (needing frame low events) is started.

Problem/Cause:
The drive module converted the float parameter COMM_OFF to a signed 12bit number and stored it in the drive. When reading back the value, the 12bit signed number was treated as a 32bit signed number without correctly extending the sign bit before converting it to a float, which made the negative COMM_OFF angles appear as large +ve values.

Fix/Solution:
The drive module now reads the 12bit signed COMM_OFF angle and correctly extends the sign bit before converting the number to a float.

Problem/Cause:
During the packet configuration portion of the SynqNet network initialization, controller firmware reads the feedback positions/status and writes the torque demands. The controller firmware writes the torque demands at the time of the packet re-configuration. Since the MPI changed the packet format at the same time that the firmware was writing to the packets, it caused the torque demand value to corrupt the packet data. The "bad" packet was detected by the service channel and caused the MPI return code: 0x1b08 (6920) SqNode: service cmd response timeout

Fix/Solution:
In versions 03.04.03 (and later), the network initialization was corrected by preventing the firmware from writing torque demands BEFORE packet configuration and only allowing the firmware to write torque demands AFTER packet configuration. This change protects both the normal network initialization and the packet re-configuration during network re-initialization.

Problem/Cause:
Although the drive parameters could be successfully stored to the EEPROM of the Kollmorgen S1800 drive, a timeout error message would be returned when calling the meiSqNodeDriveParamStore(...) function.

Fix/Solution:
The parameter storage takes about 30 seconds depending on the number of parameters to be stored. This timing requirement is corrected in the Kollmorgen S1800 drive module so that the meiSqNodeDriveParamStore(...) function will wait long enough to store all the parameters.

Problem/Cause:
When using MPIMotionTypePVT with MPIMotionAttrMaskAPPEND and mpiMotionModify(...) to add frames to an already existing set of frames, the BufferLowLimit did not change and stayed at the default value of -1. As a result, the PVT motion that was generated from multiple motion modify's to append points was running out of frames.

Fix/Solution:
Corrections were made to the MPI so that if a single mpiMotionStart(...) is used with MPIMotionTypePVT and the total sum of frames exceeds 128, the BufferLowLimit will be set to 32 by default, and a Frame Buffer Under-run will not occur.

Problem/Cause:
S200 drives with absolute feedback did not initialize correctly beyond +/-128 revs. The absolute feedback initialization did not use the upper 8 bits of the 16-bit mutlti-turn feedback data.
The S200 drive provides up to 16 bits of multi-turn and 24 bits of rotational absolute postion data. Only the lower 32 bits of position data is available on the cyclic data. The upper bits need to be read from the drive at the time of drive initialization to initialize the correct actual position.

Fix/Solution:
The SynqNet intialization for the S200 was corrected to read the full absolute position data from the drive and initialize the controller's actual position. Also, when the S200 drive uses absolute feedback as its primary source for commutation, only 32 bits of its position are available to the controller. To prevent missing position data, the auxiliary feedback pointer is used as the primay feedback pointer and the number of encoders supported by the drive is reduced from 2 to 1.

Problem/Cause:
The AT_TARGET status bit was not getting set correctly after the first move with multi-point motion (PT, PVT, PTF, PVTF, etc.). The MPI was not calculating the targetPosition correctly in the startID/modifyID frames that were downloaded.

Fix/Solution:
The targetPosition calculations were corrected, so that values were sign extended for full 64 bits.

Problem/Cause:
If Motion Console was running via client/server and the ESC key was pressed to quit the server.exe utility, occasionally server.exe did not exit. The problem was caused by the MPI's server side routine. The MPI was waiting for the packet recv buffer to empty while Motion Console was continually sending packets to the server.

Fix/Solution:
To correct the problem, the packet close routines were changed to immediately shut down the socket connection and not to wait for the packet recv buffer to empty.

Problem/Cause:
All Probe trigger control registers need to be configured to get the probe data coming at the expected location at the feedback packet. In previous versions, the drive module did not configure any probe trigger control register for the depth of the probe and the FPGA used the default depth of one. This caused a problem when the axis had more than one probe.

Fix/Solution:
This problem was fixed by configuring the trigger control registers of all the available probes of the axis during the node initialization.

Problem/Cause:
meiSqNodeUserDataGet(...) and meiSqNodeUserDataSet(...) incorrectly treated the buffer as a string. All data after a null byte would not be written to nor read from a node's user data area. If the data supplied to meiSqNodeUserDataSet(...) did not contain a null byte, it could have corrupted other parts of the process's memory.

Problem/Cause:
meiSynqNetTiming(...) did not properly initialize the calcuationTime and calculationSlack values in the MEISyqnNetTiming structure.

Fix/Solution:
The problem was corrected by translating the values from the controller and initializing the values in MEISynqNetTiming.

Problem/Cause:
Using mpiControlFlashConfigSet(...) to save the frame buffer size to flash would not save the external allocation tables to flash, but would save the frame buffer size in the Axis object. As a result, there was a mismatch (after a reset) between the presumed size in the Axis object and the actual size allocated in external memory causing frame buffer corruption. The symptoms of a corrupted frame buffer are erratic motion profiles.

Fix/Solution:
Changes have been made to mpiControlFlashConfigSet(...) was modified to update the external allocation tables and frame buffer size. The frame pointers in the Axis object will ensure that there will not be a mismatch between them. Anytime the new configuration parameters require the extAlloc tables to be updated in either working memory or flash memory, or both, the SynqNet network will shutdown and be reinitialized. Anytime the new configuration parameters require the extAlloc tables to be updated in flash memory and the SynqNet topology has NOT been previously saved, MEIFlashMessageNETWORK_TOPOLOGY_ERROR is returned and the extAlloc tables will not be updated.

Problem/Cause:
In previous versions, Feedback Fault was not cleared if the Feedback fault event was set to 'None.' Previously, mpiMotionAction(...) checked if the Encoder Fault event status was triggered before it cleared the encoder fault. In firmware version 619A1 (and later), motor limits do not generate events if the action is set to NONE. As a result, if the AmpFault action = NONE and an Encoder Fault occurred, it could not be cleared.

Fix/Solution:
To correct this problem, mpiMotionAction(...) was modified and now checks the Encoder Fault bit instead of the event status, which ensures that the Amp Fault is properly cleared.

Problem/Cause:
A motor limit with a non-zero duration may trigger if the condition is met at the time the limit is configured.

Fix/Solution:
The controller firmware was modified to remove the possibility of false triggers. Changes have been made so that the state may be calculated during configuration. If the state is 0x10 (triggered), it will override the newly calculated state during the first sample after configuration.

Problem/Cause:
The S300 drive module initialization code failed to correctly calculate an internal scale factor when the controller's sample rate was 1kHz, which caused the SynqNet network intialization to fail.

Fix/Solution:
This problem was fixed by correcting the calculation.

Problem/Cause:
Creating multiple recorder objects with the same index did not result in an error.

Fix/Solution:
After creating a second recorder objects of a given index, calling mpiRecorderValidate on that recorder will report the error MPIRecorderMessageRESERVED. Specifying a recorder index that is not reserved when calling meiControlRecorderCancel will result in the error, MPIRecorderMessageNOT_RESERVED being returned. The new error messages have been added to MPIRecorderMessage.

Problem/Cause:
If a node with a version x0103 FPGA is followed by a node with a boot FPGA, then the node with the boot FPGA (and all subsequent nodes) may not be discovered during network initialization.

Fix/Solution:
The delay after sending the ResetComplete packet was increased from 0.1 to 1 seconds.

Problem/Cause:
If Application X calls meiSqNodeDownload(...) to download drive firmware to a Kollmorgen CD or PicoDad drive, then Application Y will hang on mpiControlInit(...) until Application X either exits or destroys its SqNode handles.

Fix/Solution:
Applications will no longer hang when calling meiSqNodeDownload(...).

Problem/Cause:
A memory access violation occurred when calling mpiMotionModify(...) with PVT and APPEND before calling mpiMotionStart(...). This problem was caused by meiMotionFrameBufferCreate(...), which was allocating memory for a frame and appending it to the frameList. When meiMotionFrameBufferDelete(...) was called, it de-allocated the memory without removing it from the frameList. As a result, frameList had a frame on it with no memory associated with it.

Fix/Solution:
meiMotionFrameBufferDelete(...) now removes the frame from the list before freeing up the memory.

Problem/Cause:
Noise from the Test Signal can get added to the DAC output if the test signal is active for PID, the PID multiplying coefficient is zero, and the multiplying coefficient for PIV is non-zero.

Fix/Solution:
The algorithm types are now checked before the Test Signal multiplying coefficient is used.

Problem/Cause:
The AMP Enable was not working properly for Stepper drives. This problem was caused by the AMP enable polarity, which was inverted.

Fix/Solution:
An FPGA configuration was changed. The AMP enable should now function properly.

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:
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 error.

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

Problem/Cause:
In previous versions, the topology checker did not consider ring and string topolgies to be different. It was previously thought that as long as the node types and the ordering of the nodes was the same, the difference between a ring and a string topology was inconsequential. However, for applications that rely on the ring topology for fault tolerance, it is helpful to know if a string was discovered instead of a ring.

Fix/Solution:
The topology checker now verifies that the network type that is discovered matches the expected network type. If the network type does not match, a topology mismatch error will be returned.

Problem/Cause:
Watchdog sample applications encountered race conditions, which would cause intermittent false-positive events.

Fix/Solution:
The watchdog sample applications have been modified and no longer contain a race condition.
See the watchdog1.c, watchdog2.c, and watchdog3.c sample applications.

Problem/Cause:
A memory access violation occurred when mpiMotionMotionModify(...) with PVT and APPEND was called before mpiMotionStart(...).

Fix/Solution:
Changes were made to the MPI to correct this problem.

Problem/Cause:
When enabling more than one recorder, the following error message was received:

Controller 0: mpiControlConfigSet: Control: Invalid record count set for recorder object :: Recorder Number 1 : recordCount must be >= 1

This error would occur when changing recorderCount from 1 to 2 in Motion Console.

Fix/Solution:
A define was added to the MPI for the default recordCount (same as the firmware default = 16384):
       #define MPIControlRECORD_COUNT_DEFAULT (16384)

The MPI will now use the default value if the user's application specifies 0 for recordCount. The error code MPIControlMessageEXTERNAL_MEMORY_OVERFLOW will be returned if there is insufficient memory available for the specified or default recordCount. The MPI will clean-up left-over recordCounts when disabling recorders by setting the recordCounts to back to zero.

Problem/Cause:
In a string topology, the Yaskawa Multi-turn Reset routine would fail if the drive was connected to the controller's SynqNet IN port. The discovery algorithm in the drive module only looked for drives through the controller's OUT port.

Fix/Solution:
The node discovery routine was changed and now accesses the drive through both the IN and OUT ports of the controller. The Yaskawa Multi-turn Reset routine can now work with any topology type.
NOTE: The Yaskawa drive needs to be in Asynq mode when performing a Multi-turn Reset.

Problem/Cause:
Configurable Demand Modes have been added to the MPI. The new feature should be used when it is appropriate for a drive to change its demand mode. Currently, only the S300, S600, and S1800 drives support multiple demand modes. All drives will default to a demand mode that it supports. Check with the drive manufacturer for alternate settings. Nodes that do not support a drive interface (eg RMB, Trust, Soonhan) do not have the option of configurable demand modes, and will show a fixed value of MEIMotorDemandModeVELOCITY.

Fix/Solution:
MEIMotorDemandMode has been added to the MPI and the MEIMotorConfig structure now contains demandMode.

Problem/Cause:
The AMP_WARNING limit action was not configurable through meiMotorConfigSet(...) if the MEIMotorConfig structure was passed in with the MPIMotorConfig structure.

Fix/Solution:
The AMP_WARNING limit action is now configurable through meiMotorConfigSet(...).

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:
Under the following conditions, mpiMotionStart(...) would miscalculate the acceleration parameter for the first section of the PVT (or other multi-point) move. The result was usually a large position discontinuity.

• commandPosition = 2144920611
• origin = 2619887
• first position of pvt = 2144920606

The problem was caused by the MPI using the wrong entry in an array when calculating the initial delta between the current command position and the first point in the path move. As a result, the MPI did not adjust the origin value and subsequently miscalculated the move parameters for the initial frame.

Fix/Solution:
Changes have made so that the MPI uses the correct entry in the array.

Problem/Cause:
In a ring configuration, with topology saved, a service channel timeout would occur during SynqNet initialization. As a result, all communication via the service channel would fail. The problem was caused by an improper logical sequence when turning off the repeater on the last node, which caused the service channel DONE handshake bit to be stuck on.

Fix/Solution:
The problem was corrected by clearing the status header BEFORE starting the service channel transaction that turns off the repeater. The fix was implemented in the controller firmware.

Problem/Cause:
The meiContorlInfo(...) method incorrectly decoded the labels for the digital inputs on a ZMP-SynqNet controller. However, the information for an XMP-SynqNet controller was reported correctly.

Fix/Solution:
The meiContorlInfo(...) method has been modified and now correctly reports information for both ZMP-SynqNet and XMP-SynqNet controllers.

Problem/Cause:
A position jump resulted when an mpiMotionStart(...) with an S-Curve move type and final velocity attribute was followed by a mpiMotionModify(...) during the last few samples of the S-Curve motion. Due to a race condition between the foreground and background task in the controller, the final velocity portion of the move was misscalculated because the trajectory time value was incorrect.

Fix/Solution:
To correct the problem, the logic for setting the time value for a velocity frame was changed. If the modify flag is not set, time = 0. If the modify flag is set and the count is not 0, do not change the time value because it is already the correct value. If the modify flag is set and count == 0, add the feedrate to the TC.Time value to get the time value.

Problem/Cause:
The command shaping was only applied to position so the velocity and accleration feedforwards were calculated based on the shaper input rather than the output. This problem would only appear if Convolve patented trajectory shaping was enabled.

Fix/Solution:
The shaping filter was modified to shape both the command position and velocity. Since the acceleration used for feedforward is derived from the shaped velocity the acceleration feedforward has also been corrected.

Problem/Cause:
In previous versions, meiSqNodeFlashConfigSet(...) did not save the packet error upStreamError limits to flash because there was no place in the firmware memory allocated to store the values.

Fix/Solution:
Registers were added in firmware to hold fault and fail values for all nodes. Values can now be saved to flash memory. The firmware was modified to use the values specified to set the fault and fail thresholds instead of using the defines.

Problem/Cause:
mpiRecorderCreate(...) allows an application to create multiple recorder objects using the same controller recorder number. mpiRecorderCreate(...) also supports a (-1) for the recorder number, which will automatically select the next available recorder. If multiple recorder objects are created specifying the same recorder number (0,1,2, etc.) and one object is deleted (but not all), the next mpiRecorderCreate(...) call with recorder number = -1 may improperly, automatically select a recorder number that is not available.

Problem/Cause:
If the network topology is a string or dual-string, and the first node connected to the controller's IN port has a Boot FPGA version 0x020C, then any nodes beyond the first node will not be discovered. To recover, download the Runtime FPGA to the node. After the Runtime FPGA is downloaded, all nodes will be discovered properly.

Problem/Cause:
Kollmorgen S1800 drives (Firmware versions v1.7, v1.8) do not support direct service commands to configure monitors. The MPI will return an UNSUPPORTED error for S1800 drive monitor configuration.

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.

Warning!
The motor can jump if you perform the following sequence:

1. Use the STOP action to pause a motion.
2. Disable the amplifier.
3. Physically move the motor with an external force.
4. Enable the amplifier.
5. Motor will servo to the location where the amplifier was disabled. This may cause a motor to jump!

To avoid a jump, either use E-STOP or use a motion RESET action to clear the trajectory before the amplifier enable.

Cause:
This behavior is a result of the STOP action, which pauses the motor on the move trajectory. Since the trajectory is still active, an amp disable/enable will not automatically set the command position equal to the actual position. The move trajectory can be continued by using the RESUME action or cleared by the RESET action.

Problem/Cause:
The motion types: MPIMotionTypeS_CURVE, MPIMotionTypeTRAPEZOIDAL, and MPIMotionTypeS_CURVE_JERK do not support move lengths beyond 31 bits (+/- 2,147,483,648). Longer moves will require the application to break-up the motion into multiple mpiMotionStart(...) and mpiMotionModify(...) calls. The maximum move distance will be extended in a future release. The motion type: MPIMotionTypeVELOCITY does not support acceleration or deceleration profiles (acceleration frame) longer than 31 bits (+/- 2,147,483,648). Make sure the acceleration distance (Vinitial * time + (Accel/2 * time * time)) is less than 31 bits.

Problem/Cause:
The Data Recorder does not support 64bit position comparisons. Only the lower 32bits are evaluated for position triggers.

Problem/Cause:
The velocity demand mode does not support an "Acceleration Feedforward Torque" demand to the drive. This feature will be added in a future release. See SynqNet Demand Modes.

Problem/Cause:
The MPI only supports drive map files (*.dm) for Windows XP/NT/2000. Alternative operating systems are not supported. This feature will be added in a future release. See SynqNet Drive Parameters.