Hello,
Our interlocks are configured in DCS with a condition block (CND)---->Boolean Fan Input (BFI)-----> final element (trip valve, motor, etc.).
I would like to view in either Event Chronicle or excel Spread Sheet when a CND block for all modules is evaluted true. I am trying to provide a list for when any interlock on the system is activated to view monthly or daily.
Thank you for the help in advance.
The activation of a CND block itself is not captured in event chronicle, so you will have to tie an alarm to the action you want.
I'm not suggesting you create an visible alarm for every single CND block, but rather you create a log level or else self acknowledging low priority alarm that triggers based on the BFI/FIRST_OUT > 0.
This log alarm will appear in event chronicle but not in alarm banner, and will record the value of the FIRST_OUT in the alarm limit column. It should be easy to update module classes to add this new alarm to all instances.
If you really don't want to change existing modules, you can create new monitoring modules that look at the BFI on each equipment-type module, but this will probably be a more challenging undertaking.
In reply to Youssef.El-Bahtimy:
The higher the granularity you want on this request, the harder this request becomes.
If you want to easily see which condition is causing the interlock, the best method would probably be to:
The easier method in which Youssef describes and probably what most people do is:
This Log alarm would then go off and capture what the FIRST_OUT indication was when the Interlock occurred. Now you will also need to ensure that the FIRST_OUT is getting reset and ARM_TRAP is getting set within your control scheme so that you have a good/true indication of an interlock occurring. Someone will still have to interrogate the decimal number to determine the condition(s) that caused the interlock because you would see Module Interlocked – 37 in the event chronicle as an example.
Regards,
Matt
I have made an Interlock Bypass Summary graphics page for our system. I use a sub on the detail plate graphics page in the "click" for the bypass/unbypass function. The subroutine gleans a variety of data with the click (ie - timestamp, username, interlock description, module name and workstation name). The data gets populated to a database I set up on our AppStation that parses through the info gets the current state of interlocks and displays the active ones. I've built an html viewer as well with a variety of search and filter functions for our production supervisors and managers so they can go through the data more effectively. Something like this could be tweaked to run when the interlock active state change occurs.
In reply to Matt Stoner:
Matt Stoner said: The easier method in which Youssef describes and probably what most people do is: Add an Alarm Type that has a message like “Module Interlocked - %P1”. Add an alarm of log priority using the alarm type from above in the module that is triggered off the BFI/OUT_D parameter and enabled. On the advanced tab of the alarm configuration you can configure “Message parameter 1” to be BFI/FIRST_OUT. This Log alarm would then go off and capture what the FIRST_OUT indication was when the Interlock occurred. Now you will also need to ensure that the FIRST_OUT is getting reset and ARM_TRAP is getting set within your control scheme so that you have a good/true indication of an interlock occurring. Someone will still have to interrogate the decimal number to determine the condition(s) that caused the interlock because you would see Module Interlocked – 37 in the event chronicle as an example. Regards, Matt
Thank you so much Matt and everyone help
I am bit confused about how to determine which CND block trrigered the BFI/OUT_D.
It may be easier for me to setup alarm log for each CND block CND/OUT_D. This way I know which CND block triggered the interlock in Event Chronicle.
Thank you.
In reply to DCS Newbie:
Like Matt explains the BFI block has a FIRST_OUT (binary weighted) parameter that indicates which input on the BFI became active first (i.e. 1 = in1, 2 = in2, 4=in3, 8=in4, etc.) So no need to add logic for every individual CND block. You do need to reset the first_out parameter after it was triggered. Alarm with LOG priority works excellent for tracking events like this.
In reply to lazy_engineer:
Thank you Matt and other for the help. I am still learning.
I have a test controller, I am setting up so I can pracitice and understand the BFI and its parameters. I would like to use the BFI to know which CND (condtions) cause the interlock.
I have 4 CNDs and a BFI. The BFI/Out is connected to a DC1, device control block.
I will simulate CND/OUT to activate the BFI.
1. What is theRESET, ARM_TRP, and OUT_INT used for and how do I configure it for this example to practice?
I will use the FIRST_OUT as Matt described to let me know which inputs caused the trips.
Thanks for your help.
Here are the definitions from Books Online:
ARM_TRAP - When non-zero, ARM_TRAP enables the first out trap mechanismOUT_INT - The unsigned 32-bit binary weighted output value that represents the bit combination of the inputsRESET_IN - When non-zero, RESET_IN clears FIRST_OUT. The block sets RESET_IN back to zero at the end of each scan. RESET_IN does not re-arm the trap. FIRST_OUT remains cleared until one or more inputs are set after all inputs are zero.
Now as far as your configuration and our suggestion, not sure how the rest of your module is configured but I have done this quick config to demonstrate.
The ACT1 Expression is:
IF '^/BFI1/FIRST_OUT.CV' <> 0THEN '^/BFI1/RESET_IN.CV' := TRUE;ENDIF;
So this configuration will trap the first interlock to cause the device to interlock from an active state and a log alarm will generate this occurrance. The problem is that because we are using BFI1/OUT_D to trigger the alarm, interlocks could clear and then re-activate which would cause the alarm to clear and re-trigger but the same First Out would be indicated but it really only happened once.
If you wanted to only have one occurrance to only occur on the actual interlock occurance, you can add a condition block (have it execute after the BFI block, change the Interlock Alarm to look at this new condition block OUT_D and configure the expression to be:
('^/BFI1/ARM_TRAP.CV' <> 0) AND ('^/BFI1/OUT_D.CV' = TRUE)
Now the issue with this is that because we are using the ARM_TRAP signal which will be false on the next scan of the module, the alarm will clear as well so you won't get an accurate time/date of when it cleared but I most people only care about when the cause occurred and why.