Release Note
MPI Library Version 04.04.11

Problem:

mpiUserLimitEnableSet will report a spurious timeout error if customer calls mpiUserLimitConfigSet when enable=true, followed quickly by mpiUserLimitEnable (argument=false).

Cause:

The timeout check was faulty in this situation.

Fix/Solution:

This logic for the check for timeout was fixed.

Problem:

A timeout error is returned when downloading new Firmware to a QMP (Flash.exe). This issue is only exhibited on QMP boards that have the newer MT28EW256ABA flash chip. This issue is related only to flash programming only and not normal operation.

Cause:

The flash timeout was traced to a software bug introduced in MPI 04.03.18 and MPI 04.04.03 – 04.04.08.

Fix/Solution:

Upgrade to MPI 4.04.09 or later.

Problem:

The ZMP command position may drift for SqDC4 drives. This may occur if the SqDC4 drive has some load while holding position. The rate of position drift depends on the motor and load.

Cause:

The solution was a change in the MPI code so that the ZMP PID will ignore the AmpActive status from SqDC4. The MPIMotorDedicatedInAMP_ACTIVE bit for SqDC4 SqNode library is NOT set, which will cause the ZMP to ignore the AmpActive status.

Fix/Solution:

The position drift occurs because the SqDC4 toggles the AmpActive state on/off/on even though the ZMP continuously requests AmpEnable. When AmpActive toggles off, the ZMP's PID is momentarily disabled and the "command = actual" disable feature may allow ZMP command position to drift. Note this use of the AmpActive was introduced in MPI 2628 "AKD-SQ Reduce Position Jump on Amp Enable" (MPI 04.03.05).

With the updated MPI, the ZMP will instead use the AmpEnable state to control disable behavior of ZMP PID.

Problem:

In the previous specification, the controller init would called motor config set if the motor had a gear ratio under certain conditions. This is for re-calculation of the gear position because if contoller initialization was done first time after power on, and gear ratio has been flashed, the intial position might be wrong position if resolution is very high and it had ABS initial position. That original cause was overflow of firmware register.

Cause:

However, the firmware overflow issue was fixed in MP2728 already. Therefore motor re-initialization process was no longer useful. And this re-initial process might become an unexpected operatioin if customer configures the controller with unique motor link. (This case is posted by MPI2765)

Fix/Solution:

The motor re-configuration was removed from controller initial process. MPI and controller should be correct operation in any case.

Problem:

If customer configured unique axis-motor link (like an Axis0 referred Motor1 encoder as feedback), and linked motor has been configured with a gear ratio, Axis0 encoder will jump if controller is initialized.

This problem occured when Motion Console was refreshed because it initialized the controller.

Cause:

This cause is in motor re-configuration in controller initialization process. In expected operation, MPI will skip this motor configuraton if the motor enabled. However, this skip condition was incomplete and only the same axis and motor numbers were checked. Therefore, if customer configured unique link between axis and motor, the encoder position jumped.

Fix/Solution:

The cause of this route is reconfiguration, but this feature was no longer needed.
(See MPI2766). Because we removed re-configuration from controller initialization process, encoder jump issue is also fixed now.

Problem:

Motion will unexpected done event if axis list has been changed in another MS.

If customer is using multi thread or multi process application, and if these program are running on paralell that one task changed axis map configuration and other task called motion start and wait an event, the FW might notifed the unexpected done event.

Cause:

This cause is in axis map change process. So far, MPI could changed the axis map in anytime.
But FW process is refering mapped axis count for the loop for MS status control internaly. Therefore if MPI changed axis list to smaller than previous during MS processing of FW, FW refered to unexpected axis list as '0'. This was cause of unexpected event notified.

Fix/Solution:

For axis map control, we changed the MPI to call the MPIActionMAP internally. In new MPI, FW will set the axis count to ZERO by MPIActionMAP first. And if FW conpleted that process, MPI will set the new axis map and new axis count. This process allows you to synchronize between MPI and FW so you can fix unexpected events.

Problem:

The mpiMotionMemoryGet and mpiFilterMemoryGet/Set did not work correctly.

Cause:

These function's address validation was broken and it would return the MPIMessageARG_INVALID unpredictably.

Fix/Solution:

Now the functions sould be work collectly.

Problem:

In Windows 64 OS, customer could not open the drive map with sqDriveConfig tool.

Cause:

This cause is in MPI source code. So far, sqDriveConfig could be run on WIn32 only, not in Win64. This was the bug.

Fix/Solution:

Now, we can run this tool on Win64 too.

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.