• State Verified Answer
  • Replies 4 replies
  • Subscribers 5479 subscribers
  • Views 10331 views
  • Users 0 members are here
Recent DeltaV Community Connect Discussions
Similar Posts
Equipment Module State - Selective Operator Access
State driven EM execution order per state
State driven equipment module - detecting error after state change complete
Integer value to states
DCC Interlock state
Share

FORCE_SP Operation state

I want to know if my EDC is being forced. There are three things i have to reference, EDC/FORCE_SP, EDC/MODE and the device options for 'Force_SP in CAS' and 'Force_SP in AUTO'. I can write a function to do so. Then I will also need to figure out the Device Opts bit string (probably trivial). 

Regardless, I'd rather just look at a different parameter, but I"m not sure if there is one. OPERATION_STATE is useful to know if I'm Interlocked or if No Permissive is true. But, it doesn't look like it contains a value for forced SP specifically.

THanks

TreyB
  • JDWheelis
    As I understand it, when the condition of a Force SP of an EDC block becomes true, the SP (Auto mode) or CAS_SP (CAS mode) is "forced" to the configured SP value in a "one-shot" fashion. Once the SP is written and the EDC block implements it, I am not aware that the state of the EDC which then exists differs from the state that would exist if the SP or CAS_SP were changed by an operator or sequential code.

    Now, if you are attempting to determine during the (short) time that the EDC block is responding the DCC block's condition expression which initiates the force SP, doing so could be tricky to catch due to the short time the EDC block needs to respond and implement the force SP.

    Can you describe what is the need that drove your question? In other words, what problem are you needing to solve?
  • TreyB

    In reply to JDWheelis:

    i wanted it as an Icon indicator for a GEM.
  • Andre Dicaire

    In reply to TreyB:

    Force SP is a one shot deal. The triggering condition may still be true, but the EDC SP_D is free to be moved by the operator or by sequential logic. It would be problematic to have continuous writes to the CAS_IN_D or SP_D in CAS or AUTO, as these would undo the force write. The purpose of Force is to allow for some automatic actions on the EDC to support the Operator. LIke a Sump that needs to start on high level and stop on low level, but could be acted upon by the operator as needed. So there is no continuous force condition, except via an interlock.

    So are you wanting to indicate to the Operator that the last SP change was the result of a Force Setpoint write? Maybe that tells him why the motor is no longer running.

    If the Force SP expression can only go true if conditions are right for it to take action, and this is latched true until say the motor changes state. Maybe the state of the FORCE SP condition can be used? I I.e. ((Level <= 10) And (Motor <> STop)) OR ((FORCE_SP i = true) AND (Motor = stop)).

    The Force SP will ignore the force condition if the motor is stopped. If force condition is true, it is latched latched till the motor is started.

    Or something similar. Haven't tried this, but it creates a pulse state on the Force SP based a valid trap/clear condition. Another way is to break the FORCE condition out to create logic that goes true and clears and then use that bit in the Force Expression. Your icon follows the state of the logic. I used something similar in a CND block to apply a hysterysis on an analog trip, latching the trip condition with the CND output that cleared based on the second trip point. Worked nicely and this is the same approach. Assuming you can define the logic that clears the latch condition.

    Andre Dicaire

  • TreyB

    In reply to Andre Dicaire:

    I see. I guess it works differently than i thought. I didn't quite realize that the ILK condition in the DCC was able to adjust a state. So, I can use that for both. I don't think i am interested in knowing if the equipment was previously one shotted. At least not on the graphic. I will just have to make sure there is a way of tracking those events.
    Permissives and Interlocks are all i really need for indications.. which explains probably why only those two icons were included on the OOB EDC Gem.

    Thanks

This is the official online community site of the Emerson Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson's products and services. Our goal is to improve the efficiency and use of automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.

Community Guidelines | Legal Information | Privacy Policy | Contact Community Manager

Website translation provided by Website Translator

© 2015-2026 Emerson Exchange. All rights reserved.