Structured text to reset AC800M ports CN1, CN2 and COM3
Good day,
Is there a way of writing structured text to reset the CN1, CN2 and COM3 port without a cold or init download to the controller?
These controllers are in a remote location where sometimes there are power failures, which introduce network loops and the ports become blocked due to the protection on the controller.
We are unable to resolve the network issues as the customer has control of the network, but its something they are working on resolving. If there's a way in the meanwhile to detect this event and perform a reset via structured text a minute or two later, it would help.
Any suggestions?
Is there a way of writing structured text to reset the CN1, CN2 and COM3 port without a cold or init download to the controller?
These controllers are in a remote location where sometimes there are power failures, which introduce network loops and the ports become blocked due to the protection on the controller.
We are unable to resolve the network issues as the customer has control of the network, but its something they are working on resolving. If there's a way in the meanwhile to detect this event and perform a reset via structured text a minute or two later, it would help.
Any suggestions?
Asked 8 months ago
Answers
0
Hi,
You can do reset of communication protocol, connected / using these ports.
You can create a logic for temporary set parameter En_C=false and after a while En_C=true of the corresponding connect blocks, using the ports (MBConnect, MMSConnect etc).
The failure of communication you can detect usually by ERR output of the corresponding read or write block.
You can do reset of communication protocol, connected / using these ports.
You can create a logic for temporary set parameter En_C=false and after a while En_C=true of the corresponding connect blocks, using the ports (MBConnect, MMSConnect etc).
The failure of communication you can detect usually by ERR output of the corresponding read or write block.
0
A disabled port can be enabled via the RNRP Fault Tracer. The Fault Tracer can also be used to find which nodes that have detected a network loop. If the port is not enabled manually it will be automatically enabled 1 hour after it was disabled. If there is still a network loop on the network the port will be closed again.
For a more detailed analysis of nodes using RNRP there is a tool called RNRP Fault Tracer. It is started with a right double-click on the RNRP icon in the system tray or at Start > All Programs > ABB Industrial IT 800xA > System > Network > RNRP Utility.
Unblock blocked interfaces :7
For a more detailed analysis of nodes using RNRP there is a tool called RNRP Fault Tracer. It is started with a right double-click on the RNRP icon in the system tray or at Start > All Programs > ABB Industrial IT 800xA > System > Network > RNRP Utility.
Unblock blocked interfaces :7
0
RNRP in controller firmware prior to version 5.1.1-3 may leave one port permanently blocked after experiencing a dual network storm. Upgrade to firmware version 5.1.1-3 or later is recommended.
A dual storm bring signs of incorrect network topology for RNRP, e.g. by having primary and secondary paths in same VLAN trunk, copper or fiber link, or intertwined (connected) in some switch, router, etc. The recommended design is supplying complete different set of power, cabling, fibers, hardware, etc. for the secondary network. Two totally independent networks will likely never result in a dual storm. The use of STP or RSTP may cause flooding and should thus be avoided. See this post, or check in the new System 800xA 6.1 Network Design User's Guide.
A workaround without having to reset the controller is to download a parameter change to RNRP; e.g. temporarily raise the Max No Of Remote Areas setting by 1. Then reduce it with a subsequent download.
NOTE: This workaround/download must be made from a Control Builder M station connected on the same subnetwork/RNRP Area. A routed download (e.g. from station on the client/server network) risk being interrupted when RNRP restart in controller and the route is temporarily lost before download is completed.
A dual storm bring signs of incorrect network topology for RNRP, e.g. by having primary and secondary paths in same VLAN trunk, copper or fiber link, or intertwined (connected) in some switch, router, etc. The recommended design is supplying complete different set of power, cabling, fibers, hardware, etc. for the secondary network. Two totally independent networks will likely never result in a dual storm. The use of STP or RSTP may cause flooding and should thus be avoided. See this post, or check in the new System 800xA 6.1 Network Design User's Guide.
A workaround without having to reset the controller is to download a parameter change to RNRP; e.g. temporarily raise the Max No Of Remote Areas setting by 1. Then reduce it with a subsequent download.
NOTE: This workaround/download must be made from a Control Builder M station connected on the same subnetwork/RNRP Area. A routed download (e.g. from station on the client/server network) risk being interrupted when RNRP restart in controller and the route is temporarily lost before download is completed.
1
> "sometimes there are power failures, which introduce network loops"
This should NOT happen. In the event of a power failure, RNRP should swap to an available REDUNDANT ethernet route. There should not be a situation where the primary network traffic can end up on the secondary network equipment.
If you hardware is not truly redundant, then it would be better to configure RNRP to match your actual network configuration and run a non-redundant connection path.
Unfortunately, it is possible that a customer may not be capable of solving this issue without significant guidance from you. But the solution really needs to be to "fix the network", not "hide the problem".
This should NOT happen. In the event of a power failure, RNRP should swap to an available REDUNDANT ethernet route. There should not be a situation where the primary network traffic can end up on the secondary network equipment.
If you hardware is not truly redundant, then it would be better to configure RNRP to match your actual network configuration and run a non-redundant connection path.
Unfortunately, it is possible that a customer may not be capable of solving this issue without significant guidance from you. But the solution really needs to be to "fix the network", not "hide the problem".
Answered 8 months ago
Add new comment