Release Note
MPI Library Version 04.04.07

Problem:

If customer is using certain MPI methods as both Service and Application, controller will lose synchronization sometimes.

Cause:

The MPI lock control didn't support global lock control. Since, MPI lock did not support global control, If customer was using a Windows Service, the lock control between service and application layer was not functional.

Fix/Solution:

Now we can use MPI on both Service and Application at the same time.

Problem:

Because there is no LOCK and UNLOCK, if multiple threads call those functions at the same time, they collide and the functions can not return the correct value.

Cause:

LOCK and UNLOCK missing from the source code.

Fix/Solution:

Added LOCK and UNLOCK code to the mpiAxisCommandPositionGet(), the mpiAxisActualPositionGet() and other functions.

Problem:

The Compute command of sequencer could not work.

Cause:

A bug was found in the firmware. The compute command could not refer to the target address.

Fix/Solution:

This problem was fixed by a firmware code change. The compute command should work from 918A5.

Problem:

MPI had a wrong operation of the address in compare configuration.

Cause:

Coding error.

Fix/Solution:

The correct operation was implemented.

Problem:

To flush the last flash command, the last address was read back. This code had a bug and it was reading back a different address. Sometimes the address would be close enough to flush the command, and other times it would be completely different from the last address written.

So sometimes the erase was successful, other times it failed.

Cause:

The wrong address was used to read back the last command sent to the flash. i.e. the flash chip did not get the last command to erase it and presumably times out.

Fix/Solution:

The boot sector erases correctly.

Problem:

The downstream error count increases every few seconds on all SynqNet nodes. No other errors are visible, and the system continues to run normally.

Cause:

The root cause is in the ZMP controller FPGA version 324_A301.fpg and has been resolved in version 325_A301.fpg. This fix is recommended per customer request if the downstream error issue occurs on any MPI 04.xx.xx system. Note these downstream errors are caused by transmit timing errors and should be eliminated if they occur.

Fix/Solution:

FPGA version 325_xxxx.fpg has been modified to prevent this issue.

The version 325_xxxx.fpg FPGAs are recommended for all MPI 04.xx.xx versions, and all controller hardware versions.

Note: controller FPGAs are downloaded every time flash.exe updates firmware. The default FPGA version is loaded unless the command line option is used, for example:
cmd> flash.exe -fpga0 325_A301.fpg ZMP913B3.bin
An MPI change is required to modify the default FPGA version.

Problem:

Depending on the sequence program, QMP will emit an alignment violation exception error then stop.

Cause:

QMP accesses 32 bit data twice and makes 64 bit data now.

Fix/Solution:

QMP accessed 64 bit data regardless of 32 bit data and 64 bit data at condition wait and calculation.

Problem:

mpiMotionPositionGet() receives incorrect position data when mpiAxisOrginSet() is called.
using mpiAxisCommandPositionGet() or mpiAxisActualPositionGet() returns correct position data.

Cause:

After calling mpiAxisOriginSet(), the Axis object executes a sample count wait. In MPI 03, the Motion objects have related Axis objects, so no problem exists. However in MPI 04, the Motion objects does not have related Axis objects and poses a problem as mpiMotionPositionGet() does not know whether mpiAxisOriginSet() is called or not.

Fix/Solution:

After calling mpiAxisOriginSet (), the Control object also executes a sample wait. Additionally, the motion objects can call a sample wait function using the control object and axis number.

Problem:

MPI has a certain initialization function and the argument interface was changed in 04.04.02. However the S200 Tool is unaware of this change, the MPI returned an error by argument mismatch when the function was called.

Cause:

This cause is the MPI interface change in 04.04.02.

Fix/Solution:

The correct initialization function is now called.

Problem:

When data is exported as hex to file, the values are bad.

Cause:

Eg.: When controller data was 0x80000001, exported data was 0x80000000.

Fix/Solution:

Also: Hex format display wasn't implemented correctly.

Problem:

This feature checks and validates the size of firmware address for 64-bit MPI builds.

The size of the firmware address is 32-bit. But if a customer made a mistake and set the wrong software build option, the firmware address becomes a 64-bit value.

This feature is introduced to catch this error. However, it will be 64-bit when customer sets wrong software build option.

Cause:

NA

Fix/Solution:

Check firmware address size when application call the mpiControlCreate().
If it is bad, it will return "Control: Firmware address size mismatch.".

Call yjr mpiControlCreate()

Problem:

If the application uses the 'Capture State' address by MPIUserLimitConditionTypeCUSTOM and sets configuration using mpiUserLimitConfigSet, then, when calling mpiUserLimitConfigGet(), the type is returned as MPIUserLimitConditionTypeCAPTURE_STATE.

Cause:

mpiUserLimitConfigGet().

It is determined only by the address that set the condition type. Additionally, the custom setting is changed to the simple setting of each condition type.

Fix/Solution:

The condition type is stored in a firmware field and retrieved when mpiUserLimitConfigGet is called.

The types that are set are read properly in the get functions.

Problem:

For AKD & S200 drives, if the user generates an Abort action (Disable action), the 'Near Target' status will be TRUE.

Cause:

The motor status data was incorrectly getting reflected in the axis status and causing a spurious status.

Fix/Solution:

When motion is aborted, the wrong bit from motor status is not copied to the axis status.

Problem:

In a certain situations, the motor gearing function did not work well.Example is when using a high value for the resolution and spinning the motor shaft at high speed.

Cause:

This problem was in unit size of firmware calculation.

Fix/Solution:

The calculation was fixed and the motor gearing works as expected.

Problem:

Axes are assigned to the following:

1. MS - Axis map
MS#0: Axis#0
MS#1: Axis#1
MS#3: Axis#0 + Axis#1

2. Motion start
MS#0: start.

3. EStopAbort
MS#2: EStopAbort.

4. Problem
Axis#0 abort soon.

Cause:

This problem occurs when two or more axes are assigned to a motion supervisor (MS). The axis staus of the 2 or more axes were not combined properly.

Fix/Solution:

When multiple axes are being assigned to a motion supervisor, each axis staus is properly combined to set the motion supervisor status.

It works correctly to abort all the axes at the right time.

Problem:

When using MPIRecorderRecordTypeAXIS in mpiRecorderRecordConfig(), the
DAC output value was always 0.

Cause:

DAC output was assigned filter output and MechaWare firmware does not have filter.

Fix/Solution:

Check Mechaware or Standard firmware. If it is Mechaware firmware, DAC output is assigned for Motor commutation input.

Problem:

Map: symbol not found is returned when setting the map pointer as MPICapture.Data.State address and calling the mpiMapPtrToSymbol() function.

Cause:

Improper coding of the mpiMapPtrToSymbol() function.

Fix/Solution:

The mpiMapPtrToSymbol() function was corrected.

Description:

If installed in the default installation directory (C:\Program files), Motion Console and Motion Scope require administrator privileges to run. This is due to increased security measures by Microsoft in Windows 7 and above. Installing to an alternate directory will circumvent this requirement.

Description:

At the time of the release, the development of SimServer had not been completed. This feature is available as a standalone package and is not included in the MPI distributables.