RamonDarios
Member
I have a question about the fine details of how the RSLogix ALM (Alarm) function block processes its Rate of Change calculation and in particular the ROCNegAlarm output.
There are two main configurable parameters that govern the rate of change calculation: 1. ROC period and 2. ROCNegLimit.
Quoting the reference manual (Publication 1756-RM006G-EN-P), ROCperiod is "the time period used to evaluate the rate-of-change alarms (in seconds)".
The ROC alarm calculates the rate-of-change as:
ROC = ( In(Now) - In(EndofpreviousROCPeriod) ) / ROCPeriod.
So, if In(Now) = 10 and In(EndofpreviousROCPeriod) = 11 and ROCPeriod = 100ms then ....
ROC = 10-11/(100/1000) = -10 units per second.
Simple.
But what if the function parameters are configured with a value of ROCPeriod that is LESS THAN the executing module's interval time? That is, what if the ROCPeriod is set to 50mS but is only executed once every 200mS?
The "ROCPeriod" will have expired on every execution of the module. But the module will not be able to determine the real value of In(EndofpreviousROCPeriod) because that was only 50mS ago, 150mS after the last execution of the function block. Will the value of In(Now) be equal to the value on the last scan (i.e. 200mS earlier)? If so, this will distort the ROC calculation for a signal that is changing continuously between the two scans. If this is how the function behaves, in the case of 50mS ROCPeriod and 200mS interval time it will quadruple the calculated rate of change.
If this is the case then it would appear to be best practice to always have the ROCPeriod 3 or more times the value of the execution interval time. Absolute minimum of 2 times.
Can anyone confirm if this is how the function block behaves? Or is there some "magic" behind the scenes that compensates for this scenario? Any links to official guidelines from Rockwell on such information?
Thanks in advance.
There are two main configurable parameters that govern the rate of change calculation: 1. ROC period and 2. ROCNegLimit.
Quoting the reference manual (Publication 1756-RM006G-EN-P), ROCperiod is "the time period used to evaluate the rate-of-change alarms (in seconds)".
The ROC alarm calculates the rate-of-change as:
ROC = ( In(Now) - In(EndofpreviousROCPeriod) ) / ROCPeriod.
So, if In(Now) = 10 and In(EndofpreviousROCPeriod) = 11 and ROCPeriod = 100ms then ....
ROC = 10-11/(100/1000) = -10 units per second.
Simple.
But what if the function parameters are configured with a value of ROCPeriod that is LESS THAN the executing module's interval time? That is, what if the ROCPeriod is set to 50mS but is only executed once every 200mS?
The "ROCPeriod" will have expired on every execution of the module. But the module will not be able to determine the real value of In(EndofpreviousROCPeriod) because that was only 50mS ago, 150mS after the last execution of the function block. Will the value of In(Now) be equal to the value on the last scan (i.e. 200mS earlier)? If so, this will distort the ROC calculation for a signal that is changing continuously between the two scans. If this is how the function behaves, in the case of 50mS ROCPeriod and 200mS interval time it will quadruple the calculated rate of change.
If this is the case then it would appear to be best practice to always have the ROCPeriod 3 or more times the value of the execution interval time. Absolute minimum of 2 times.
Can anyone confirm if this is how the function block behaves? Or is there some "magic" behind the scenes that compensates for this scenario? Any links to official guidelines from Rockwell on such information?
Thanks in advance.
