Emerson Exchange 365

Cold Restart - Controller Behaviour on Startup

I have a controller that is doing something I don't understand on startup. It is a SX controller, 13.3.1, PCSD V13, with Version Control.

I know it's not ideal to remove power from a DCS controller. We are working to improve the UPS and power systems.

I have a question related to how a controller, modules within the controller, and ?? are controlled on a powerup.  From the event data, It appears a COLD_RESTART was triggered. 

Does the "Always Disabled " on the controller mean that it always cold starts and reloads DB values?  We have some that have a time limit of 2 days.  I thought if, Always Disabled, it wouldn't ever load from DB.

Some of the messages in the event data seem to be overriding individual attributes. Is this from the Parameter level "Restore Parameter Value after Restart"

Another thought-   Let's say I changed an online value, maybe tuning value of PID gain. I checked out module from DB, didn't go online but manually changed affected parameter, then checked back in WITHOUT downloaded.  So my version changed in VCAT but wasn't downloaded. If the controller cold restarts, will it pull the data from the newest VCAT version or somewhere else?

Sorry for sporadic questions. I know my data is changing on power up but not sure how.

Thanks in advance.

EVENT DATA

Controller Settings

Module Settings on individual parameter

• Cold Restart
• power up
• Version Control

s_brwn

• 5 May 2023 8:11 PM
• Cancel

2 Replies

• ElectroTech

  

  • 10 May 2023 1:17 PM

  Parameters with Restore Parameter Value after Restart are failing because you have cold restart disabled. Typically that is set to Always Enabled (Maximum Time) to avoid your situation.
  Curious as to your system, it appears you have no controller redundancy nor power supply redundancy?
  This is all well and good that you are attempting to actively manage the restart but this could also happen at any time with a blown fuse or other power loss situation.

  • Cancel
• ElectroTech

  

  • 10 May 2023 1:36 PM

  Regarding losing tuning values, its not completing uploads that causes them to not be captured, downloading isn't the issue, uploading makes the database match the online controller, donwloading makes the controller match the offline database.
  If you do not complete uploads any time the controller is shut down you have lost those values, or any time you do an upgrade.
  With controller redundancy the controllers will jockey the new values to the standby automatically, but still needs to be uploaded to the database in case of a major failure.
  Tuning values are relatively minor to lose, but alarm and trip setpoints can cause real safetly issues.
  There is also download behaviour, which by default is Preserve Critical Block Values which in most cases should be changed to Preserve User Defined and Critical Block Values so that things do not overwrite to what is in your database on download.
  Setting this incorrectly is often what casues things to trip on download as the device gets set to whatever is in the database, which by default most people put as a safe state, motors off and PID loops in manual at 0%.
  
  You need to take a look at what all this means in combination as it appears you have the functions mixed up.
  
  Cold Restart allows the controller to come back to life the same as it shuts off, and then populates the parameters that have Restore Parameter Value After Restart If you disable it the controller has nothing but the database to reference on restart and as it comes to the ones with Restore turned on (many of them) it will fail because it has been disabled on the controller.
  Now you are forced to do a download to get the online controller to match the database.
  The reason we set it to maximum time is that if properly programmed and using physical ESDs there should be no concern about a system just starting up inadvertently, but there are cases in catastrophic events where the database could be destroyed, or otherwise not up to date.

  • Cancel