Wednesday, August 3, 2016

Output Cusps - Exceptionally Artistic!

We came across the pretty but alarming output forms shown here at a client. The scale is one minute per cusp and just over 1% amplitude. This is important because it means that the HMI and historian would not see this at all. DBDOC Watch Window handles it nicely, as is evident.

So what is going on here?

The blue line is the output of a FC 80 Station block and the output cusps were, in fact, a significant issue. The green line is the raw PV input (nice and smooth). However, the APID block was being fed by an exception-reported version of the PV, shown in red. The significant change specification was 0.1%, so the exception-reported value actually was competently implemented, changing in steps, as expected.

The problem simply is that the APID algorithm used a derivative term. As the two diagrams make painfully obvious, this simply does not work. Although the PV signal is changing at a nice fairly constant rate, the controller, fed by the red step input, is hit with a huge change accumulated over one minute, but seen as happening in 250 ms. Thus, the derivative is calculated as being 240 times bigger than it actually is.

The second image shows that, if the PV is changing so that the exception reports are triggered by the significant change, the cusps are smaller, as they have a better time base. but they are still misleading and problematic.

The bottom line is that PID and APID algorithms should never use a derivative term if the PV is affected by an exception-reported input PV. It cannot work mathematically, and it sure kicks the process in the teeth, again and again.

DBDOC can't yet detect this error situation automatically, but we are working on it.  Stay tuned.


  1. That is terrible. DBDOC can detect it based on a few rules. Just flag potential problems by looking at the PV and the PID/APID devivative term. If the PV is from off module/pcu/loop and there is a value of derivative other than 0 then likely there will be problems.

    We try to avoid this by never putting the PV off module. Unfortunately all too often the CO is off module where we interface to the PLCs via comms. At least that is only steps.

  2. We have just finished the programming this check in DBDOC, which is not quite as easy as it might seem. A few rules is true, but you have to follow the chain of blocks feeding the PV past REDAI, transfer and other blocks to find it. This test will be in version 10.7 and includes adapted gain specs.

    PLCs brought into the same module on BASROQ blocks probably have the same problem, because they typically get a new value every n seconds. Take some value like 15 seconds and realize that a derivative specification will see all that change in 250 ms (typically) and give 60 times the "kick". Guess we better add more logic, eh?

  3. The new code to detect these found 664 of these in 89 of 199 projects checked. Clearly, it is potentially a serious issue.

    I am in the process of sending the instances found to people for them to check for bad effects.