A cumulative energy channel reports the meter total since reset, but period consumption is the difference between two boundary readings. If the meter reads 82000 kWh at one daily boundary and 83000 kWh at the next, the completed-day consumption is 1000 kWh. The key design choice is whether the channel must contain completed-period values for archives and trends, a live period-to-date value for a mimic, or both.
Separate the meter total from period consumption
| Required value | Calculation | Update behavior |
|---|---|---|
| Cumulative meter total | Read the source energy channel directly | Changes as the meter accumulates energy |
| Completed-period consumption | Current boundary reading minus previous boundary reading | Written when the hour, day, or month starts |
| Period-to-date consumption | Current meter reading minus the reading saved at the current period boundary | Changes throughout the active period |
Do not add the cumulative source value to an hourly total. The source already represents all energy accumulated since the meter was reset; adding it repeatedly would not calculate consumption for the active period.
Choose the required channel behavior
The available approaches do not produce the same result:
| Approach | Supported result | Limitation |
|---|---|---|
| ModDiffCalculator | Calculates channel differences over a time period | Does not display a continuously increasing period-to-date difference |
| Boundary snapshot and subtraction | Records a completed-period difference at the boundary | Requires storage for the boundary reading and trigger state |
| Live subtraction from the boundary value | Displays consumption from the boundary to the present | If archived in the same channel, intermediate values can produce a rising or sawtooth trend instead of boundary-only values |
One channel therefore cannot safely be assumed to provide both a live period-to-date display and an archive containing only completed-period points. The evidence does not establish a mechanism that changes the current value without affecting archived minute data or the behavior of PrevVal and PrevData.
Capture and calculate a completed-period difference
The demonstrated script design uses three channels: a period-start trigger, a saved meter reading, and a calculated difference. In the example, channel 327 is the cumulative energy source.
- Generate a boundary indication with
HourStarted()orDayStarted().MonthStarted()was proposed for monthly operation, but its availability must be verified in the installed environment. - When the boundary starts, copy the cumulative reading into the saved-value channel. If the calculated channel has no valid status after server startup, mark the captured value with status
4, meaning that the value is defined but unreliable. - Subtract the previous saved reading from the new saved reading and assign the previous saved status to the result.
public CnlData IfStart(int started, int curVal)
{
if (Stat() < 1)
return NewData(Val(curVal), 4);
if (Val(started) > 0)
return NewData(Val(curVal), Stat(curVal));
return Data();
}
public CnlData DivIfStart(int started, int lastVal)
{
if (Val(started) > 0)
{
double div = Val(lastVal) - PrevVal(lastVal);
return NewData(div, PrevStat(lastVal));
}
return Data();
}
Configure the saved-value channel with IfStart(X, 327) and the result channel with DivIfStart(X, X+1), where X is the trigger channel. This records the difference only when the selected period starts.
Handle server startup and incomplete periods
After a server restart during an hour, day, or month, the system may lack a trustworthy reading from the true period boundary. The supplied logic returns the current source reading with status 4 when Stat() is less than 1. Treat the resulting period as incomplete until two valid boundary snapshots are available.
A live period-to-date calculation also requires the reading captured at the active period boundary. If that snapshot was not retained through restart, the full consumption since the actual boundary cannot be reconstructed from the current cumulative reading alone.
Verify calculation and trend behavior
- At a known boundary, confirm that the saved-value channel equals the cumulative source reading and carries the source status.
- At the next boundary, confirm that the result equals the new snapshot minus the previous snapshot. Readings of 82000 kWh and 83000 kWh must produce 1000 kWh.
- Restart the server inside a period and confirm that an unavailable boundary context is identified with status
4rather than presented as a complete period. - Inspect minute and boundary archives separately. A completed-period channel should change at boundaries; a live period-to-date channel will change inside the period.
- If Graph Pro does not connect hourly difference points, do not assume that changing
GapBetweenPointsalone solves the issue. Values of3600,3700, and5400were reported as ineffective, so verify the actual timestamps and graph data-selection behavior before changing that setting again.
FAQ
How do I calculate daily energy consumption from a cumulative Rapid SCADA channel?
Save the cumulative reading at consecutive daily boundaries and subtract the previous snapshot from the current snapshot. A change from 82000 kWh to 83000 kWh produces 1000 kWh for the completed day.
Can ModDiffCalculator show energy consumed since the start of the current period?
No. The supplied evidence states that ModDiffCalculator calculates a difference over a period but does not show a continuously increasing period-to-date difference.
Why is status 4 used after a Rapid SCADA server restart?
The demonstrated logic uses status 4 when Stat() is less than 1 to mark a defined but unreliable value. This prevents an incomplete post-restart period from being treated as a valid full-period difference.