.

Important Things to Know

Release Type
MPI Version
Release Date
Production Release
03.04.00
16Aug2006

Introduction

This release contains several new features since the 03.03.xx series:

 

For information about MEI's software life cycle policy and release types, see the Software Life Cycle Policy and MPI Release Types. To learn about the MPI version numbering scheme, see MPI Version Numbering for details.

SynqNet HotReplace

The SynqNet HotReplace feature allows one or more consecutive nodes to be shut down, serviced, and then reattached to the system without affecting the operation of the other nodes. This feature is especially useful for modular systems where modules are occasionally taken offline for regular maintenance or replacement.

SynqNet HotReplace does not allow changes to the original topology. Adding, removing, or changing nodes is not supported by HotReplace. Replacement nodes must have the same runtime FPGA version. Replacement cables must be the same length within +/- 1 meter. Any topology change requires a full network re-initialization. During HotReplace, network fault recovery is not supported.

For more information, see SynqNet HotReplace.

SynqNet HotReplace requires all nodes to have a runtime FPGA version 400 (or higher).

 

Position Resolution Extended

The controller’s command and feedback position registers have been extended from 32-bits to 64-bits. This change was made to support machines with higher resolution feedback devices and axes with greater than 32-bit travel.

The MPI uses “double” data type for position values. Double precision variables are limited to 52-bits for the mantissa and 1 bit for sign, which allows a range between 1.7E-308 to 1.7E+308. The MPI will automatically convert its double position to the controller’s 64-bit integer position. If the controller’s position is beyond +/- 52-bits, the MPI’s double position data will have precision loss in the least significant bit(s). Likewise, if the user specifies a double position value beyond 52-bits, the data will have precision loss in the least significant bit(s). The MPI uses doubles for backwards compatibility.

To guarantee atomic 64-bit position read/writes the MPI uses a handshake between the host and controller. This impacts the performance of methods that read/write the command, actual, and origin positions.

The XMP-Series and ZMP-Series controllers use different byte and word ordering. The MPI automatically handles these conversions for 32-bit long data types and double data types. If an application directly accesses controller memory addresses or data values for 64-bit entities, use meiPlatformHostAddress64to32(...) to acquire the correct word address. For more details, see the Release Notes.

When upgrading from a previous MPI version, modifications to application code may be required. The programming interface has changed for the following structures:

 
MPICompensatorRange
MEIAxisConfig MEIMotorEncoder MPIMotorEventTrigger MEIMotorEventConfig MEIXmpLimitData
MEIEventStatusInfo MEIRecorderRecordAxis MEIRecorderRecordFilter

Gantry configurations (Gantry.c sample application) have changed.

For more information, see the Release Notes.

 

Cable Length Discovery

The SynqNet network cable length discovery implementation has been improved in the MPI version 03.04.00 and runtime FPGA version 400 (and later). In previous versions, the cable length was derived during network initialization by measuring the packet time delay from the controller to a node, and back to the controller.

The new cable length discovery improves the measurement accuracy to +/- 5 meters. This improvement does not require any changes to the user’s application code.

For more information, see SynqNet Cable Length.

 

New Node FPGAs


The 03.04.00 release includes new SynqNet Node FPGA Runtime images, version 400. These images contain support for the new SynqNet features (HotReplace and Cable Length Discovery) and bug fixes. Due to the new SynqNet features, the 400 FPGAs are NOT backwards compatible with previous MPI Software Releases (03.03.xx or earlier), nor are previous FPGAs (3xx or earlier) compatible with the 03.04.xx MPI. The MPI automatically checks the FPGA version compatibility. If the FPGA is NOT compatible, the MPI will return an error:

 
ERROR 0x1a34: 
SynqNet: node MAC version mismatch - network in asynq mode :: Node 0 : Version 0x250 : Less than Minimum Version 0x300

SynqNet cyclic operation is NOT allowed until compatible FPGAs are downloaded to all the nodes.

For more information, see the FPGA Release Notes for 03.04.00 for more details.

WARNING! Older revisions of the Kollmorgen CD drive were manufactured with version 103 boot and runtime FPGAs. The 103 boot and runtime FPGAs do NOT support dual-string topology discovery via the controller’s IN port. There are two failure symptoms:

 
  1. If you use an older CD drive with 103 runtime FPGA, use MPI 03.03 (or later), and the topology is dual-string, the node will not be discovered.

  2. If you use an older CD drive with 103 boot FPGA (20C or later runtime FPGA), use MPI 03.04 (or later), and the topology is dual-string, the node will be discovered, but the runtime FPGA download will fail.

To recover from these cases, you will need to make sure the CD drive is connected to the controller’s OUT port and download the runtime FPGA included in the MPI release. After the runtime FPGA is loaded, the drive can be operated from the controller’s IN port.

WARNING! If you use a SynqNet Node with 20C BOOT FPGA (or older) with MPI 03.04 (or later) and the topology is dual-string, the node will be discovered. However, the runtime FPGA download will fail.

To recover from this case, make sure the Node is connected to the controller’s OUT port and download the runtime FPGA included in the MPI release. After the runtime FPGA is loaded, the Node can be operated from the controller’s IN port.


SynqNet Demand Modes

SynqNet now supports Torque and Velocity demand modes. The demand mode determines the size and type of control signal between the controller and the drive. In the future, SynqNet will also support Position demand mode. The demand mode is configurable, but it does not support on-the-fly demand mode switching while the amplifier is enabled.

