Emerson Exchange 365

John,
I haven't used the Advanced option, but have done it from the CLI. I made my own cable and it was a pretty quick process. When the switch reboots every port will be off line for a few minutes for the reboot.

In reply to Andre Dicaire:

Thanks Andre - it will be interesting to hear how the demo goes. Of course we conceive of the DeltaV PCN as redundant, but I remember hearing the degree of redundancy is possibly not 100% - DeltaV allocates the load between primary and secondary, so unlike controller / IO card redundancy the secondary network is not just loafing along waiting to spring into action.
I would imagine refraining from network-intensive tasks like calling up 6 months of 2 second history or downloading scores of complex modules might be something to avoid - otherwise all will be well.

In reply to John Rezabek:

John,

the basic difference between flashing the DeltaV Smart Switches over Ethernet vs. serial cable is that using the Network Device Command Center (NDCC) you are actually transferring the firmware files with an underlying TFTP application (you must run it manually as prescribed in NDCC) rather than using a USB flash drive attached to the switch itself. With that said, once the files are transferred, the remaining steps are pretty much the same, one using NDCC and the other a hyper terminal/console user interface.

As everyone mentioned here already, during the firmware upgrade the switch is not communicating so the network area affected by the specific switch will be down momentarily, but once the process is finished (few minutes) the process is concluded and communications are reestablished. If you are planning to consider an online upgrade, just make sure the redundant network side is available before proceeding on, there should be no issues with that approach.

The Knowledge Base Article with the firmware files describes the upgrade using the serial cable, but there are instructions to perform the Ethernet-based firmware upgrade in Books-OnLine and in the NDCC help.

I hope this helps!

Regards,

Alexandre

In reply to John Rezabek:

john, I have to correct you on the statement regarding DeltaV redundancy. DeltaV does not balance load between primary and secondary. If the primary network is 100 % available, all communication will be on the Primary. The secondary is then passing health information so that all nodes are aware that the secondary connections are all good.

Each DeltaV controller maintains a connection list of all nodes with which it communicates. For each node it monitors the health of the connection on both the primary and secondary networks. If the primary connection is healthy, data flows on the primary to that node. so if the primary connection to one controller is lost, such as the network cable being disconnected, data to and from that controller will occur on the secondary. Meanwhile, the remainder of traffic will continue on the Primary for all other nodes.

You can see the Device Connection List in Diagnostics by right clicking the Communciation container and selecting "Display Comm Connection List" . You can also view the Number of Good and Bad Connections for each network (ConGood, ConBad). The system should show 0 Bad connections and the number of good connection depends on how many nodes that device has established connections. A connection, once created remains in the list until a reset of the controller. The number of connected nodes is typically equal, unless there are some nodes that have simplex network connections.

So I would check before upgrading a switch that there are no nodes using that switch for any peer to peer communications. Best way to do that would be to check the Primary and Secondary ConBad diagnostic. If this is not 0, you can then check the Display Comm Connection List to see which node is reporting bad connection. Then you can determine if you need to remedy this connection or not. Normally, there should be no Bad Connections, so this should not take long. If there are, then these connections did not have redundancy and were at risk of a communications failure if the remaining link were disrupted.

Cheers.

Andre Dicaire

In reply to Andre Dicaire:

Andre - were you able to upgrade with the utility? I keep getting errors. I wonder if the GSC has anyone who's done this.
On one switch I get "unspecified error" (secondary). On the other, I once saw an error about the TFTP server. The other attempts are either "unspecified error" or no error is indicated - it just fails.

In reply to Alexandre Peixoto:

Yep - had to D/L a TFTP server ; one RM100 had to be power cycled before it would connect to the "server". Both upgraded using the utility in the NDCC.
One of the workstations' datalinks went to "&&&&&" during each upgrade, otherwise there were no other issues.