Release Note
MPI Library Version 04.00.03

Description

Support was added to the Kollmorgen S200 drive module for Endat 2.2 and BISS ABS feedback devices. The MPI drive module will automatically determine the feedback device type and initialize the absolute position value during SynqNet network initialization.

Description

Controller simulation is now possible with the MPI library. A new control type, MPIControlTypeSIMULATION has beed added for use by the server.exe utility program when used with the controller simulation software package. The MPIControlTypeSIMULATION type is for internal use only, it is NOT for use by your application's call to mpiControlCreate(...).

Controller simulation is only available when the Controller Simulation software package is purchased and installed on your PC. See Simulation Server for more information.

Description

New NO_WAIT motion attribute masks are available for Point-to-Point, Velocity, and Path move functions. The NO_WAIT attribute allows the move function to return as quickly as possible, by skipping the controller profile load error check and motion profile start execution check. The NO_WAIT attribute does not affect the latency between the move call and the commanded position increment.

This feature should be used if an application requires the fastest possible MPI motion function execution. Additionally, sacrifice profile calculation/loading error reporting and handle race conditions when the controller's motion profile starts and the MPI reports the motion state as MOVING.

How do I use this feature?

For more information on how to use this feature, see MPIMotionPointToPointAttrMask, MPIMotionVelocityAttrMask, and MPIMotionPathAttrMask.

Description:

A new function was added to set the thread priority when adding functions to the event callback list:

mpiControlEventCallbackAddEx(MPIControl control,
MPIControlEventCallback callback,
MPIThreadPriority priority,
void *userData,
MPIEventFilter *eventFilter);

This new function is an extension of the existing mpiControlEventCallbackAdd(...). In version 4.1, mpiControlEventCallbackAddEx(...) is deprecated and replaced with mpiControlEventCallbackAdd(...), including the thread priority argument.

How do I use this feature?

For more information about this feature, see mpiControlEventCallbackAddEx(...).

Description
The MPI now supports MPIEventTypeMOTION_START to complement MPIEventTypeMOTION_DONE. The MOTION_START event triggers when the commanded trajectory velocity is non-zero. For more information, see Motion Start Events.

Description:
A Clear All Faults command was added to the sqDriveMsq Utility allowing all drive faults and warnings to be cleared.

How do I use this feature?
In the SqDriveMsg command line, enter -Clear to remove all drive faults and warnings.

Description:
Due to restrictions on drive frequencies, not all controller sample rates are valid on all networks. To resolve this problem, mpiControlValidSampleRate and mpiControlNearestValidSampleRate were added. mpiControlValidSampleRate(...) returns a structure containing the valid rates for a given controller. If the noRestrictions flag is TRUE, any controller rate between the minimum and maximum is valid. mpiControlNearestValidSampleRate(...) is used to determine the closest valid rate to the desired rate.

These functions should be used to determined what values for MPIControlTimingConfig.sampleRate are valid.

Description:
New SynqNet functions and structures were added to identify network topology for the actual physical (discovered) network. This is useful for verifying when the discovered network topology matches the application's expected network topology.

The following items were added to synqnet.h:
MPISynqNetNodeTopology
MPISynqNetTopology
mpiSynqNetTopologyDiscovered

How do I use this feature?
A user initializes a SynqNet network and the software returns a Network Topology Mismatch error:

MPISynqNetMessageTOPOLOGY_MISMATCH
or
MPISynqNetMessageTOPOLOGY_MISMATCH_FLASH

To determine the cause of the mismatch you can compare the controller’s discovered network topology information with the expected topology information. From this comparison, you are able to identify the physical network problem (missing node, different node, extra node, failed node, incorrect wiring, etc.), correct the physical mismatch, and re-initialize the network successfully.

Description:
A new action, MPIActionTRIGGERED_MODIFY was added. The action can be specified for a user limit's configured action. When the limit triggers, a motion modify occurs for all axes associated with the parent motion supervisor. The motion modify parameters are specified in the MPIAxisEstopModify{...} structure by using mpiAxisConfigGet/Set(...).

Description:

