Emerson Exchange 365

• Not Answered

SZ Controller not downloading Completely and CSLS I/O Decommissioning from Explorer

Hi all,

I have a redundant SZ controller (Software Rev: 12.3.1.5220.xr., Hardware Rev: 1.7), and 3 set of redundant CSLS; with DeltaV 12.3

Initially, i commissioned the SZ controller and i was also able to download it. Then i assigned the CSLS to their respective placeholders, then they were commissioned. 

When i tried to download the CSLS, the download didn't complete. After trying many times without success, i then decided to unassign the CSLS, but they failed to unassign. All i could do was to decommission the controller and swapped the SCLS from their respective slots to see if they would decommission and unssign themselves in Explorer. The CSLS decommissioned hardware wise, but still showing as commissioned in explorer and also has X on it.

Current State

1. CSLC cards are decommissioned hardware wise.

2. CSLC cards are not decommissioned software wise.

3. SZ controller can be commissioned on the placeholder but doesn't download completely. 

SZ Controller Error during download: Error Code 327781   RTC_NO_FB_DEFINITION_EXISTS.

Because of these errors, i then tried to create a new placeholder for the SZ controller. I commissioned it and was able to download it with the new placeholder without error. This shows the former placeholder is corrupt i guess. 

I exported the old placeholder and deleted the license line when opened with note pad. For me to import it back to the database, i have to delete the old placeholder to have the license floating; but i can't delete the placeholder because of the (3) SCLS that are showing as commissioned in explorer.

Please help me with how i can unassing or remove or delete these CSLS and the whole SZ controller node from the Database.

Meanwhile, there are some other nodes that are live(Running Plants) in the database.

Thanks in advance for your kind replies.

• SIS
• DeltaV #DCS
• DeltaV 12.3
• CHARMS

Alexander Tom

• 25 Mar 2022 11:06 AM
• Cancel

7 Replies

• Tadeu Batista

  

  • 25 Mar 2022 2:24 PM

  There's a KBA with instructions on what could be done when you get the error you mentioned, but since you already moved past that, I would suggest you contact the GSC support.

  • Cancel
• Stefan Muellner

  

  • 25 Mar 2022 2:25 PM

  Hi Alexander.
  
  First of all I thought that CSLS are not supported by version 12 BUT I checked the datasheets:
  
  Prerequisites:
  „ DeltaV SIS with Electronic Marshalling hardware requires DeltaV v12.3 or later software.
  „ Non-boolean secure parameters requires DeltaV v13.3 or later software.
  „ Keylock Ethernet Isolation Port requires DeltaV SIS v14.3 or later software
  
  So we´re fine with this ;-)
  
  
  Also I found another post with the same failure message:
  emersonexchange365.com/.../8928
  
  So it seems not to be a CSLS related error number.
  
  
  
  
  Would the devices be shown in the folder of "Unassigend Safety Nodes" if you would put the CSLS back in place physically?
  But honestly I have no idea why the CSLS couldn´t be deleted or at least uncommissioned.
  
  Regards

  Stefan Müllner
  Senior Plant Engineer - Automation & Systems

  METADYNEA AUSTRIA GmbH
  

  • Cancel
• Stefan Muellner

  

  • 25 Mar 2022 2:49 PM

  In reply to Tadeu Batista:

  From a KBA I found:

  Important: To resolve the issue, you must apply the hotfix, and then import the database. For DeltaV v12.3 and v13.3 systems: A software solution is not available for these versions. We recommend upgrading your system to DeltaV v12.3.1, v13.3.1 or later.

  So maybe though a version issue...

  Stefan Müllner
  Senior Plant Engineer - Automation & Systems

  METADYNEA AUSTRIA GmbH
  

  • Cancel
• Tadeu Batista

  

  • 25 Mar 2022 2:56 PM

  In reply to Stefan Muellner:

  It's not version related, for Safety and Security reasons, non-communicating nodes are not allowed to be decommissioned from the SIS database (either SLS1508 or CSLS), in a situation like this, where the nodes were manually decommissioned, and the commissioned on a separate placeholder, you should get in contact to GSC, they might be able to walk you thru a procedure to remove it from the DB.

  • Cancel
• Alexander Tom

  

  • 25 Mar 2022 6:42 PM

  In reply to Stefan Muellner:

  @Stefan Muellner: Thanks for your reply. Yes; after i manually decommissioned and unassigned the CSLS, they all appeared on the "Unassigend Safety Nodes", but the placeholder in explorer is still showing them commissioned.

  • Cancel
• Alexander Tom

  

  • 25 Mar 2022 6:47 PM

  In reply to Tadeu Batista:

  Thanks for the advice.

  • Cancel
• Alexander Tom

  

  • 25 Mar 2022 7:22 PM

  Thank you all for your concerns and contributions so far.

  To update you:

  I bypassed the switches (1 for Pry. and 1 for Sec.) connected in-between the SZ Controller and the Main Control Network hubs (Pry. And Sec.) then surprisingly I was able to download the SZ controller on the Old placeholder. Reasons for not being able to download with the former connections; I don’t know!

  The issue I have left now is how I can unassign or delete the 3 CSLS nodes from the Database.

  • I have all the 3 CSLS appearing on "Unassigned Safety Nodes".
  • The 3 CSLS placeholders are still showing as commissioned node in explorer.

  Thanks in advance for your resolution advice.

  • Cancel