Emerson Exchange 365

• Not Answered

not seeing CSLS

I got my version 13.3 Proplus out of the box from Emerson partner.  all configuration already on this machine.  Plugged it in and connected cat5 directly to CSLS.  the CSLS is not shown on the local safety network ->unassigned safety nodes.

I tried 4 different cat5 cables and still nothing. 

I plugged directly into my SZ controller which was connected through safety switches to the CSLS still did not see it on unassigned nodes.

I plugged directly into the CSLS and still did not see it on unassigned nodes.

Yes I checked the power on both (it is fine 24VDC).  When cat5 was plugged in the communication light flickered next to the cat5 plug on both the server and the CSLS. 

Thanks,

pat 

Petrisky

• 6 Aug 2019 11:57 PM
• Cancel

6 Replies

• Andre Dicaire

  

  • 7 Aug 2019 11:49 AM

  What are the LEDs on the CSLS indicating? Confirm the CSLS is in fact decommissioned.
  
  If it was commissioned prior to shipping it may be holding that information. You may have to force it physically. Is the CSLS place holder in the database unassigned and decommissioned?
  
  If it was staged prior to shipment it may actually be commissioned and all you need to do is download.
  
  Anyway, need more information to help you further.

  Andre Dicaire

  • Cancel
• Petrisky

  

  • 7 Aug 2019 1:14 PM

  In reply to Andre Dicaire:

  Background: We were going to start loop checking the CSLSs before the software FAT was complete thanks to a colleague.... a temporary PROPLUS was brought in (with version 12.3 because we were originally going to have version 12.3...).
  
  The SZ controller and CSLS were downloaded with version 12.3 and the original software configuration.
  
  Jump ahead 6 months. The software configuration was updated and we ended up going with version 13.3. The rental PROPLUS is gone.
  
  I now have my real live version 13.3 plugged in. I plugged in power and then connected the CSLS directly to the Version 13.3 PROPLUS and I don't see any sign of the CSLS or SZ controller in DeltaV explorer

  • Cancel
• JDWheelis

  

  • 7 Aug 2019 2:39 PM

  In reply to Petrisky:

  Was the CSLS or SZ controller upgraded to V13.3 since they were downloaded from the rental V12.3 ProPlus? I believe neither will be operational with a DeltaV workstation (ProPlus) that is not the same version. You should be able to upgrade both using the normal upgrade procedures and the Controller Upgrade Utility.
  
  J.D. Wheelis

  • Cancel
• Petrisky

  

  • 7 Aug 2019 2:48 PM

  In reply to JDWheelis:

  Update to all....I found out I have to use old PROPLUS (version 12.3) to decommission the SZ controller and CSLS. I will then plug in my new PROPLUS (version 13.3) and assign and commission.
  
  Thanks

  • Cancel
• IntuitiveNeil

  

  • 7 Aug 2019 2:56 PM

  In reply to Petrisky:

  If that doesn’t work, please refer to DeltaV Books online and search for manually resetting decommissioning a CSLS.
  
  It involves powering down, and removing the Network port from the baseplate. After power up, wait for a 2 minutes for the CSLS to boot and go through self tests. Then you reinsert the network port.
  You have to do exactly as per the BOL procedure, see below. The wait 2 minutes is important.
  
  I spent half a day getting to the bottom of this issue when the CSLS was previously assigned to a different database placeholder.

  

  • Cancel
• Andre Dicaire

  

  • 7 Aug 2019 6:09 PM

  In reply to IntuitiveNeil:

  As IntuitiveNeil points out, you do not have to connect the Old ProPlus. You can decommission the SZ and CSLS physically.
  
  A correction on JD's reply. Although the SZ controller must be flashed to the same revision as the Pro Plus, the CSLS does not. The CSLS version is not tied to the version of DeltaV, as it is separate.
  
  As for commissioning, you have to commission the SZ before you can flash it to the current revision. So you should still see the decommissioned node even if it is not of the same revision as the Pro Plus.
  
  The SZ and CSLS use the same architecture as the CIOC, which introduced the concept of the separate Ethernet modules. These Ethernet Modules store the Commissioning Information for the node. Previously, in M series and S-series controllers, the commissioning information (i.e. the assigned IP address and node name) were stored in the controller, by pulling the controller from the carrier, it would clear the commissioning. With the CIOC, we looked for a way to allow the CIOC to hold its commissioning data from FAT to site or through an extended power outage. The separate IOP's have NVM so the MAC address of the two processors is stored there. If the same processors are installed in the same location as the IOP's stored data, the processor will be commissioned during its power up sequence. The same approach now applies to SZ, CSLS, EIOC and new PK controllers.
  
  This is why you have to remove the IOP's in order to physically decommission the node. With the IOP's removed, the processor will complete its self tests and remain decommissioned. By swapping the position of the processors on the carrier, you change the make up of the node such that it does not match the stored information in the IOP. When you install the IOP's, they will recognize that the hardware configuration has changed and will not apply the commissioning data.
  
  At this point, the device (SZ, CSLS, CIOC, PK controller) will broadcast its presence to the Pro Plus. If the Pro Plus has this MAC address defined as a commissioned node, it will automatically commission the device. So even after you manually decommission a node, it can automatically be recommissioned and you'll never see it in the Decommission list. If the node was never commissioned on a system, this will not happen. But if you import an FHX from another database that includes the export of the controller while it was commissioned, you could find yourself not seeing the new hardware in the decommissioned list, even if you physically decommission it.
  
  Warning:
  When moving hardware from a test system to a production system, always decommission the hardware before it is connected to the running system. The IP address assigned to the hardware during test might conflict with IP addresses of existing devices in the production system. this is true for Operator stations as well. If you install and power up these new devices and connect them to the production network, an IP conflict could disrupt communication to an existing device. Since the conflict will be on both Primary and Secondary, it will disrupt all comms to that device. For workstations, you should run Workstation configuration to set its IP addresses for the new system before you connect to the network. For embedded hardware nodes, they should be decommissioned in the database, and physically decommissioned prior to connecting to the network. (Red LED flashing slowly).

  Andre Dicaire

  • Cancel