The following functions now have remote methods to improve performance during client/server operations:
mpiAxisCommandPositionGet(...)
mpiAxisActualPositionGet(...)
mpiAxisPositionError(...)
mpiMotionStatus(...)
mpiControlResetToDefault(...)
mpiAxisStatus(...)
mpiMotorStatus(...)
mpiSynqNetStatus(...)
mpiSqNodeStatus(...)

Affects to Application Code:
No application code changes are necessary. If upgrading from a previous version, make sure to upgrade the MPI software runtimes on both the server and client side.

Description:

Several Motion, Axis, and Motor status methods and data types were updated to correct existing problems, inconsistencies, and to simplify the MPI interface. These objects include:

• MPIMotorStatus
• MPIMotorFeedbackStatusMask
• mpiMotionStatus
• mpiAxisStatus
• mpiMotorStatus

Additionally, the following new data types and functionality were added:

• MPIMotionStatus
• MPIAxisStatus

Description:

The following objects and functionality that were previously in the Flash object were integrated into the Control object:

• mpiFlashMemoryFromFile is now mpiControlFlashLoadFromFile
• mpiFlashMemoryToFile is now mpiControlFlashSaveToFile
• mpiFlashMemoryVerify is now mpiControlFlashVerify

Additionally, the following new Control objects and functionality were added:

• mpiControlFlashErase
• mpiControlDefaultFile
• mpiControlFlashSaveAll

Problem/Cause:

Trajectory - XMP processor supports float data type. The ZMP processor supports float and double data types. In 03.04, the trajectory calculator uses floats for both the XMP and ZMP.

The problems are due to limitations of the float data type and include:

• Command and Actual Position delta per sample period is limited to 31-bits. Zero position does not work if command - actual > 31-bits.
• Move distances are limited to 31-bits. Trapezoidal and S-Curve moves must be less than 2.1 billion counts. For S200, this is 128 revs.
• Trajectory resolution loss at move distances and velocities greater (24-bits). Frame position and time inaccuracies cause profile disturbances at distances > 16.7 million cts. Motors generate audible buzzing noises (>29-bits).
• Motion Hold source is limited to 32-bits.

Limitations for Recorder include:

• 64-bit values (doubles) are not supported by addresses or triggers.
• Floating point comparisons are not supported, only integer or bit-masks.
• Pre-triggers are not supported.

Limitations for Motor Limits include:

• Double data type values are not supported.

These issues are caused by XMP processor not being capable of dealing with native double data types.

Fix/Solution:

Note: XMP support for the 4.0 branch is no longer supported.

This allows the use of doubles in the firmware. For consistency and better accuracy, all floats in the firmware and MPI have been changed to doubles. Floats are no longer used by the firmware or the MPI.

Description:
Previously, path motion types were limited to 5000 points, as the intermediate buffers were statically allocated. This limitation has been removed and the code was updated to use the meiPlatformRealloc() function to dynamically resize the intermediate buffers as necessary.

Description:
In previous versions, if a motion was stopped and the amplifier was disabled and the disableAction was configured for command equals actual, the command position follows the actual position. When the amplifier was re-enabled, the motor reverts to the original stopped position.

If a STOP or E_STOP action occurs and the amplifier is disabled, the command equals actual feature will not be active. The actual position does not follow the command position allowing the STOPPED or E_STOP position to be maintained during the Amp Enable/Disable action.

Description:
The MPIObjectMaps were provided as an interface to create relationships between objects. They did not remap objects or provide any functionality in the controller. The MPIObjectMaps have been removed since it is a legacy interface providing no functionality.

Note:
Remove the MPIObjectMaps if your application is using them. Removing these object maps will have no effect on the controller objects.

Description:
The MPIMotorDacConfig structure was replaced with the mpiMotorDemandMode Offset and Output functions. These functions allows the user to read/write the demand offset and read the demand output for all the demand modes. These are useful for open-loop control.

Previously, MPIMotorConfig(...) and MPIMotorDacConfig(...) could only be used to adjust output levels for ANALOG and DUAL_ANALOG demand modes.

