Hi,
We are having 10 Controllers (MX - 11.3.1) , 10 Operator stations and 4 Application stations in DeltaV network having smart deltav switches (RM100).
All controllers, operator stations and applications stations generate random events of
"Switching to primary ACN network 'controller name/operator station name/application station name' " or "Switching to secondary ACN network ''controller name/operator station name/application station name".
e.g. Switching to primary ACN network ES.
After some seconds it will generate another event of
e.g. Switching to secondary ACN network ES.
This kind of events keeps on generating for all controllers, operator stations and application stations,
Pls suggest some solution.
For ready reference i have attached photo of events getting generated.
.
Niklas Flykt
Klinkmann Oy
Key Account Manager safety products
nikfly@gmail.com
In reply to jwiersma:
So what causes an ACN switch over? DeltaV uses a redundant network, two completely separate networks. All the data management on these networks is handled by the end devices, so the networks do not make any decision as to which is used or not. Each DeltaV node communicates to other nodes using Unicast messages with the UDP transport protocol. A UDP packet is highly efficient. DeltaV communication layer takes care of confirming data is received and has timeouts built in for retries. By preference, all DeltaV "process data" uses the Primary network. Data is sent to each destination in separate packets. When a packet is sent, a response is expected. If a response is not received within the timeout period, the parameter values are resent (the latest available value). After several retries, if no confirmation is received, the network between that node and the destination is marked bad and the packet is sent on the secondary. THis is called an ACN Switchover. The source node does not know how or why the packet is not confirmed, just that it is not. So, if you disconnect the primary cable from a console, all nodes sending data to that console will experience an ACN Switchover to the Secondary. Diagnostic messages are still attempted to the console on the primary so that when it returns, an ACN switchover to the Primary will occur. If an intermediary switch is turned off, all traffic through the switch will stop and any affected nodes will report an ACN switchover between it and its destinations. As you can see, one event can generate a significant number of ACN Switchovers. If this point of failure is intermittent, say a bad cable, improperly seated connector, bad Port on a switch, bad NIC in a computer, and traffic is intermittently getting through, the ACN messages can toggle. If it is a hard failure, you will get the switchover to the secondary and it will stay there till the problem is addressed. To isolate the problem, you can look to see if there is a common device involved. One device has lost connection on the Primary to all others, and all others have lost connection to one device. This will point to that device's primary port, network cable or Smartswitch Port. If the Switch shows issues on that port, it could be the switch, and changing ports can confirm this. If there are multiple devices that lose connection to all devices, one has to look for a common point in the network that sees all affected traffic. Some say that a normal healthy DeltaV network will still see some ACN switchover events and that a few events per day is of no concern. But every ACN switch over is the result of a failure to receive confirmation of receipt of a DeltaV packet, three successive times resulting in a time out and switchover. Early on when DeltaV used hubs and common collision domains, this was more likely as a 10 MB half duplex network became saturated. Today, all Smart Switches provide a separate full duplex connect to each controller and IO card, virtually eliminating collisions. 100 MB bandwidth at full duplex eliminates network pinch points. What is left is either corrupted data packets due to EMI noise, damaged cables, bad connections, bad network ports, high dB loss on fiber or bad NIC cards at the devices, or a software issue that prevents a device from responding. Other normal causes of ACN messages are activities such as rebooting a console, or cycling power on a switch. If these events occur, then the ACN messages are expected and can be ignored. The system will stabilize once the nodes are restored. In this case, sorting the Event Chronicle messages by Source device, you are able to determine if there is one common device or a common network point. If a cable is disconnected, and ACN messages stop because of the hard fault, it is likely that cable, and restoring connection with a good cable should result in one last ACN flurry as things switch back to Primary. Using the Smart Switch Command console, confirm that the switches involved are reporting any error counts, such as bad packets or other. Remember, if the packet is corrupt, it cannot be delivered and a confirmation is impossible. If the Confirmation is corrupt, it cannot get back to the source. If a console has a cyber security threat that is disrupting network traffic, this too could result in lost confirmation packets. The latest Smart Switch firmware limits broadcast and multicast storms, but the affected Computer may still have issues. Hope this is useful information.
Andre Dicaire
In reply to Andre Dicaire:
In reply to Maria Portillo:
In reply to Alexandre Peixoto:
I have the same issue with ACN switching over between primary and secondary then I/O failure of remote CHARMs for about 0.001 second then recovered. Laterly I’ve found that one of my Emerson Smart switch in Primary network is commissioned but showed red cross in DeltaV Smart Switch Command Center. I’ve check LED on this switch they are running and healthy. I’ve trìed to use telnet to login but don’t know the user name and password. My question is what happen with my smart switch? how i can fix it? Is it possible that ACN switching over causing remote CHARM I/O failure alarm. I’m using DeltaV v. 13.3.1
Thank you in advance.
In reply to Jitomit: