OWS showing cross in explorer

Hello Everyone.

Can anyone please tell me why my workstation (Ows9) node in DV explorer is showing a cross even though OWS9 is working fine?

I am able to download ows9 also I am able to operate process through ows9.diagnostics of ows9 also shows everything fine.

25 Replies

  • Restart ows9 and then check in diagnostics.
  • Have you checked the suggestion by Roman?
    Please verify that the primary and secondary networks are going to the proper switches for that workstation.
    This isn't just unplugging the cable and seeing the network adapter show not connected at the workstation.
    You need to check that these cables are going to the proper switch for the associated network adapter.
  • In reply to Matt Stoner:

    Yes Matt I have checked and also I have reversed the network cables the communication went bad as soon as i reversed.
  • In reply to Siddiqui:

    Interesting that Diagnostics shows the OWS8 and OWS9 nodes as connected and GOOD, but Explorer flags them as not communicating. To get to the bottom of this, you have to be very specific and clear on the information. Your comment about diagnostics has me questioning exactly what you are showing us.

    What is the workstation name where you are running DeltaV Explorer?
    Does OWS9 show up with the red X in Explorer on all workstations or just this one station?
    Does OWS9 show up good in Diagnostics on all workstations?

    This will tell us if the issue is unique to the station you are viewing Explorer on, or is common to all stations, and therefore not really a specific issue for Explorer, but rather the network health.

    Also, in Diagnostics, expand OWS9 and right click on Communications, select Display Comm Connection List. This will show all nodes that OWS9 communicates with and will indicate the status of the Primary and Secondary connections. Verify specifically the status for the workstation where you are running Diagnostics.

    You can also run the PING commands to determine if the Workstation running Diagnostics can successfully ping and multi cast ping the OWS9. Note you have to ping from Communications/Secondary context menu to go out the secondary network. Also the Multi cast Ping result shows up in the Integrity History message section: TimeStamp NodeName Detected with Multicast Ping.

    I'm thinking that if we have a network issue between the Explorer station and the OWS9 node, Diagnostics may show you that OWS9 is healthy on both networks, and the Explorer node is healthy on both nodes, but one of the connections between these two nodes is not working. The connection list and Ping results may illuminate this.

    There are times where restarting the database, rerunning Workstation configuration and other broad stroke actions maybe required, and if that fixes it, we can move on, but never know exactly what happened. To me, these are the fall back actions when time forces our hand and we don't know where to go next. Let's take a moment to investigate the symptoms before we prescribe the wrong medication.

    Andre Dicaire

  • In reply to Andre Dicaire:

    They are probally both not connected to the proplus, out of my head do a right click on the comm in diagnostics and check the connections on both nodes.

    I guess those hosts see only the nodes on the same switch and thats why they say comm is oke

    Check the cables between both switches, maybe the switch is not connected to the main switch if the proplus.

    Regards
  • In reply to Siddiqui:

    FYI: If you are using DeltaV Smart switches, and you swap cables, and the switch ports are locked, the switches will prevent any communications on either cable. You need to disable port locking during any troubleshooting involving changes to Ethernet port usage.

    Andre Dicaire

  • Looks like a graphical glitch.
  • In reply to Siddiqui:

    You may want to install the DeltaV software updates on OWS9 to match the software revision with the other stations.

    Check if network connections are interchanged (DeltaV Primary network is connected to DeltaV Secondary of OWS9). Remove all other network connections of OWS9 except the DeltaV Primary. Make sure the PRO+ (EWS1) is up and running. On the OWS9 open up command prompt then ping 10.4.0.6 (PRO+ Primary) then ping 10.8.0.6 (PRO+ Secondary). Following are the possible results and what they mean.

    1. 10.4.0.6 has a reply but 10.8.0.6 does not have a reply. At least the DeltaV primary network is good on OWS9.
    2. 10.8.0.6 has a reply but 10.4.0.6 does not have a reply. The DeltaV networks are interchanged on OWS9. Need to correct network connections.
    3. No reply from either 10.4.0.6 and 10.8.0.6. Network issue. Need to correct network connections.
    4. Both 10.4.0.6 and 10.8.0.6 has replies. The DeltaV primary and secondary networks are interconnected somewhere. Need to find the interconnect and disconnect it. Do the ping test again.

    Regards,
    Neil Castro
  • In reply to Andre Dicaire:

    Thank you Andre,

    I am running Explorer on EWS1 & OWS9. Yes OWS9 shows good on All diagnostics. Under Display Comm Connection List I cant see OWS9 Display Comm Connection List.

  • 1. Can you post a picture of the routing table from OWS9 and EWS1? From command prompt: route print -4.

    2. Please verify that the "SystemID" registry value is the same on OWS9 and another functional node.

    Located here on 32bit nodes: HKEY_LOCAL_MACHINE\SOFTWARE\FRSI\DeltaV\CurrentVersion

    Located here on 64bit nodes: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\FRSI\DeltaV\CurrentVersion

    Please let us know if they do not match. Please do not post the registry value here, nor should you change the value.

    3. Please verify the Time zone and time of OWS9 vs the Proplus.

    4. Ensure Ping tests are intiated from Diagnostics OR that "ping -k" syntax is used from the command line. Eg. ping -k 10.4.0.6 10.4.0.6

    A normal Ping from one computer to another on dual-homed redundant networks (such as DeltaV), is not very helpful for troubleshooting redundancy. Computers will dynamically create temporary route for themselves to establish an alternate path of communication. E.g. If you disconnect the Primary from a computer, it will still hit the Primary addresses of other computers (but not controllers). Controllers however do not establish dynamic routes therefore they are still useful for determining redundancy from a 'vanilla' ping.

    5. If Windows 7/2008R2 and prior, verify NIC binding at both end. If Windows 10/2016 verify NIC metrics.

    6. Consider temporarily unlocking the associated smart switches.

    Brock P.