Restore parameter values after de(re)comissioning of controller

Hello Madames, Sirs!

I kindly ask you for a solution for the following task:

I am having a Counter value that has to be stored permanently. Therefore I am using a CALC block variable.

As long as I do not decomissioning the Controller, it works perfect. So, I can down the Module and open the module and the parameter value is as it was before the download.

But if the Controller has been decomissioned, after (re)commissioning, the counter value (CALC block variable is set again to its initial value.

Q:  Is there any possibility to restore the actual value of the counter?

f.ex: Counter value before decomissioning = 3

        Counter value after recomissioning = 3

So far, i am getting always  the initial value, f.ex. 0.

Would be nice to get some ideas, BR Horst

Horst

• 5 Jun 2025 8:15 AM
• Cancel

2 Replies

• Andre Dicaire

  

  • 5 Jun 2025 4:10 PM

  I would not use a CALC Block variable. An expression variable does not survive a controller switchover, or a Total Download.
  
  I would define a Module level parameter to store your value. This will persist on switchover.
  
  Here is an off the cuff suggestion so I don't have a proven configuration, but the idea is simple. Create a second module assigned to an App Station or other controller. This module will read you Count parameter and check if it is valid (should be equal or bigger than the backupCount value you store). If the Count module is reset, the BackupCount will be larger (it has the last value) and you can update your Count value from the BackupCount parameter.
  
  The back up Module reads from the Active Counter value, and the Active counter reads the BackupCounter value. No writes across the network. Use a Calc Block to validate the values before taking action.
  i.e. If Counter > BackupCount then BackupCount := newCount;
  
  In the source module, If BackupCount > Counter then Counter := BackupCount;
  
  This way, both modules have to be reset at the same time to lose the count value.
  
  There is also the SYSSTAT parameter than can be used to detect when a module is executing for the first time following a download. This can detect total downloads, switchovers partial downloads etc. However, it seems in your case that whatever the reason, the counter should never be reset, and the simplest logic here is to compare to the backup value.
  
  Error handling is usually the most complicated part of any solution. What if you do want to reset this value from time to time? You might want to add a second reset parameter. Place this in your source module. When True, reset the Counter to 0. In the Backup module, you also read this value and when true you allow BackupCount to follow this "smaller" value. Back in the source module, you can clear the Reset value once the BackupCount value is seen to be 0 (or <= to counter).
  
  You should also be considering Status on these remote references. The source module would continue to count if BackupCount.CST shows not connected. Similarly, if Counter.CST in the backup module is not connected, you would pause updates. Or, you could continue counting in the backup module until the connection is restored. This would make the counter redundant.
  
  Start with a simple use case and test that you can recover the count.

  Andre Dicaire

  • Cancel
• Horst

  

  • 6 Jun 2025 4:58 AM

  In reply to Andre Dicaire:

  Hello Andre!

  I am going ahead wiht your proposal to find out how it works with the SYSSTAT parameter and with the backup and source modul.

  Thank you for this great solution !!!

  Have a nice day,

  Horst

  (So by the way, I am new in working with DeltaV, but I already like it :-))

  • Cancel