During SynqNet network initialization, the nodes are discovered and the demand mode is automatically set to a default, based on the particular drive model. The number of 16-bit demand fields (1, 2, or 3) per motor are configured and connected to the controller’s filter (closed-loop servo algorithm). The default is the recommended mode, but the user can change the demand mode using mpiMotorConfigGet/ Set(...).

Not all demand modes will be supported by each drive. RMBs and analog drives will only support ANALOG and those with two DACs per axis will support ANALOG_DUAL_DAC. Drives that support a drive processor interface will support TORQUE and those that have velocity loops, also support VELOCITY as well (Kollmorgen S200, S300, S600, and S1800).

Due to legacy analog controllers, the MPIControlConfig structure contains counts for the DACs and the Aux DACs. The number of DACs and Aux DACs were configurable by the user, so the number of physical analog outputs on an analog controller could be utilized for motor control, sinusoidal commutation, or other purposes.

In SynqNet systems, the controller DAC count and Aux DAC count are not necessary. Because the MPI is smart enough to configure the appropriate number of demand fields, based on the network discovery and motor count, the cmdDacCount and auxDacCount have been removed from the MPIControlConfig structure. The demand equivalent of the DAC count is automatically set to the control’s motorCount. To upgrade application code from previous versions, set the motorCount equal (or greater) to the previous cmdDacCount.

 
OLD
MPIControlConfig.cmdDacCount
NEW
MPIControlConfig.motorCount

Previously, the configured the number of Aux DACs per controller. The MEIMotorConfig.demandMode configures the demand mode. For RMBs, set the motor’s demand mode to either ANALOG (for one DAC) or ANALOG_DUAL_DAC (for DAC + Aux DAC). For example, if auxDacCount = 4, configure the demandMode = MEIMotorDemandModeANALOG_DUAL_DAC for motors 0-3.

 
OLD
MPIControlConfig.auxDacCount
NEW
MEIMotorConfig.demandMode =
MEIMotorDemandModeANALOG; /* Single DAC per motor */
OR
MEIMotorDemandModeANALOG_DUAL_DAC; /* Two DACs per motor */

For reduced controller load, set demandMode = MEIMotorDemandModeANALOG_DUAL_DAC ONLY for the motors that actually use the Aux DACs.

 

SynqNet Packet Schedule Improvements

The SynqNet packet schedule algorithm has several improvements. For 16 kHz drives, the new packet schedule algorithm will have the identical control latency times to version 03.03.xx. For drive update rates other than 16 kHz and for non-periodic nodes (RMBs), control latency might be different.

The following changes were implemented:

 
  1. Multiple drive period support
    In 03.03.00 (and older) all schedule calculations were based on 16 kHz drive update rates. The schedule calculations for each node are now independently optimized based on each drive’s update rate. Thus, for the following drives, the control latency will now be optimized, based on an integer multiple of the drive period:
         Glentek Omega – 24 kHz (41.667 microsecond)
         Panasonic Minas B – 6 kHz (166.67 microsecond)
         Sanyo Denki Q – 8 kHz (125 microsecond)


  2. Non-periodic nodes (RMBs) no longer use 16 kHz for calculations
    In 03.03.00 (and older) all schedule calculations were based on 16 kHz drive update rates. The schedule calculations for RMBs (MEI, Trust Automation, Soonhan, etc.) are now independently optimized based on the node’s 25MHz clock. Thus, the control latency will now be optimized, based on an integer multiple of the clock period (40 nanoseconds).

  3. Minimum and maximum latency configurations per node
    A minimum and maximum latency configuration limit, MEISqNodeConfigControlLatency was added. This allows the user to force a minimum latency for backwards compatibility or to generate an error if the maximum latency is exceeded during network initialization.

Whenever your SynqNet system configuration is changed or MPI software is upgraded, you should verify the control latency. SynqNet schedules adapt to hardware changes (controller type, number of nodes, node types, topology, and cable length). Future software releases may have improvements to the schedule algorithms. To ensure hardware and/or software changes, do not change the control loop behavior; verify that the overall control latency remains identical.

WARNING!
If the control latency is significantly different, it may affect the closed-loop control algorithm response. You may need to re-tune the servo-loop parameters.

For more information, see SynqNet Timing Values and SynqNet Control Latency.

To view the SynqNet timing values, see the SqTiming1.c sample application.

 

New SynqNet Drives

SynqNet support has been added for the following Kollmorgen drives:

 
 

 

S200 Drive Position Resolution Change

The Kollmorgen S200 drive position resolution has increased from 16-bits multi-turn and 16-bits per rev, to 8-bits multi-turn and 24-bits per rev. Thus, the position resolution has increased from 65,536 to 16,777,216 counts per revolution.

WARNING! Due to the increase in position resolution, previous closed-loop control algorithm parameters (Filter Object or Mechaware) will NOT be compatible with MPI version 03.04.xx and runtime FPGA version 400 (or later). Using previous parameters will cause unstable and unsafe servo operation. You must re-tune the servo-loops.
DO NOT USE PREVIOUS CLOSED-LOOP TUNING PARAMETERS!

 


 

       Legal Notice  |  Tech Email  |  Feedback
      
Copyright ©
2001-2010 Motion Engineering