Problem/Cause:
SynqNet initialization errors intermittently occurred on ZMP-SynqNet systems with one or more nodes. When the problem occurred, all nodes on the system failed to enter cyclic operation. It was caused by a clock domain problem in the RinconZ timer module. Although this latent problem existed in RinconZ (build 244) and all prior versions, it was masked in prior MPI releases due to different timing schedules. This problem does not exist on XMP-SynqNet systems where both the source and destination of the signal exist in the same clock domain.

Fix/Solution:
FPGA code was corrected in Rincon Build 245 and later versions to eliminate the clock domain problem on ZMP-SynqNet systems.

Description:
In order to support the new SynqNet HotReplace feature, improvements were made to the cable length discovery routine. A new module, testEcho, was added for support.

Description:
Support was added for the new SynqNet HotReplace feature. The packet types TEST, CHANGE, REQUEST_RESTART, and RESET_COMPLETE are now blocked in hardware under certain conditions.

Problem/Cause:
In Rincon version 231 and 232, SynqNet Fault Recovery may fail. This was caused by an invalid cable length discovered on the last cable after an "idle cable" check is performed. The problem could have only occurred if the MPI idle cable function was called just prior to a SynqNet initialization call. This problem could not have occurred after a normal controller reset. The invalid cable length does not have an effect unless fault recovery forced SynqNet to switch to the idle cable (last cable) in the ring. If this occurred, one or more nodes may have declared sqPllFail and shut down. This problem was a combination of both hardware and software bugs. The hardware bug existed in Rincon version 231 and 232 only. The software bug existed in MPI 03.03.Beta4 and prior versions.

Fix/Solution:
The problem has been fixed in software version 03.03.Beta5 and later. The problem was fixed for the hardware in Rincon version 233 and later. Note Rincon 233 or later is recommended for MPI versions between 03.03.00 and 20031222.

Problem/Cause:
The TEST packet status was not reported correctly in Rincon version 214 and later. This caused the MPI "idle cable" check to fail for cables connected to the controller. However, fault recovery and all other SynqNet functions still operated correctly. This issue affected MPI 20031015 and later.

Fix/Solution:
The FPGA code as been corrected in Rincon version 232 and later. No software changes are required.

Description:
Added a new bit ChangePktEnable to the Rincon RxDMAControl register. This is useful for testing SynqNet.

Description:
The Rx Prop Delay counter can now measure the Nth receive packet. This is useful for special situations.

Description:
Improved the RxMiiBuffer module to correctly handle simultaneous packets on both IN port and OUT port. This feature is required for reliable dual-string discovery.

Description:
Added a "Promiscuous" feature to the Rincon receive state machine. This helps with certain discovery situations.

Description:
Added new bit “Valid Status” to the Receive Control Block "Status" word. This bit may be useful in certain Asynch operations.

Description:
Added two bits to the Rx DMA Control register to disable packet reception on either IN port or OUT port. This feaure helps with the discovery of dual-string networks. These bits default to 0 (enabled) for backwards compatibility. No software changes are required.

Description:
Modified the RinconZ timer control logic to provide a watchdog shutdown if ZMP firmware fails (RinconZ will stop transmitting if the firmware fails to rearm the RinconZ on each cycle, which will then cause the nodes to declare ioAbort and put the outputs into safe states). The previous control bit "External Trigger" was replaced by a bit named "Single Trigger." No software changes are required (although ZMP firmware must be changed to take advantage of the new feature).

Description:
The rxOnOutPort bit may not be valid in the Receive Control Block status word. This does not affect basic operation, but may cause problems with idle cable detection after fault recovery (only if the system has more than 16 nodes). This problem depends on internal FPGA routing delays, and potentially exists in all builds prior version 224. Currently, the problem has only been observed in 223_A301.fpg.

Description:
XMP and eXMP controllers using FPGA versions 221 and 222 always discover cable lengths of 0. The MPI schedule will allow for actual cable lengths between 0 and 10 meters, but longer cables may not work reliably. ZMP controllers are not affected by this bug.

Description:
When fault recovery occurs on a network with 9 or more nodes, excessive upstream packet error counts may be seen for all nodes, or some nodes may fail to recover. The errors occured if a CHANGE packet arrived while the receive FIFO was reset at the begining of the next controller cycle. This problem exists in all FPGAs prior to version 222.

Description:
A debounce filter has been added to all 6 opto inputs of the XMP and ZMP controller designs. The filter delays input changes 140 uS +/– 20 µS, with the delay restarting if the input bounces back to the previous value.

Description:
ZMP controllers may fail network initialization. Typically, the application (Motion Console, reset, etc.) will never complete initialization. For MPI releases prior to 03.01.00, the application halts and never reports an error. The program can be aborted successfully in some cases, while others require a reboot to fully recover. Occasionally, the host computer may hang. For MPI releases 03.01.00 and later, the application will report an error. This problem exits on all ZMP controllers prior to FPGA version 221. XMP controllers are not affected.