Release Note
MPI Library Version 04.03.16

Description:
Capcon iMx SQ Drive is available in this release.

How do I use this feature?:
Capcon iMx SQ Drive is available in this release with SQ Node Library.

Description:
SynqNet is now supported on Yaskawa SGDV series drives.

How do I use this feature?:
Yaskawa drives (SGDV, SGDV-MD4 and MD8) are all available with SynqNet.

Problem:

SqTopologySave often failed when a lot of high performance nodes were in Synqnet.

Cause:

This cause was in QMP flash capacity.

Fix/Solution:

QMP flash capacity was extended from version 916.

Problem:

In the mpiSynqNetPacketConfigGet/Set had a problem in 'compare depth' configuration.

Cause:

The mpi will create the unexpected useless packet of Compare when customer called mpiSynqNetPacketConfigSet. This cause is in MPI packet calculation bug.

Fix/Solution:

Packet calculation fixed.

Problem:

The MPI method sgdzBsEncoderConfigureCopy returns "Not Supported".

Cause:

The cause of the problem was bad logic.

Fix/Solution:

The logic was corrected and the method returns an MPIMessageOK.

Problem:

On a 64-bit Windows 7 machine, after running any MPI application, if the customer updates the driver (even to the same version) using the device manager, the system will crash with a Blue Screen (BSOD).

Cause:

The data structure for an ISR was not deallocated correctly.

Fix/Solution:

The data structure for holding ISR information was correctly deallocated. Therefore, the system does not crash when performing repeated driver updates.

Problem:

On a 64-bit Windows 7 machines, the device driver was continually serving the same interrupts from the controller and this caused the CPU time to increase

Cause:

Due to the compiler optimization, the device driver was not reading a register properly.

Fix/Solution:

The register was marked 'volatile' so the compiler did not optimize access to it. The CPU time did not increase without bounds.

Problem:

On 64-bit Windows 7, MotionConsole can report driver errors of the form "Win32 Device Error" when the controller is reset.

Cause:

The Device driver did not handle mapping and unmapping of the memory descriptors correctly.

Fix/Solution:

The mapping and unmapping of descriptors were corectly handled and MotionConsole does not report any errors when the controller is reset.

Problem:

MPI failed when trying to set the Multi-turn limit configuration for a Yaskawa SGDV-MD.

Cause:

The motor type SGDVMD was not configured.

Fix/Solution:

Additional configuration types for SGDVMD were added. MPI succeeds when setting the Multi-turn limit configuration for a Yaskawa SGDV-MD.

Problem:

A sequence command can take parameters for a Point-to-Point move. The move parameters can specify attributes (MPIMotionPointToPointAttributes). In a sequence command for a Point-To-Point move, these attributes were not correctly getting used by MPI.

Cause:

A bug in MPI made it refer to the wrong attributes pointer internally. Therefore, the attribute was not referred to correctly in some motion types.

Fix/Solution:

The correct pointer was used in the Sequencer Command code.

The Point-to-Point attributes are getting correctly used by MPI and the motion is correct.

Problem:

An MPI bug corrupted the value of Final Velocity in a Point-to-Point motion specification.

Cause:

When MPI made the sequence of the motion parameter set, a final sequence number was not increased. Therefore, final parameter set procedure will be overwritten by next sequence command.

Fix/Solution:

The final sequence number was increased and this allowed the setting of Final Velocity to stick.

When a Final Velocity is specified in a Point-to-Point motion using the Sequencer, it behaves correctly.

Problem:

Commution Detection for an SGDV drive fails.

Cause:

MPI did not support the method of a motor type of: SGDV.

Fix/Solution:

The code was changed to recognize the "SGDV" motor type.

Commution Detection for an SGDV drive succeeds.

Problem:

If a motor is configured to velocity mode, gearing is enabled, and the motor was enabling at the same time as MotionConsole was refreshed, MPI reports an error.

Cause:

MPI wasn't able to resolve the race condition.

Fix/Solution:

The race condition was handled and MotionConsole does not report spurious MPI errors in console when refreshed.

Problem:

The MPI for ScurveJerkPercent and ScurveJerk moves only validates the arguments: positon and velocity. Specifically, it does not validate the arguments: accelerationJerk, decelerationJerk and jerkPercent.

Cause:

Since the MPI does not validate the jerk arguments, it passes these values to the firmware which generates an inaccurate frame.

Fix/Solution:
MPI argument checking has been enhanced to include validation of the jerk parameters and if the MPI gets zero values (i.e. invalid values) for the jerk parameters, it retuns an error.

Problem:
If the parameter Acc/Dec is less than 20, the firmware calculates incorrect trajectory in the SCurveJerk algorithm.

Cause:

There is a cause is a mistake in the limitation value of the firmware code.

Fix/Solution:
This limitation value was fixed and will return a profile error if Acc/Dec is less than 1e-6.

Problem:
mpiCompareLoadStartStopPoints function had a memory leak.

Cause:

This function did not release resources it acquired.

Fix/Solution:
The funcition's resources were deallocated and no longer has a memory leak.

Problem:
The sqNodeFlash reports an error if the FPGA or firmware is downloaded.

