Deltav Controller IP Addr Discrepancies

The DeltaV network is configured in two subnets 10.4.x.x for Primary and 10.8.x.x for Secondary. The Primary controller's IP address is 10.4.0.86 and the Secondary controller's Ip address is 10.8.0.86. When switching over redundancy controllers, the addresses displayed on diagnostics is 10.4.0.86 and 10.5.0.86.

Communications to operator stations are not affected so is this IP addr discrepancies a concern?

Why is the secondary controller showing a different address than what is configured?

Thanks

  • The primary controller uses 10.4.x.x and 10.8.x.x. The redundant controller uses 10.5.x.x and 10.9.x.x. This is expected behavior. As a reminder, DeltaV sets the IP addressing for each node and it should never be changed manually.
  • In reply to Brian Atkinson:

    our delta V system seems to behave different. The primary controller, that is the active controller, can be either 10.4 or 10.5. The address 10.4.x.x seems to be assigned to controller and it does not matter if that controller is active or in standby. It may just be you are referring to the A and B controllers as primary and standby?
  • In reply to doug bray:

    As Brian explained, the address space for the primary and secondary addresses spans two Octets, from 10.4.0.1 to 10.5.0.255 for the primary and 10.8.0.1 to 10.9.0.255. Note that the subnet mask for DeltaV NICS is 255.254.0.0.

    The call states that diagnostics is showing two primary addresses (10.4.0.86 and 10.5.0.86) after a switch over. That would not be correct. Either the call description has an error, or the diagnostics is not reporting the correct information. Did you mean to say the primary changed from 10.4.0.86 to 10.5.0.86? That would be normal.

    You should be able to PING the various addresses from the engineering station and should only see responses on the correct network cards. PING 10.4.0.86, and 10.5.0.86 primary addresses for the controller. They should "Reply...". If not, it will indicate destination not found on the 10.4.x.x NIC of the workstation. Do the same for the 10.8.0.86 and 10.9.0.86. If all NIC's respond, the controller has its assigned addresses and is connected correctly.

    If you are seeing two primary addresses, please be more specific such as, Primary Active NIC = 10.4.0.86 and Secondary Active NIC = 10.5.0.86. and also for the Standy controller, what are his NIC addresses in diagnostics. If you controller is showing invalid IP addresses in Diagnostics, you should file a call with the GSC and get them involved in the investigation.

    Andre Dicaire

  • In reply to Andre Dicaire:

    I guess I did not make clear. I am not part of the mill that had the original post. I was just asking a general question about the structure of how delta v addresses are used and specifically wanted to be sure I understood his use of the words primary and redundant in terms of the a and b controller designation.
  • In reply to doug bray:

    The words Primary and Secondary refer to which controllers hold the 10.4.x.x/10.8.x.x or 10.5.x.x/10.9.x.x.
    Active and Standby are used to indicate which is actually running Control Modules.

    Either controller can be the Active controller, but the Primary controller will be Active when the node is first commissioned.

    The network is redundant, and we often use Primary to designate the 10.4.0.1 to 10.5.255.255 address space. The Secondary Network, which is sometimes referred to as the redundant network (I prefer Secondary, as the two together make up a redundant network) is the 10.8.0.1 to 10.9.255.255 address space. When DeltaV assigns IP addresses, all simplex and primary nodes get an address in the 10.4.0.6 to 10.2.255.254 space, in increments of 4. If a node is redundant, the secondary address shifts the second octet to 5, but maintains the same relative address, i.e. 10.4.0.86 uses 10.5.0.86 for its partner. Same on the secondary network.

    Generally, primary and secondary applies to physical components, while Active and Standby apply to functionality.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Thanks for the help. That is exactly what we needed and was as we understood it to be.