Emerson Exchange 365

• Not Answered

Redundant Standby Controller Network Communication Status in DeltaV Diagnostics

Hi All!

I Have a query regarding Redundant Standby Controller Network Communication.

I am unable to ping to the Secondary connection of one of the Redundant Standby Controller in the DeltaV system (There is no comms and the request times out)

There is some issue with the connection I suppose.

In the DeltaV diagnostics, the secondary of the Redundant Standby Controller still shows healthy.

It should show bad and that Comms not healthy.

Anyone else faced this issue before?

Thanks

dikshitsh

• 3 Dec 2018 6:51 AM
• Cancel

5 Replies

• Andre Dicaire

  

  • 3 Dec 2018 9:05 PM

  Please provide version and controller node type. Also, what is the address of the controller and what addresses did you ping.
  
  The Secondary network port may be healthy and the ping is failing due to an external issue. A check of my SX controller shows the standby controller diagnostics to indicate GOOD integrity as the only information. The Active will show a host of information such as connected nodes and data packets etc. Not so the standby.
  
  Did you ping from Diagnostics or from command prompt. Should work in both, but Diagnostics has some qualifiers and message may be different.
  
  Since we don't know any specifics on this, hard to suggest what it could be. I'd have to try disconnecting the cable on my standby to see what that looks like. If it is a bad cable or a bad port on the switch, the controller's diagnostics may not catch that.

  Andre Dicaire

  • Cancel
• dikshitsh

  

  • 4 Dec 2018 8:11 AM

  In reply to Andre Dicaire:

  Hi Andre
  
  Thanks for the reply, The DeltaV Version is 13.3.1, The controller types whose Secondary comms is not working (Only for the redundant standby controller)MD+, MD and MQ types, More than 20 controllers, Only 6 controllers(Md+, MQ and SD+ types) have all their comms which ping.

  The addresses that I pinged were 10.4.**.**, 10.5.**.**,10.8.**.**,10.9.**.**, I am unable to ping 10.9.** when 10.5 is standby and 10.8 where 10.4 controller is standby.  

  I pinged from Diagnostics and also from the cmd prompt but the request times out in both the cases.
  
  The strange thing is on these controllers in diagnostics, when I try the the TCP/IP through Secondary comms of the standby controller it fails, but says detected with multicast ping, Also the Telnet does not work through these secondary comms.
  
  The other Strange thing is secondary comms of both the active and standby controllers are connected to the same Switch in the Rack room and come through the single fiber to the control room network switch, and Iam able to ping to the secondary of the active controller, No issues there.
  
  

  The other thing is some Fiber ports on the secondary switch are blinking in a different manner than the primary and some secondary port connections.

  These ports in the DeltaV network command center are showing port locking violation though these ports are enabled. I can send a video of that If you provide me your mail id.

  • Cancel
• Andre Dicaire

  

  • 4 Dec 2018 3:46 PM

  In reply to dikshitsh:

  Your last comment is interesting. It tells me you are using Smart Switches. The first thing I would do is to unlock the secondary switch for these controllers. You also need to confirm the version of Smart Switch firmware you have installed. There should not be a port lock violation, but if we have changed cables on the switch to try other ports, this would set a port lock violation when a new MAC address was detected on a locked port. Unlocking the switch will allow the currently connected devices to be sorted out.
  
  Let us know if this has any effect.
  
  As far as sending a video, I prefer you to log a call with the GSC and have them interpret additional information. I've never observed this behavior and I'm not in a position to run this to ground for you.

  Andre Dicaire

  • Cancel
• dikshitsh

  

  • 5 Dec 2018 7:02 AM

  In reply to Andre Dicaire:

  Hi Andre
  
  Yes. we are using RM100 smart switches. The firmware is 9.0.12.

  The interesting thing was though the ports were enabled but also had a locking violation (We never have changed/removed cables after upgrade/installing smart switches).
  Yesterday, I had done an unlock of these switches with the auto lock of 60 minutes enabled, The comms were restored but as soon as the 60 mins expired and the switch was locked again, we got the same standby sec. comms. failure (Locking violation again) on a few controllers (Not all which had this issue initially), So I again unlocked (Without the auto lock timer) and locked it manually after the unlock was successful, have been 16 odd hours as I reply and all the comms are working fine,
  
  Dont know what the root cause for this comms failure was (Lock violation) or Why It wasnt fixed first time when I unlocked and locked the switches.
  
  I had logged a call with GSC a couple of days ago, sent them the DDC but still await their feedback, I shall update you once I hear back from them.
  
  Thanks for the reply and help.

  • Cancel
• Andre Dicaire

  

  • 5 Dec 2018 3:23 PM

  In reply to dikshitsh:

  This at least focuses issue on the smart switch. Best to work this with the GSC.

  Andre Dicaire

  • Cancel