IAC communication time out with message:degraded sequence number diff
May I know what causes the following message on controller log:
IACInVariable::VerifySequenceNumber First Fault - degraded sequence number diff: 7200
This message occured when timeout on external IAC variable (between controllers).
This IAC consist of only 7 bools (simple data type).
The setting of the IN communication variables is as follow:
Unique ID: 180210101 and is unique on the entired network,
IP address: 172.16.80.180 i.e. source controller's IP
ISP values: mixture of true and false
Attribute: retain hidden,
Interval time: normal,
Expected SIL: same (between safety controller PM865)
Acknowledgement group: auto
Parameter on IAC MMS setting:
Interval time normal: 2000ms
Timeout normal: 6000ms
Application interval time (task time) containing the source variables is 900ms
System version:800xA Base S-FP 5.1.4-2 ver5.10.5632.29860
Thank you so much for your time!
Voted best answer
Sorry, no idea but I would guess the HI controller has detected some loss of IAC telegrams.
Ensure task tuning has been applied properly and with ample amounts of Task Offset to allow the controller to crunch some network data in/out before entering next 61131 task execution.
Lack of task offset will push communication ahead, possibly up to the 700ms limit (per 1000ms cycle).
With too much IAC, MMS and other network traffic going on and too little task offset the Ethernet chip will overflow the circular buffer holding received but not ”digested” network telegrams and report an Overrun. Disabling NETBIOS on Control Network computer NICs have helped in many cases.
This drives automatic resending of MMS TCP based telegrams but IAC run over the more lightweight UDP protocol, in which the data is lost and receiver need to wait for next transmission.
Check and compare the Remote System>Controller diagnosis>More>Network Information>Get result with other controllers. There are many counters available. Use Google to translate them, they are not invented by ABB, rather used in most network drivers of computer systems running Ethernet. Some are REALLY bad, eg Late Collision while others are perfectly OK to see, eg up to 5% collisions (put in relation to all sent telegrams) are OK on half duplex but not acceptable on full duplex (PM891).
Later in the network info there is a breakdown of how many telegrams the network filter in the controller has dropped (after flowing through and occupied the relatively small Ethernet ring buffer). Your NETBIOS should show up here; try removing traffic the filter is actively removing from the input queue to the processor. Less undesired traffic leave more room for what is important For the controller.
Using an NE870 as router instead of regular PC with RNRP opens up for a more stringent routing and filtering of what is allowed to enter the Control Network.
Gents, thank you for the comment and help. The root cause is found. It was due to duplicated MAC address in the control network.
From the control hardware manual 3BSE036351:
Reuse of CPU modules replaced from redundant configurations within the
same control network, might cause control network problems due to the MAC
and IP address handling. See MAC and IP Address Handling in Redundant
Configuration on page 49. Such reuse should not be fulfilled unless both the
replaced module and the module previously acting together with it in redundant
configuration are known to be restored from the previous mutual address swap.
It is recommended to set up an IP-config session and use the “Restore factory
settings” option subsequently followed by reassignment of the IP address or
assignment of a new IP address.
in order to avoid network problems while reusing previously used CPU
modules within the same plant:
• The stored swap addresses will be remembered until erased by an IP-config
session (Restore factory settings) or until started up as a backup CPU in new
context (in this case a new swap will take place).
• A CPU running in standalone mode (with RCU terminator fitted) will always
use its own native addresses.