Verify Primary and Secondary CAN are communicating

Hi All

I am reading some technical article for Delta-V and found this sentence.

- Verify Primary and Secondary CAN are communicating

My question is, what is the CAN? Could you please describe full name?

  • The ACN stands for Area Control Network. This is the DeltaV network that connects workstations, controllers IO Nodes via the primary and secondary networks.

    Using DeltaV Diagnostics, you can select a node and view the state of its primary and secondary network connections. In particular, under each network, you can see the number of good and bad connections as seen by each node. This can help you determine where you may have an issue in the network, such as a bad cable or Switch.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Should the number of Good connections plus the number of Bad connections add up to the total number of nodes minus 1?
    We have nodes on our system reporting 39 good connections (0 bad) and others reporting 42 good connections (0 bad). Is there an algorithm that removes nodes from the list if they have been bad for too long?
  • In reply to Casey Houchens:

    The number of nodes is based on actual configuration and resulting communication requests.

    On initial download a controller will have a connection to the pro proplus. Typically it will also set up a connection to the historian and event journal nodes, assuming you have these and history is configured.

    As operator consoles ask for data they get added. If you have remote references executing these nodes are added and if the references are in other controllers those too are added.

    Nodes that have no references or consoles that have not launched diagnostics and or have not displayed data from the controller will not have a connection. But give them time...

    If you have remote IO CHARMS, WIOC, RIU, these also appear in the connection list.

    In some cases connection nodes are deleted but connection remains in list and shows as bad connections.

    You can clear these with a switch over of controller.

    Check the connections list for who is connected.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Thank you for the information.
    So, if I understand you, ConGood can't be used to diagnose network health, because you would have too hard a time knowing how many good connections to expect. You could use OLInteg or OCInteg, but they would only show you the first problem? Should I expect that the ProPlus should have a ConGood for each node? We want to have an alarm (the same alarm retriggered) each time a new bad communication event occurs. Is there a particular node that should trigger this alarm, or should they each have their own? Do you have any suggestions on how to achieve this?1
    Thanks.
  • In reply to Casey Houchens:

    Although the number of Good connections may vary, the number of Bad connections should be 0. If you have deleted nodes that were connected, these need to be removed to get Bad connections to 0, and that may require a Switchover or Total download.

    There certainly is a minimum number of Good connections per node that you engineer. that is the downloaded confirmation has remote references that will immediately establish a connection. This happens on Peer to Peer references or IO nodes. You Historian is also configured to establish these connections. The only real variables are the consoles, as you can have an operator console not connect to all nodes, so it does not show up as a connection, until it does. But once connected, it remains Good, unless you reboot it or delete it.

    So Good/Bad connections is a valid diagnostic to monitor, with BAD connections > 0 being something to investigate. If BAD connections is not 0, use the connection list to identify which connections are not communicating and resolve them.

    Andre Dicaire