Cause:

A prior bugfix (MPI2658) was incorreclty implemented and its side effect was that the SynqNet network was not in SYNQ state causing this error.

Fix/Solution:
Tthe code was changed to sidestep the side effect of MPI2658 when SynqNet is not in SYNQ state.

Problem:
Dumpevents occasionally does not print out all event data.

Cause

DumpEvents was not properly reading the circular event buffer when new events overflow and are queued at the beginning of the buffer.

Fix/Solution:
DumpEvents circular buffer handling was fixed and now prints out all data at all times.

Problem:
There were no output measurement data in the User Buffer. Therefore, the Bode tool was not receiving any data.

Cause:

1. There is no download method in the mechaware loader.
2. The firmware was using them as a floats and should be doubles.

Fix/Solution:
A download method was added to MwLoader.c and ModeUtils.c

Problem:
For the PIV_GT block, when all gains are set to 0 and 1 is entered for Kvff, it commands a move of 1 rev/s and the motor runs away.

Cause:

Calculation of Kvff term was incorrect.

There was the following equation in the FF term:

Output += cv * Kvff;

It is not required since PIV has already calculated Vel FF.

Fix/Solution:
The equation was changed to the correct equation.

Problem:
When the motor gear is saved and an ABS motor is minus some distance, the initial position of an encoder may have an error.

Cause:

The cause of the problem is the firmware ratio module. The module cannot handle a large delta.

Fix/Solution:
The MPI was corrected and will recalculate the initial value.

Problem:
When saving the topology in flash and CaptureConfigSet function is called afterwards, the function returns an error.

Cause:

The topology preservation function saves the Arming status of Capture. Therefore, Capture always enters the state of Arming, and the setting of Capture is obstructed.

Fix/Solution:
The MPI clears CaptureStatus before flash.

Problem:
MPI checks the wrong error code after pole detection of SGDZBS.

Cause:

Fix/Solution:
Correct error code is now checked.

Problem:
mpiControlEventNotifyGet had a problem in object lock operation.

Cause:
The method call to Control object LockTake twice, however it will release Lock only once.
This generates the mismatch of the lock.

Fix/Solution:

Problem:
When axes are idle the position will drift when the disable action is set to cmd=actual. This occurs with various rmbs.

Cause:
The problem is caused by the fact that amp active was improperly supported by various rmbs (gms, soonhan, and Yaskawa). Also it is possible to set the amp disable action to cmd=actual for stepper axes.

Fix/Solution:
The MPI was modified so that these rmb's are not identified as supporting amp active. Also it is not possible to set the amp disable action to cmd=actual for stepper motors.

There is no drift when axes are idle for these rmb's when the amp disable action is set to cmd=actual. In addition no drift will occur for stepper axes because the amp disable action cannot be set to cmd=actual for stepper axes.

Problem:
Tolerance configuration is lost after reset when topology saved. Therefore, the tolerance status is unstable because firmware compares the position tolerance with zero.

Cause:
The firmware compares the tolerance with actual position and axisData.Tolerance. Beccuase MPI did not backup the axisData values, axisData.Tolerance will be zero after the reset when the topology is saved.

Fix/Solution:
The firmware will copy the tolerance data from axisConfig to axisData when restarted. When Topology is preserved, this operation is effective.

Problem:
The mpiAxisOriginSet is called when sample counter = 0. Read command or actual position immediately. The origin value is not accurately reflected.

Cause:
Wait is determined by whether the samplecounter value in the axis structure is 0 or not 0.

Fix/Solution:
If the function needs to wait, set sample counter value and wait flag.

Problem:
In prior versions of MPI 04.xx UserVersion and UserLabel do not save to flash.

Cause:
This feature was not ported over from MPI 03.xx.

Fix/Solution:
The functionality was ported from MPI 03.xx to MPI 04.03.06.

Affects to Application Code:
This feature is now supported in MPI 04.03.06. UserVersion and UserLabel will save to flash as intended.

Problem:
In prior versions of MPI 04.xx UserBuffer and VolatileBuffer do not save to flash.

Cause:
This feature was not ported over from MPI 03.xx.

Fix/Solution:
The functionality was ported from MPI 03.xx to MPI 04.03.06.

Affects to Application Code:
This feature is now supported in MPI 04.03.06. UserBuffer and VolatileBuffer will save to flash as intended.

Problem:
For large systems with lots of configuration data, the MPI improperly calculates the total amount of flash required to save the configuration. Additionally, the ZMP controller did not have enough flash to contain all of this data, but this error was not reported correctly.

Cause:
This error is caused by exceeding the flash memory capacity. On systems with lots of motors, the dynamic memory size is larger than the flash memory on the ZMP, causing sqTopologySave to fail.

Fix/Solution:
After correcting the memory calculation, we reviewed and optimized the objects being saved; removing some unnecessary data structures from the objects. This gives save to flash a much larger memory buffer, preventing errors on larger systems.

Affects to Application Code:
sqTopologySave(…)has been tested on systems having 64 motors with no capacity problems.

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:

QMP controller hangs after meiReset with 64 nodes attached.

Problem:

The version may hang on a ZMP if the network is not cyclic.

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