800xA 5.0--CEX bus problem
Hi,
Can anyone help regarding two log files, I don't understand these message. In network I have 9 CPU PM864. In same time I lose these two PLCs from HMI. This happening every other day.
Thank you,
Can anyone help regarding two log files, I don't understand these message. In network I have 9 CPU PM864. In same time I lose these two PLCs from HMI. This happening every other day.
Thank you,
Asked 10 months ago
Answers
0
1. Two controllers with identical MAC-addresses exist in the control network, which
will cause network problem due to address conflict. For example a redundant CPU
(P and R) below with MAC addresses A and B respectively.
2. Primary and backup CPU have the same MAC-address and get synchronized, this
situation might occur after repeated circulation of CPU devices in the network. For
example a redundant CPU (P and R) below with MAC addresses A and B
respectively.
In such situations, printouts as below will occur in the controller log:
E 2006-11-26 13:25:38.929: NISPrimarySupFailed to send on CexBus, CexBus timeout
E 2006-11-26 13:25:46.554: NIS:Sup error send on cex bus
E 2006-11-26 13:25:48.565: NISPrimarySupFailed to send on CexBus, CexBus timeout
E 2006-11-26 13:25:56.157: NIS:Sup error send on cex bus
Preventive Procedures
The CPU with the described behaviour above can be identified by starting it up in
standalone mode (with a terminator in the RCU port). It will show its own native MAC
address which is different compared to the one showed when it was started up with an
RCU cable connected.
A method to minimize the risk for such problems is to make sure to always push the
"Restore Factory Settings" in the IP-config tool before assigning new IP-addresses to the
CPU and before connecting it in the new context. "Restore Factory Settings" will erase
previously cloned MAC addresses including the assigned (cloned) IP-addresses and keep
the native MAC address.
A method to completely avoid the problem is to always keep the TP830 bases in their
original places when moving CPU devices around in the network as both the native MAC
address and the clone are stored on the base.
Please contact your local ABB Support Engineer to fix your problem.
will cause network problem due to address conflict. For example a redundant CPU
(P and R) below with MAC addresses A and B respectively.
2. Primary and backup CPU have the same MAC-address and get synchronized, this
situation might occur after repeated circulation of CPU devices in the network. For
example a redundant CPU (P and R) below with MAC addresses A and B
respectively.
In such situations, printouts as below will occur in the controller log:
E 2006-11-26 13:25:38.929: NISPrimarySupFailed to send on CexBus, CexBus timeout
E 2006-11-26 13:25:46.554: NIS:Sup error send on cex bus
E 2006-11-26 13:25:48.565: NISPrimarySupFailed to send on CexBus, CexBus timeout
E 2006-11-26 13:25:56.157: NIS:Sup error send on cex bus
Preventive Procedures
The CPU with the described behaviour above can be identified by starting it up in
standalone mode (with a terminator in the RCU port). It will show its own native MAC
address which is different compared to the one showed when it was started up with an
RCU cable connected.
A method to minimize the risk for such problems is to make sure to always push the
"Restore Factory Settings" in the IP-config tool before assigning new IP-addresses to the
CPU and before connecting it in the new context. "Restore Factory Settings" will erase
previously cloned MAC addresses including the assigned (cloned) IP-addresses and keep
the native MAC address.
A method to completely avoid the problem is to always keep the TP830 bases in their
original places when moving CPU devices around in the network as both the native MAC
address and the clone are stored on the base.
Please contact your local ABB Support Engineer to fix your problem.
Add new comment