Emerson Exchange 365

Virtual Controller Communication on a Multinode Simulation

Hello,

I am working on a multinode simulation system with one Proplus station and one virtual S-Series controller. I am running into a problem where I am able to see the controller in the decommissioned nodes group, but after commissioning, the assigned controller loses communication. 

Here are something I can see even though explorer is showing that it is not connected:

1. I can ping the virtual controller

2. the assigned controller has an assigned MAC address and IP that is consistent with the DeltaV network.

3. There was traffic to the controller while the controller was undergoing "autosense"

In a virtual system, why would the controller lose communication after commissioning?

hoang nguyen

• 10 Mar 2021 9:40 PM
• Cancel

5 Replies

• Andre Dicaire

  

  • 10 Mar 2021 9:46 PM

  Is this a hyper V or VMWare environment?

  Andre Dicaire

  • Cancel
• Andre Dicaire

  

  • 10 Mar 2021 9:48 PM

  In reply to Andre Dicaire:

  In general, when a decommissioned controller is connected to the DeltaV system, it communicates via broadcast messages. If your VM networks are crossed ( also true for physical controllers), the Decommissioned controller will appear in the decommissioned list. Once you assign it to a node, it is rebooted with its fixed IP addresses and subnets and if the networks are crossed, there will be no communication.

  Andre Dicaire

  • Cancel
• hoang nguyen

  

  • 11 Mar 2021 4:33 PM

  In reply to Andre Dicaire:

  Thank you for your reply Andre.
  
  Can you please explain the crossing of networks further?
  Primary network is configured as: 10.4.0.6
  Secondary network is configured as: 10.8.0.6
  When commissioned the controller gets assigned: 10.4.0.10 and 10.8.0.10
  
  Also, you mentioned that the controller reboots after being commissioned, does the whole VM get rebooted or is that an internal function?

  • Cancel
• Andre Dicaire

  

  • 11 Mar 2021 6:09 PM

  In reply to hoang nguyen:

  When a controller is decommissioned, it sits on the networks it is connected to and broadcasts its MAC address. The IP address does not matter. If you have the Primary port of the controller connected to the Secondary network and the Secondary port connected to the Primary network, the broadcast messages will still be seen and read by the Pro Plus. This will result in the Decommissioned controller being "Seen" and showing up in the Decommissioned list. When you commission it, the Pro Plus will send the IP address and controller name to the decommissioned controller using its MAC address, because if you have two or more decommissioned nodes, they all share the same IP address. (The MAC address is unique in the world and is assigned during manufacturing. It cannot be changed.)
  
  When the controller receives its assigned IP address and name, it resets and reboots with the new addresses. At this point, if the ports are crossed, you lose communication because the primary 10.4.x.x address cannot communicate with the pro plus 10.8.0.6 to which it is connected. Similarly for the Secondary Port of 10.8.x.x unable to communicate with the Pro Plus at 10.4.0.6.
  
  So this would be one possible explanation for the behavior you are seeing.
  
  The other is dependent on whether you are using VMWare. I received an Email yesterday that described an issue with how the VM controllers and such end up reverting to Bridged networks, which disconnects them for the expected, required virtual network in the PC. A colleague suggested that the VMDX file needs to be modified to allow the VM to take on and keep the assigned IP information when commissioned.
  
  We modify the existing lines to:
  ethernet1.networkName = "VMNet2" => ethernet1.networkName = ""
  ethernet2.networkName = "VMNet3" => ethernet2.networkName = ""
  and then Add:
  ethernet1.vnet = "VMnet2"
  ethernet1.connectionType = "custom"
  ethernet2.vnet = "VMnet3"
  ethernet2.connectionType = "custom"
  
  Once these changes are done, the VM can be opened with VMWare v15 and MAC addresses can be adjusted if needed (They must be unique).
  
  I have not looked that this in great detail, but it too sounds like it could result in the same behavior your described.
  
  Hoping someone else on the forum can provide more detail on this aspect of the VM controllers, EIOC, CIOC and SIS nodes.

  Andre Dicaire

  • Cancel
• hoang nguyen

  

  • 27 Apr 2021 9:30 PM

  In reply to Andre Dicaire:

  Hey Andre,
  
  We looked into the situation further recently. Out network representative confirmed that the Bridged networks issue was not occurring.
  
  We tried multiple virtual controllers, but almost none worked. When we used and connected to the virtual CIOC it initially did not work, but after a rescan we established a working communication where we could download to this node.
  
  After this, we tried to use DV Diagnose to see what else can be done. What we found is that even though we could not download an virtual SX controller, we are able to ping and telnet the virtual controller. The only error we receive at this point is that there is not enough memory to perform the download. We've tried to manipulate the ram and hard disk to see if that would change anything and it did not.
  
  Is there anything else you'd recommend trying? I am thinking we're being blocked by an application from accessing the controllers memory.
  
  Thanks,
  Hoang Nguyen

  • Cancel