In DeltaV, the Deviation alarms are suppressed on SP changes. Makes sense, as one would receive the alarm every SP change. The Deviation alarm is enabled when the PV is within the deviation limits.
However, we just ran into an issue where the PV never came within the Deviation limits, and we never got the deviation alarm. The PV was still higher than our low alarm, but the PV never came within deviation to enable the deviation alarm.
This ruined our product.
Any methods out there to re-enable this after a SP change? Maybe 5-10 seconds after a SP change?
Is it alarm suppression or alarm disabled, because it doesn't show on our suppressed alarms list?
Do you have hysteresis configured as non-zero? If yes then that will affect Deviation alarm limits.
In reply to Lun.Raznik:
The HYS configured is 0.5 but only comes into play if the conditional alarm detection is enabled, which it isn't. If you look at "Deviation Alarming" in Books-OnLine, it explains the issue...which is a problem for us. What I don't understand is that our controller is in RCAS, then we change the SP. The information on BOL makes it appear that this calculation is not performed when in RCAS....but we see it happening.
In reply to mtbe:
"The HYS configured is 0.5 but only comes into play if the conditional alarm detection is enabled, which it isn't."
Conditional alarming can be enabled for all alarms configured for say a function block. It is disabled by default. It is also my understanding that HYS is applied to all alarm configured.
If you look at "Deviation Alarming" in Books-OnLine
Reading books online, it seems like it is behaving as documented. Since the SP-PV never goes below Deviation limits, devition alarming didn't get re-armed.
I can see the issue now in your specific application but what would be a good expection for the block behavior here? Like maybe a time delay override to re-arm deviation alarming on SP change?
This takes me back to a call I logged in 2006.
If you are dealing with a PID block, the full description of deviation alarming is actually a better one than on the deviation alarming article. It says:
Deviation alarms are suppressed on SP changes. When the PV comes within the deviation limits or if the status of OUT or BKCAL_IN becomes limited, the deviation alarm is enabled again
http://www3.emersonprocess.com/systems/support/bol123/extfile/function_blocks/c_pid_function_block_alarm_detection.html
So the question is, did your control output become limited while you were out of deviation due to setpoint change? If it didn't then DeltaV thinks the PID algorithm is still trying to work out the error through control action. Once the PID control action becomes limited, DeltaV recognizes that the error is irreconcilable, and re-arms the deviation alarm.
So perhaps at the root, the PID tuning is not aggresive enough to become limited within the time needed to recognize that a SP change has yielded an ineffective control response.
If this assessment is too much trouble, then the typical remediation is to put logic to disable and re-enable the alarm after a configurable time delay OR once the error is within deviation alarm limit.
In reply to Youssef.El-Bahtimy:
It seems to me he is using using the block in very intersting ways as well. The block was in RCAS and yet the SP was also changed. If the block is in RCAS, the setpoint will be coming from RCAS_IN. Or I might not be totally understanding RCAS mode.