Release Note
MPI Library Version 04.03.05

Problem:
There is NO brake mode in the I/O Window on the Motion Console. The function of Home1.c returns 0x631.

Cause:
The Axis and Motion objects were created before mpiControlConfigSet().

Fix/Solution:
The code was changed so that Axis and Motion objects are created after mpiControlConfigSet().

Affects to Application Code:
The same problem was also fixed in dmc_capture1.c, dmc_capture2.c, schall1.c seq1.c and watchdog3.c.

Problem:
Compare and Recorder will overwrite each other causing the features to crash.

Cause:
This was caused by a resource misalignment. The MPI assigns the same memory address to CompareValueBuffer and RecorderBuffer.

Fix/Solution:
The memory address assigned to RecorderBuffer was changed so that it no longer conflicts with CompareValueBuffer.

Affects to Application Code:
Compare and Recorder should no longer have conflicts when used at the same time.

Problem:
When the amplifier was enabled there was a jump in position.

Cause:
A delay occured between the amp enable signal and the amp actually becoming active. The delay can be up to 25 milliseconds. During this time the command position is no longer set to the actual position so position errors can build up while the servo is unable to correct for this position error.

Fix/Solution:
A change was made to the firmware and the MPI so that the command position will remain set equal to the actual position until the amp active signal is true. This will prevent position error build-up while the amp is inactive and unable to servo properly.

Affects to Application Code:
When the amp is enabled, the command position will continue to be set equal to the actual position until the amp active bit is true. Once the amp active is true, the servo will be able to run properly and reduce the position error before a large error can build up, and cause jump in position.

Problem:
The S200 initial absolute position was incorrect for certain feedback values if the primary feedback was selected via the AUXFB (J14) connector. This includes Endat2.1 sin/cos feedback and Mitutoyo feedback. This particular issue did NOT apply to any base unit feedback (J3) such as SFD.

Cause:
At SynqNet discovery, the initial 64-bit feedback requires sign extension from the multi-turn count MSB. For primary feedback on AUXFB, the MPI accidently used the wrong bit (bit 23) to trigger sign extension. So for some feedback values, there was no sign extension and initial position was correct. For other feedback values, sign extension corrupted the multi-turn count.

Fix/Solution:
The MPI code was modified to correct this sign extension.

Affects to Application Code:
The MPI now allows for 12 bits of multi-turn count for primary feedback on AUXFB (36 bits of total absolute resolution).

Problem:
When running an application like MoCon or motion4 sample program (esp using AKD at high sample rates), occasaionally, this error surfaces. If a customer application sees this, it will likely stop their application. However, it is hard to reproduce.

Cause:
Double comparison checked for 3 consecutive memory reads, which essentially needed to be the same. At high sample rates, and with doubles which change values (because of high-resolution encoders), this is error is likely to happen. It is also more likely in a loaded system.

Fix/Solution:
On modern PCI systems, one read suffices because PCI reads use burst-reads which can read both 32-bit words atomically. Thus, one double read was sufficient, no comparison between successive reads necessary. For older systems which did not support burst 2-word reads, double comparison used 2 consecutive matches which have a much higher probablity of succeeding.

Affects to Application Code:
No copy64 error will result in modern PCI systems, and for older systems, the error will only arise in failure cases (e.g. when the sample rate is too high to be supported by the system).

Problem/Cause:
With MPI 04.xx.xx, primary feedback selected from the S200 option card connector (Aux connector J14) has an invalid absolute position after the mpiMotorConfigSet() function is called. The absolute feedback will be CORRECT after node initialization (controller reset, or network reset).

The issue has existed since MPI 04.00.00 and still exists as of MPI 04.03.01.

This was an issue with MPI mapping pointers inside the SynqNet controller (not in the S200 drive hardware).

Fix/Solution:
A workaround using application code will be investigated. An MPI update is expected for the final solution.

Affects to Application Code:
With either the workaround solution, or the MPI fix, absolute feedback remains valid after mpiMotorConfigSet().

Problem/Cause:
After running MoCon overnight in a system with several nodes, the host computer seemed very sluggish. This behaviour was not seen in 32-bit systems.

The device driver has a list of treads waiting for interrupts. This list contains a unique 64-bit identifier for each thread that is assigned by the driver. The identifier is passed back to the thread and expected to be used but that thread for all interrupt calls (wait, pend, wake). Due to a mistake in the function mpiPlatformOSInterruptWaitPend(), the identifier was truncated to 32 bits by the MPI which caused the driver to allocate a new identifier for each mpiPlatformOSInterruptWaitPend() call. Since each new identifier was added to the list of known identifiers, the list would grow each time the function was called. After an overnight run the list would be large enough (>1,000,000 entries) that searching it in the driver was impacting performance.

Fix/Solution:
The truncation of the identifier was removed from the MPI. The search would now correctly find an identifier previously issued so each thread would only have one identifier.

Affects to Application Code:
The performance no longer degrades with time.

Problem/Cause:
mpiUserLimitConfigSet() times out when called repeatedly from different threads.

Two threads writing into the firmware's limit enable queue would cause occasional missing entries in the queue. In that case, the thread waiting for the enable would time out.

Fix/Solution:
A lock was used to control access to the firmware's limit enable queue by different threads.

Affects to Application Code:
The enabling of the limits is assured for all threads.

Problem/Cause:
If you do a coordinated motion with hold values set, the hold condition value and timeout value will be word-swapped in axis 1, but OK in axis 0 (assuming a 2-axis motion).

Fix/Solution:
Word-swapping was fixed.

Affects to Application Code:
Coordinated motion with holds work correctly for release holds correctly on all axes.

Problem:

Multiple *.dm files in the node directory may cause unexpected results when using meiConfig. It is recommended that you only have one file in this directory with the .dm extension per drive type. When multiple drive map files are present, it is possible that meiConfig will use the wrong one or an out of date .dm file.

Cause:

MeiConfig expects a clean directory and doesn’t know about copies and test DM files. MeiConfig reads every  file with a .dm extension, and uses the first instance where the CONTENTS of the drive map file match the drive type.

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.

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

Description:

While running server.exe on the eZMP with S200, a timeout error occurs when sqNodeFlash.exe is run on the client PC.

Description:

At the time of the release, the development of SimServer had not been completed. This feature is released as a standalone package and is not included in the MPI distributables. SimServer is planned to be completed and supported in the next MPI release (04.02.01).