AB DLR Network Issues

[kchishti]

Greetings Folks,
This is my first post after a long gap (almost 13 years) on this forum and i hope that i will get things fixed with your professional help and support.
I have three units being controlled with three independent PLC control. Each PLC is redundant (1756-L71) with its own Its (Point IO chassis and 1756 IO chassis). Each Unit PLC (UCP-X) is configured with two DLR networks. DLR network # 1 with blue dotted lines is connecting the redundant controller chassis with its IO chassis. The supervisor node for DLR # 1 network is the ETAP device. Each Unit PLC (UCP-X) has a secondary DLR network # 2 with green dotted lines which is connecting the three UCP panels (UCP A-B-C). The supervisor node of DLR # 2 network is one of the 1756-EN2TR devices in the redundant controller chassis of UCP-C.

The DLR networks are working fine however, i noticed excessive amount of errors and intermittent faults on DLR # 2 network. One of the EN2TR devices (inside the synched chassis of UCP-C) link 2 LED its solid green and it shows port 2 as half-duplex whereas all other EN2TR devices are full duplex. I understand that on DLR network, baud rates of all devices must be identical however i don’t know how to change that 1756-EN2TR baud rate to full duplex?

Screenshots for the topology and DLR tool topologies for both networks are attached herewith for your kind consideration.
Potential Problems:

DLR # 1 network - A lot of errors being faced on this network as well as when i go online with UCP-C LOGIX program, i noticed that UCP-B EN2TR is continuously going on fault (under the properties) and then clear by itself within short period of time. Is this due to the fact that the supervisor EN2TR port 2 is shown half duplex and the LINK 2 LED is solid green not flashing? How can i fix this issue?

DLR # 2 network - This network is more stable however as you can see from the DLR network topology the secondary ANETR adopter is crossed out and even in LINX i can’t access its Network Configuration. Further, the secondary ANETR adopter Network Status LED Is blinking green not solid green like the primary ANETR adopter. Also ETAP link 2 LED is solid green. How can i fix this problem?

 

[kchishti]

I would appreciate any feedback or pointers towards resolving the above mentioned two problems.

 

[Contr_Conn]

I don't have time now to dig any deeper, but I recall that 1715 adapters defaulted to 10/half, must be configured to "Autonegotiate" or 100/full.
They will not work correctly on DLR with 10/half.
Also, the secondary 1715 adapter does not respond to any CIP messages, so 191.130.5.6 with X is expected behavior.

 

[kchishti]

I don't have time now to dig any deeper, but I recall that 1715 adapters defaulted to 10/half, must be configured to "Autonegotiate" or 100/full.
They will not work correctly on DLR with 10/half.
Also, the secondary 1715 adapter does not respond to any CIP messages, so 191.130.5.6 with X is expected behavior.

Hi Contr_Conn, thanks for your quick response. All adaptors including 1715 are configured as auto-negotiate. Also, on DLR #2 network, the supervisor node (1756-EN2TR) is shown half duplex on its display (this may be an issue) even though it has configured as auto-negotiate.

 

[kchishti]

Greetings All,

I have done some more troubleshooting and found the following two observations;

1- on DLR network #2, the supervisor node (ENT2R on the secondary or backup chassis) has link 2 full duplex and full connectivity whereas link2 is half duplex and the liink2 LED is steady green. Is this due to the fact that the supervisor will block one port on the DLR network and use the other port for communication? Would appreciate any feedback?
2- the primary chassis is initiating a switchover (while there was apparently no reason for SW. All modules in primary was healthy) every now and then. This morning I observed this twice within the span of 4 hours. During switchover, the secondary chassis doesn’t accept it and the secondary controller reported “no project” for a time being until switchover failed. The primary remained primary and after the failed switchover attempt, the secondary synched again with primary. I would appreciate if anyone can provide some guidance on this issue?

Is there any way that I can capture logs from the system? I am running 1756-L71 with version V20.056 and redundancy module 1756-RM2.

Regards

 

[Contr_Conn]

For #1 - this is not normal, all links must be full duplex.
If you have one port forced duplex and the opposite end is set for Auto negotiation, then you will see similar duplex mismatch.
Until you correct #1, looking at #2 is pointless.
#2 - yes, you can extract logs using Configuration tool in RS Linx.

 

[kchishti]

For #1 - this is not normal, all links must be full duplex.
If you have one port forced duplex and the opposite end is set for Auto negotiation, then you will see similar duplex mismatch.
Until you correct #1, looking at #2 is pointless.
#2 - yes, you can extract logs using Configuration tool in RS Linx.

Thank you sir for your quick response. How would I make sure that the supervisor is full duplex using auto negotiation?
Which configuration tool? Can you provide the name please? I am using RSLinx 4.0. Once again thank you so much.

 

[Contr_Conn]

You need to check all ports on all modules to make sure Autonegotiate is set on all of them.
Tool called Redundancy Module Configuration Tool.
Right click on RM2 and select Module Configuration. If nothing there then you need to download and install it.

 

[kchishti]

You need to check all ports on all modules to make sure Autonegotiate is set on all of them.
Tool called Redundancy Module Configuration Tool.
Right click on RM2 and select Module Configuration. If nothing there then you need to download and install it.

Hello Sir,

I have gone on to check all ports and found all of the. Configured as auto negotiation and full duplex. However, the supervisor node link 2 was set as auto negotiation with half duplex speed. When I tried to force it to full duplex online it gave me an error and failed to set the speed. However, when I remove that module and inserted back in it did take full duplex but no auto negotiation. The port diagnostic counter still showed collisions, FCS errors, alignment errors. I am assuming that after some time when the DLR registered fault, the RM2 modules tried to switchover to secondary but because the supervisor node is in secondary chassis, it logged the DLR network fault right away and failed the switchover(although I couldn’t get any evidences of DLR failure).
For RMCT, I guess I have to use a firmware compatible version of the tool? System is currently running L71 with revision 20.056. I would appreciate if someone support to get the right version of RMCT. I believe I have to update RSLinx software as well which is currently running V4.0.

Regards
Khurram

 

[Contr_Conn]

You can't force speed duplex on one module only - FCS error and collisions is the direct result, set all device to Auto.
If still issue with Auto, then you have a faulty module of cable.
For RMCT, I don't remember version for 20.056, I think the latest will work for it.

 

[kchishti]

You can't force speed duplex on one module only - FCS error and collisions is the direct result, set all device to Auto.
If still issue with Auto, then you have a faulty module of cable.
For RMCT, I don't remember version for 20.056, I think the latest will work for it.

So module can be faulty without showing any visual signs? All LEDs on the enT2r modules are green. I will try to replace the cables connected the two ports of supervisor ENT2R module (which shows one of its ports as half duplex). If the problem persists, I would replace the supervisor ENT2R module. The spare ENT2R module is version 11.xx whereas the current module is at V 10.07. Do I have to flash the spare to 10.07 firmware? Or 11.xx will work just fine?

Also will try to look for Compatible version of RMCT module to get some insights during the switchover. Will report my feedback. Thanks a lot once again.
Regards