Emerson Exchange 365

• Not Answered

Preserve PID output parameter on download

   Hello experts,

   I was wondering if it would be possible to preserve the output from PID during a download? I've tried to find the specific donwload parameter to use it as a condition, but I couldn't.

Thanks,

Sam.

Samuel Bandeira

• 5 Mar 2017 3:31 PM
• Cancel

6 Replies

• GeloCortez

  

  • 5 Mar 2017 11:21 PM

  I usually set PID mode to manual before download.

  • Cancel
• Kartik29

  

  • 6 Mar 2017 4:13 AM

  Normally on the module properties(select the control module right click properties) , you have the option of 'Parameter download behaviour' you can select either of those.

  Karma doesn't have any menu, you get serve what you deserve.

  • Cancel
• Digital Technician

  

  • 7 Mar 2017 4:39 PM

  Hi Kartik

   

  In the control module proprieties, under the “parameter download behavior”, how can I know what are the user defined and critical blocks values?

   

  Bruno Tanaka

  Automation engineer

  FPSO Petrojarl Cidade de Rio das Ostras

  Teekay Offshore

   

  office   +47 7398 8555

  mobile 

  email    pjs.digital@teekay.com

  Bringing energy to the world with Teekay Spirit

   

  • Cancel
• Kartik29

  

  • 8 Mar 2017 6:25 AM

  In reply to Digital Technician:

  Hi Bruno,

  User defined Parameters are those which are created by the user(for ex:- Ouput Parameters) and critical block parameters are those defined within the function blocks(for ex:- PID1/OUT)

  Below extract from DeltaV BOL:-

  "Parameter download behavior

  Select the download behavior. The choices are:

  Preserve critical block values - The controller copies critical function block values from the executing module to the new module during a download. This selection typically minimizes disruption to the process.

  Preserve user-defined and critical block values - The controller copies user-defined parameter values from the executing module to the new module during a download in addition to copying the critical function block values. Make sure to use this value if any parameters reference OPC Mirror data. If this is not selected the parameter values will change to their configured default after download rather than retaining the value from OPC mirror.

  Use configured values - The controller does not copy any parameter values from the executing module but uses the values from the configuration database. "

  Karma doesn't have any menu, you get serve what you deserve.

  • Cancel
• kmarks

  

  • 8 Mar 2017 12:35 PM

  In reply to Kartik29:

  Be aware that not all of the function block parameters are critical and will be preserved during a download. For example, the following are the critical parameters for a PID function block:
  
  MODE.TARGET, PV, SP, OUT, SP_WRK, FIELD_VAL
  
  The "Downloading data" entry in BOL contains a table with all critical function block parameters that will be preserved during a download.

  • Cancel
• Andre Dicaire

  

  • 9 Mar 2017 7:13 PM

  This is an interesting thread. The PID block by default should be the same following a partial and even a total download. The BOL table under the Downloading Data section indicates the PID bets the MODE.TARGET, PV, SP , OUT, SP_WRK and FIELD_VAL from the old module. The other parameters in the block will take on the downloaded values, such as GAIN, RESET, alarm limits etc.
  
  Typically, the PID Block also has its BKCAL_IN wired to the downstream block, and so the value of OUT will depend on this as well, but during a download, unless the logic directly associated with the OUT signal flow is modified, will preserve on download, if the Preserve Critical block information is selected. Even if it is not, the BKCAL signal should ensure the OUT value matches the IO OUT value.
  
  This is true if the PID block and AOUT blocks are connected as recommended and there is no additional logic that is triggered/initialized in the module that affects the PID out, such as a Track enable or what have you.
  
  I did a bit of testing as well. The OUT value of the PID block remains at its current value through a partial download. The MODE.TARGET is also preserved. The MODE.Actual is set to 2 or OOS on the first scan of the module, before the PID block executes, and moves to MAN during the first execution, and from there will move to the TARGET mode if the Downstream is in CAS, otherwise, it will move to IMAN. Note on a partial download, where the AOUT or other blocks and wired connections are not modified, initialization of the OUT parameter is preserved. If the Download modified this, by say inserting a Splitter block or renaming the AOUT block, etc, these new and modified blocks would go through their initialization and the PID out would drive to its final value based on the logic.
  
  As you read the list of parameters that are copied from the original instance of the module to the new one, many parameters are not actually transferred. These will take on the values in the database. It is important therefore to ensure tuned variables such as GAIN, RESET, RATE, alarm limits etc are uploaded to the database so that they are not overwritten,.
  
  During a download, what happens to all those parameters that are currently not equal to the default values in the database, that are dynamic in nature, such as the Alarm_ACT parameters? What if I have a CONDITION block reading the HI_HI_ACT value that sets an interlock and this value clears during the download? This is handled by the system. These parameter values are held in the original module location until the next scheduled execution of the new version. Any references to parameters are still to the original version. Within the controller, only one module executes at a time, and so any references to the module will happen before or after the new version executes. When it executes, all the alarm parameters and other internal values are updated on the initial scan and are again valid for peer references.
  
  Within a module, proper Block execution order is important so that internal references to say alarm states is done after the host blocks have executed.
  
  To test this, I created several 100 ms monitoring Modules and confirmed that I had at least one of them in each module execution time slice, so that one executed immediately prior and after my test module. On repeated downloads, I could detect internally to that module when values were initialized (i.e. MODE.ACTUAL = OOS on Download), but none of the monitoring modules ever saw this initial transient state of the PID mode.actual value.
  
  The PID / OUT was preserved without any initialization as it is copied from the original version and it overwrites the default value downloaded from the database.
  
  Because of the availability of the original version and all the parameter values up until the new version is used, data references remain valid for other modules, and any parameters communicated to other controllers or Operator stations will remain the same through the download.
  
  Note that the parameter list in download behavior is not the same as for redundancy updates. In redundant controllers, the modules update the dynamic values in the active controller to the standby controller as the modules execute. On a switch over, all modules hold these dynamic values, and as modules begin to execute, external references will still see valid data, even before their host module has executed for the first time. This now includes the XX_ACT values often used for Interlocks. In earlier versions, the XX_ACT parameters were not updated which might affect logic following a switchover (Configuration dependent), but this was enhanced, (Cannot remember if that was in v11, or v12...)
  
  So setting an AO Block to MAN prior to download should not be required for the PID to maintain its Out value, since a download is done to apply changes, it is up to the user to decide if this is to be done as a standard operating procedure, or is a case by case decision. It is important to ensure the Control Module design does not inadvertently cause disruption of Outputs during partial downloads, but by default the BCKAL connection of control signals, either via an AO block or when the IO reference is directly defined in the PID block, should align the PID/OUT with the field OUT signal during the module initialization following download.

  Andre Dicaire

  • Cancel