For more information, see:
mpiMotorDemandModeAnalogOffsetGet/Set(...)
mpiMotorDemandModeAnalogOutput(...)
mpiMotorDemandModeDualAnalogOffsetGet/Set(...)
mpiMotorDemandModeDualAnalogOutput(...)
mpiMotorDemandModeTorqueOffsetGet/Set(...)
mpiMotorDemandModeOutput(...)
mpiMotorDemandModeVelocityOffsetGet\Set(...)
mpiMotorDemandModeVelocityOutput(...)

Description:

The enumeration for MPIMotorFaultBitAMP_NOT_POWERED was renamed to MPIMotorFaultBitNOT_READY_FOR_REMOTE_CONTROL. This was changed to match the hardware definition.

A new MPI interface was defined to read the NOT ready for remote control register from the drive. This register indicates the fault status.

When this interface is called on a drive which supports this direct command, the drive reports the reason for NOT setting the Ready For remote control bit. This is a new feature and is currently not available on existing drives

Description:

Due to the new User Limit feature, the dedicated limits were moved to a separate simplified interface. mpiMotorEventConfigGet/Set(...) was replaced with mpiMotorLimitConfigGet/Set(...) and a MPIMotorLimitType enumeration. The new interface allows each dedicated limit to be configured individually or all of the dedicated limits can be configured with mpiMotorConfigGet/Set.

For more information, see MPIMotorLimitType, MPIMotorLimitConfig, mpiMotorLimitConfigGet, and mpiMotorLimitConfigSet.

Description:

The output limits were extended to support velocity demand mode.

The output limits are applicable with the PID algorithm for velocity mode drives. They are not used with the PIV algorithm.

There are two values, one to set the high limit and one to set the low limit. For a bipolar limit, set these values to +/- the limit value.

Description:

Drive firmware version checking in drive map file was changed from case sensitive to case insensitive.

This was corrected by defining the meiPlatformStricmp () function in platform.c which internally calls function _stricmp() and for drive firmware version checking, meiPlatformStricmp() was replaced by strcmp() in the drivemap.c file

Description:

Monitor values are now reported in the range of –32768 to +32767. If the monitor value represents an unsigned type, the application must cast the value to a signed short.

Description:

The previous mpiObjectHandle(...) methods take an object and return a handle. In this scenario, the user must validate the returned handle with mpiObjectValidate(...). To simplify the interface, the mpiObjectHandle(...) methods now take two arguments, an object handle and a pointer to a handle. The method returns an error code indicating success (MPIMessageOK) or failure (MPIMessageHANDLE_INVALID).

The following methods have been changed:

mpiAxisControl
mpiCaptureControl
mpiCompensatorControl
mpiClientControl
mpiFilterControl
mpiFlashControl
mpiMapControl
mpiMotionControl
mpiMotorControl
mpiProbeControl
mpiRecorderControl
mpiSequenceControl
mpiSynqNetControl
mpiSqNodeControl
mpiServerControl
mpiSqNodeSynqNet
mpiServerClientPacket
mpiServerPacket
mpiClientPacket
mpiControlPlatform

Example:

Old
control = mpiMotorControl(motor);
returnValue = mpiControlValidate(control);
msgCHECK(returnValue);

New
returnValue = mpiMotorControl(motor, &control);
msgCHECK(returnValue);

Description
The server.exe command line utility has been extended to provide the user the ability to view the clients and selectively terminate a client/server connection.

To exit server.exe, either press the ESC key. This terminates all client connections. Press the S key to view and select a specific client connection to terminate.

Problem/Cause:
User limits configured for the MPIUserLimitLogicLT or MPIUserLimitLogicGE logic types, evaluating 64-bit data values (double or fixed point) would trigger incorrectly.

The problem was caused by an internal enumeration for the limit type logic.

Fix/Solution:
The enumeration was corrected.

Affects to Application Code:

No application changes are necessary.

Problem/Cause:
The Motion Behavior attribute in the MPIMotionPointToPointAttributes{...} structure was not ignored when the MPIMotionPointToPointAttrMaskBEHAVIOR bit was not set in the AttrMask.

The problem was caused by a redundant check in the MPI library.

