Grouping Alarming of DeltaV Live and DeltaV Operate Stations in a control room

Ladies and genlemen.

We are operating a seperated control room with 6 operator stations:

GROUND FLOOR:   2 of them (OS1, OS2) ran DeltaV Operate and 2 of them (OS3, OS4) ran DeltaV Live working on the newer plants of our site

1ST FLOOR:   1 operator station (OS11) ran DeltaV Operate and 1 of them (OS12) ran DeltaV Live - also for the newer plants of our site

Because this is only a part of the whole system, the stations are NOT participating the Global Horn Acknowledge Group.

A few years ago we configured a scheduler inside DeltaV Operate and combined the stations to seperated "alarm groups". Due to the fact DeltaV Live isn´t supporting scheduling I am now searching for work arounds.

Ideas and suggestions appreciated.

Thanks in advance.

brg Stefan

Stefan Müllner
Senior Plant Engineer - Automation & Systems

METADYNEA AUSTRIA GmbH

4 Replies

  • not sure what your script is executing or how frequently the scheduler was firing.

    One approach is to use timers in your Alarm Banner. The script will fire based the timer. I noticed that the timer value is in milliseconds but only accepts values up to 65535, so max time is 65 seconds. You can set this to 60000 and use a counter in your script to execute every 60 seconds.

    Another approach could use a Picture variable, again on your Alarm Banner and link this to a Module parameter, and enable the OnWrite script. In the Module use a DTE block to set the Module Parameter. In the Variable OnWrite Script, read this Module Parameter and execute your desired logic. To make the OnWrite work, the script finishes by returning the current value of the parameter. This updates the variable value and the script stops executing. I would place a Set Flip Flop between the DTE and the parameter. The DTE will set the block on the event time with a one shot pulse. The script will fire on the Set state of the Flip Flop, and I reset the Flip Flop in the script. This ensures the trigger remains true until the console script sees it and resets it.

    Note: Create a trigger Flip Flip flop for each Console. You can use one DTE that sets multiple Flip Flops that are each reset by one single console event variable. If you use the console name for your trigger parameters, you can use the ENV.Nodename to customize the AlarmBanner variable script so one common alarm banner uses a dedicated set of module triggers.

    You could create an Embedded block for each console in one module. Name each block with the Workstation name, and create a flip flop trigger for each event. Then you can create system event triggers at the module level that you reference in each console, or create console specific triggers in each embedded block. Now you have a Module based scheduler that could also provide an event trigger used by control modules.

    This module could be assigned to a controller or to an App station.

    I'm thinking that you might also add a log event on some timers so that you record events when they are triggered. If an event fails to be reset by its console script, you could log that as well. Note that if your script resets the Flip flop, this write event will be logged as a user change event automatically. If the script did not execute, this even would be missing. So most events need not generate a log event from the module. Simple is always best. You don't want to fill the Event database with non-actionable records.

    So I'm thinking Timer scripts that fire every minute and conditionally act on HMI level properties are a good option with no network communication or log events other than parameter writes. Module level triggers give you system wide event triggers based on the system time, and can trigger on times greater than 60 seconds.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Hello Andre.

    Thank you very much for the detailed explaination.

    After approx 20h of "tries&errors" my event based scripts started to work succesfully now. Aspecialy the "OnWrite"-coding is very tricky with all the little differences starting at the variable declaration with let, var, const, ... and the very basic functions WirteAsync, ReadAsync, CondRead, etc. Also the finishing RETURN action is not 100 percent clear to me up to now.

    From my point of view the descriptions and given examples inside the BOL are realy very unsufficient. E.g. there is no example how to do a simple parameter write onto a control module. Out of your experience, is there any further documentation, online course or something else available to increase skills without hundred times of modifying code lines?


    Thanks again for your time and your involvement in the DeltaV Forum!
    brg Stefan

    Stefan Müllner
    Senior Plant Engineer - Automation & Systems

    METADYNEA AUSTRIA GmbH

  • In reply to Stefan Muellner:

    I hear you.  DeltaV Live is a different scripting environment that VBA and for those of us not familiar with TypeScript, or JAVA, one has to take some time to master the basics and understand the new syntax, especially the new DeltaV specific functions.  

    For the TypeScript side of things, I've relied on the Internet (Google is my friend, as Duncan would say).  There are many supported functions that are not explicitly documented in BOL. like the MATH. library functions.  

    As for the OnWrite feature, that is definitely not well documented, by that I mean it is not documented in BOL.  "Topic not found" when you search.  BOL for Live does mention it, but fails to tell us about the Return function that is required.

    Based on this explanation, if you define the variable as a Boolean and set its default to FALSE, and define an OnWrite script, then writing to the Variable itself within DeltaV Live, and setting it to True will trigger the Script.  When the script returns a FALSE, to match its default value, the script stops running.  

    - Layout variables cannot be animated with Runtime data, and yet, they can have an OnWrite script.  Linking the variable to a Standard allows for some global control of the default value, but the only way to trigger the script is again writing to the Variable itself, as its source is static.

      

    Confirmed.  A Layout variable linked to a standard will trigger its OnWrite Script when you write to the variable.  The script will stop firing when the variable is returned to the matching value.

    I created a Boolean layout variable (Lyt.Bool_Test) that will increment a number every time the script fires.  I added an "if" statement and I don't return a value until the number reaches 10.

    On a display, I have a datalink that allows me to write to the Bool_Test variable and view the Num_Test variable.  Two observations:

    - the number will increment every second, which tells me the script fires every second or so until it is equal to the configured default, which is a standard value.

    - the Bool_Test variable indicates an error after two executions where it did not perform the Return function.  Eventually the value reaches 10 and the script returns the TRUE and the script stops running.

     The Red Heart Errors will detect an error on the datalink that a value has returned a bad status.

    I added a Return false to the script so that on every execution, the script returns a value.  While counting, it returns 0, which allows the script to continue firing every second.  

    My conclusion....

    The OnWrite script of a variable can be triggered by altering either the animated source value or by modifying the Variable.  

    A Return function must be executed on every execution of the script to avoid a BAD status on the variable.

    The script can be allowed to run indefinitely by delaying resolution that makes the variable and source equal.

    Hope this helps.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Yes, that helps. And I will go for the GOOGLE-Online-Class ... ;-)

    brg

    Stefan Müllner
    Senior Plant Engineer - Automation & Systems

    METADYNEA AUSTRIA GmbH