Fix/Solution:
The problem was corrected by removing the redundant code.

Affects to Application Code:

No application changes are necessary.

Problem/Cause:
mpiSqNodeCreate(...) does not return an error when there are no nodes connected to the network

The problem was caused by mpiSqNodeCreate(...) not checking the number of nodes on a network if the network did not have any nodes.

Fix/Solution:
The problem was corrected by verifying connected nodes to the network.

Affects to Application Code:

No application changes are necessary.

Problem/Cause:
MPIControlEventCallbackAdd() was not filtering events correctly when the eventFilter argument was non-NULL.

MPIEventFilter was incorrectly declared as a union in event.h, causing the source, sourceCount, and eventMask fields to conflict.

Fix/Solution:
MPIEventFilter was changed from a union to struct.

Callbacks can be filtered with by source, eventType, or both.

Affects to Application Code:

No application changes are necessary.

Problem/Cause:

Repeated calls to mpiControlDelete() could result in an application crash due to lack of available handles.

mpiControlDelete() was not releasing the handles used to synchronize access to the MPICompensator objects associated with that MPIControl.

Fix/Solution:
mpiControlDelete() was modifed to release the handles used to synchronize access to the MPICompensator objects associated with that MPIControl.

Repeated calls to mpiControlDelete() will no longer result in increased handle usage.

Problem/Cause:
The compensator may not work properly, causing the output axis to jump. The MPI compensation tables, configured by mpiCompensatorTableGet/Set(...) were defined as longs instead of doubles.

The problems were caused by:
The controller firmware had the data type for the compensation table data as a double, when MPI was using a long.

Fix/Solution:
The problem was corrected by changing the table arguments from long *table to double * table:

New:
mpiCompensatorTableGet(MPICompensator compensator, double *table);
mpiCompensatorTableSet(MPICompensator compensator, double *table);

Affects to Application Code:

WARNING: If you are upgrading from version 04.00.00, you must recompile your application and use doubles for compensation tables. The interface for mpiCompensatorTableGet/Set(...) is not compatible between 04.00.00 and 04.00.01.

Problem/Cause:
The following Cam move configurations do not execute properly:
1) Cam configured to use motor feedback for the axis master type.
2) Cam is configured to start at a specific MASTER_START position.
3) Repeating relative Cam with drift (where the cam move start and finish are not at the same position).

The problems were caused by:
1) mpiAxisConfigSet(...) improperly configured the cam pointer to the motor feedback and the firmware was using a long (instead of a double).
2) The hold frame was not implemented correctly, it was using a long instead of a double.
3) The Cam move position bias calculations and firmware were incorrect.

Fix/Solution:
The problems were fixed by:
1) mpiAxisConfigSet(...) was corrected to configure the cam pointer to the motor feedback and the firmware was corrected to use a double.
2) The hold frame in mpiMotionCamMove was corrected to use a double.
3) The Cam move position bias calculations were corrected and the firmware position bias offset was corrected.

Problem/Cause:
mpiMotionSCurveJerkPercentMove() was not using the finalVelocity parameter correctly. Final velocities were always zero.

The underlying code swapped two its parameters in a function call, resulting in a zero value for final velocity.

Fix/Solution:
The swap was corrected and non-zero final velocities are specified correctly.

Problem/Cause:
If an axis was configured for sub-sampling (sub sample = 2 or 4), the command trajectory parameters were scaled properly but not actual velocity parameters. For example, if the sub-sample factor was 2 (every other sample), the mpiAxisActualVelocity(...) would incorrectly report a 2x higher velocity than true actual velocity.

The problem was caused by a missing sub-sample calculation in firmware.

Fix/Solution:
The problem was corrected by adding the sub-sample calculation.

Problem/Cause:
When commanding a motion with MPIMotionOutputTypeADDRESS, the address was not correctly translated to a firmware address resulting in an error.

The problem was caused by an internal MPI function assigning the translated value to the wrong location, resulting in a untranslated value being used.

Fix/Solution:
The problem was corrected and the address now properly translates to a firmware address.

Problem/Cause:
mpiSqNodeInfo(...) incorrectly orders the CRC InPort and OutPort values from the node. The MPINetworkPortIN0 was swapped with the MPINetworkPortOUT0. Additionally, Motion Console improperly swapped the controller summary CRC InPort and OutPort values.

This problem was caused by the ordering of the MPI code reading the controller and node InPort and OutPort CRC registers.

Fix/Solution:
The problem was corrected by swapping the order of the In and Out in the MPINetworkPort enumeration. This change corrects both the MPI and Motion Console.

Problem/Cause:
Previously, running multiple client applications that read events from a remote controller using interrupts could cause the loss of events and in certain situations deadlocks.

Fix/Solution:
Multiple client applications can now read events from a remote controller using interrupts.

Limitation:
The controller event service routine feature started by mpiControlEventServiceStart(...) uses interrupts when MPIWaitFOREVER is specified for the sleep parameter.

However, only one thread can access an interrupt when accessing a controller over a client-server connection. Additionally, the SyncInterrupts feature uses interrupts. To use the SyncInterrupt feature, the event collection thread must use polling or the SyncInterrupt routine must call mpiControlProcessEvents(...).

Problem/Cause:

The Windows XP Device Driver interrupt handler has a race condition when multiple threads are waiting on interrupts resulting in calls waiting for interrupts that already occurred. On the next interrupt, the application thread awakens and continue normally.

In the device driver, when an interrupt occurs the ISR is called. The ISR wakes up and checks the controller to see if the interrupt was sent. If sent, the OBDR register is cleared and will not continue to generate interrupts. Afterwards the ISR calls a function to request windows to run the DPC (Deferred Procedure Call) and exits. The DPC is run at a lower IRQLevel task than the ISR and is processed afterwards. When executed, the DPC checks to see if any tasks are waiting in the queue. If there are tasks waiting, the DPC wakes them and exits. If there are no tasks waiting, the DPC sets an internal flag called UnHandledInt and then exits.

When the application waits for an interrupt, it calls an MPI function which in turn calls DeviceIOControl(MEIXMP_IOCTL_INTERRUPT_WAIT). This causes the driver to check the UnHandledInt flag. If the flag is set, it is cleared and returns control to the application. If the flag is not set, the call is put into the wait queue and block.

The logic behind the UnHandledInt flag is that if an interrupt occurs before a wait call, then the wait call will not have to wait for the next interrupt and returns immediately.

The problem is that the DPC runs at a different IRQLevel than the MEIXMP_IOCTL_INTERRUPT_WAIT code. This causes the DPC to interrupt the processing of the MEIXMP_IOCTL_INTERRUPT_WAIT code which produces a race condition that occurs with the UnHandledInt flag and the placing of the wait call in the queue. The result is that the wait call gets placed in the queue and the UnHandledInt flag is set. When this instance, the wait call never gets freed from the queue and the application waits for an interrupt that has already occurred.

On the next interrupt, the DPC releases the queued interrupt and the application resumes.

Fix/Solution:
The device driver was updated with new IOCTLs.

Limitation:

Problem/Cause:

In the method mpiMotorInfo(...), MPIMotorInfo.sqNode.driveIndex was incorrectly set to the motor number.

Fix/Solution:
mpiMotorInfo(...) was corrected. MPIMotorInfo.sqNode.driveIndex is now set to the offset of the drive interface for the motor, relative to the node. For motors without drive interfaces, it is set to -1.

Problem/Cause:
MPI methods used for reading segment information from the slice IO were not thread safe. As a result, faults occur when more than one thread was accessing the same method.

This was caused by not implementing thread safety in methods accessing slice IO hardware.

Fix/Solution:
Thread safety was added to the MPI methods which provides more than one thread to access the slice IO hardware without causing a fault.

Problem:

Client/Server architecture does not support multiple client threads.

Cause:

The Server architecture is not compatible with multiple client-side threads. All client-side threads share the same server connection to the same server thread. The result is that locks are not honored on the server since it is the same server thread acquiring and releasing locks. This has been fixed in MPI 04.02.xx.

Problem:

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

Cause:

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

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

Description:

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

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