Configuring Siemens S7 Totalizer FB100 for Multiple Flow Meters

Overview of the S7 Standard Totalizer Block

The Siemens SIMATIC S7-300 and S7-400 CPU families ship with a pre-engineered totalizer function block in the Standard Library → TI-S7 Converting Blocks collection. The block is normally referenced as FB100 with its associated instance DB100 and is engineered specifically for cyclic-interrupt (OB3x) execution. Its purpose is to integrate a process variable — typically a flow rate in m³/h, L/min, or kg/h — into a running total expressed in the same engineering units over a defined INTERVAL window.

The integration formula implemented by the block follows the classical rectangular-rule approximation:

Where CYCLE and INTERVAL are both TIME-format inputs. The block samples VALUE every CYCLE period, multiplies by the ratio CYCLE / INTERVAL, and adds the contribution to Q_OUT. This rectilinear integration approximates the area under the process curve between successive calls.

The default FB100/DB100 binding is a single-instance relationship, meaning each call to FB100 reuses the same instance data block. When four flow meters must be totalized independently with four distinct accumulator addresses, the standard library block alone does not support four parallel integrations. The instance data must be separated.

Problem Definition: Totalizing Four Flow Meters in Parallel

A common field requirement is to totalize four independent flow meters on a single S7-300 CPU (e.g. CPU 317-2DP, order number 6ES7317-2AK14-0AB0) while keeping each accumulator value isolated to its own data word. The single-instance block cannot deliver four independent totals from one DB100, because every call would overwrite the previous accumulator state.

Three engineering approaches are available, in order of preference:

1. Multiple background DBs — simplest approach. Call FB100 four times in separate networks and assign a distinct instance DB to each call (DB100, DB101, DB102, DB103).
2. Multi-instance encapsulation. Wrap FB100 calls inside a higher-level parent FB so that the parent FB owns the four instance DBs and the calling OB sees a single block interface.
3. Re-implement the integrator in SCL/ST. Build a custom block with explicit LREAL (64-bit) accumulators when the 32-bit REAL precision is insufficient for high-rate, long-interval applications.

Prerequisites

Before applying any of the procedures below, verify that the following items are available and configured:

• STEP 7 V5.5 or TIA Portal V15 or later, with the Standard Library → TI-S7 Converting Blocks registered in the project.
• An S7-300 CPU whose OB35 cyclic interrupt is configured. In HW Config, OB35 default scan time is 100 ms; this value can be increased to 1 000 ms or reduced to 1 ms minimum depending on the CPU type.
• Four 4–20 mA (or 0–10 V) flow-meter signals wired to AI modules (e.g. SM 331, 6ES7331-7KF02-0AB0) and scaled to engineering units before being passed to FB100.
• Per-meter scaling FCs (FC105 / FC106) or equivalent, ensuring that the VALUE input falls in the range 0.0 ≤ VALUE ≤ 1.0E+4 for 32-bit REAL precision.
• A monitoring path: either a VAT table in STEP 7, a WinCC flexible / TIA WinCC tag connection, or a Web server variable for on-line viewing.

Step-by-Step: Multiple-Instance Configuration

Step 1 — Configure OB35 scan period

Open HW Config and double-click the CPU. Navigate to Cyclic Interrupts. Set OB35 execution time to 100 ms unless a faster rate is required. The value displayed is the cyclic-interrupt period that OB35 will trigger at; this is the value that must be entered into the CYCLE input of FB100.

Step 2 — Insert the four FB calls in OB35

Open OB35 in LAD or FBD and create four networks. In each network insert FB100 and assign a unique instance DB:

Network 1:  FB100  "TOTAL_1"   DB100
  VALUE    := MD100      // flow rate, m³/h, meter 1
  INTERVAL := T#1h
  CYCLE    := T#100ms
  COM_RST  := FALSE
  Q_OUT    := MD200      // accumulator, m³, meter 1

Network 2:  FB100  "TOTAL_2"   DB101
  VALUE    := MD104      // flow rate, m³/h, meter 2
  INTERVAL := T#1h
  CYCLE    := T#100ms
  COM_RST  := FALSE
  Q_OUT    := MD204      // accumulator, m³, meter 2

Network 3:  FB100  "TOTAL_3"   DB102
  VALUE    := MD108      // flow rate, m³/h, meter 3
  INTERVAL := T#1h
  CYCLE    := T#100ms
  COM_RST  := FALSE
  Q_OUT    := MD208      // accumulator, m³, meter 3

Network 4:  FB100  "TOTAL_4"   DB103
  VALUE    := MD112      // flow rate, m³/h, meter 4
  INTERVAL := T#1h
  CYCLE    := T#100ms
  COM_RST  := FALSE
  Q_OUT    := MD212      // accumulator, m³, meter 4

When the first call to FB100 is inserted, STEP 7 prompts the user to generate the instance DB — click Yes and accept DB100. Repeat for each subsequent call, manually renaming the DB instance (DB101, DB102, DB103) before confirming. Do not reuse DB100 across the four calls: this would cause all four accumulators to overwrite each other.

Step 3 — Optional: encapsulate in a multi-instance parent FB

For larger programs where OB35 should not carry application logic, create a parent FB (e.g. FB200 — FLOW_TOTALIZER_4CH) with four static instances of FB100. In the parent FB's STAT section, declare:

VAR
  TOTALIZER_1 : FB100;   // multi-instance, no separate DB
  TOTALIZER_2 : FB100;
  TOTALIZER_3 : FB100;
  TOTALIZER_4 : FB100;
END_VAR

OB35 then contains a single call to FB200 with DB200, dramatically simplifying the OB35 view. All four instances live inside DB200 as a single multi-instance DB. This is the recommended pattern for production systems that will be expanded beyond four channels.

CYCLE and INTERVAL Timing Relationships

The relationship between the OB35 hardware period, the CYCLE input, and the INTERVAL input is the most common source of integrator error. The CYCLE value is the elapsed time between two successive calls to the totalizer; it must equal the OB35 interrupt period exactly. The INTERVAL value is the total time over which accumulation is desired.

The dimensionally correct rule is:

For VALUE = 60 m³/h, INTERVAL = T#1h, CYCLE = T#100ms, after one hour of continuous operation Q_OUT should reach exactly 60.0 m³. A reported value of 120 m³ after one hour indicates that CYCLE is being interpreted at half its intended duration, typically because the user entered T#100ms while OB35 was actually running at a different period — or because the simulator's clock resolution differs from the real CPU's tick counter.

Floating-Point Precision and the 64-Bit Real Library

FB100 uses 32-bit IEEE-754 single-precision REAL arithmetic. The single-precision mantissa is 23 bits, providing roughly 7 decimal digits of significant precision. For very small incremental additions to very large totals, the round-off error dominates the calculation. The classic case is adding 60.0 m³/h × 100 ms / 3,600,000 ms = 0.001667 m³ per call into an accumulator that has already reached 50.0 m³. The relative resolution at that point is approximately 3.3E-5, near the IEEE-754 noise floor.

Siemens provides a 64-bit real (LREAL) replacement for totalization on the S7-300 family via the open-source library OBS_DOLPHIN_S7_300_64BIT. The block preserves LREAL accumulators in a separate DB and re-implements the rectangular integration at 64-bit precision.

Recommended input scaling to keep FB100 in its precision sweet spot

Pre-scale the engineering value so that the working range is bounded by approximately 0.0 ≤ VALUE ≤ 1.0E+4. For example, a flow rate that physically reaches 1,200 m³/h should be expressed as 12.00 with an implicit ×100 multiplier stored in the documentation. This keeps the IEEE-754 spacing tight and avoids the upper-precision-degradation plateau that begins around 1.0E+7.

Input Filtering and Process Fluctuation

Raw flow-meter signals typically include a 1–5 % ripple from pump pulsation, valve cycling, or vortex shedding. When this ripple is passed directly into FB100 the totalizer advances in small jittery increments; the average matches the true flow, but the displayed total at any given moment differs by the instantaneous error.

Implement a first-order lag filter on VALUE before the FB call:

// In a separate FC called once per OB35:
MD_FILTERED := MD_FILTERED + (MD_RAW - MD_FILTERED) / TAU;
// where TAU is the filter time constant in calls (e.g. 20 for 2 s at 100 ms OB35)

A TAU value of 10–30 calls typically reduces ripple below 0.5 % of full scale while introducing a phase lag that is acceptable for hourly totals.

COM_RST and Reset Behaviour

The COM_RST input forces a complete restart of the integrator. Setting COM_RST := TRUE zeroes Q_OUT on the next call and latches the reset state until COM_RST returns to FALSE. The recommended pattern for operator-driven reset is a rising-edge trigger:

// Reset logic in OB1 (one scan per operator press)
FP_RESET := RESET_PB AND NOT RESET_OLD;
RESET_OLD := RESET_PB;

// In OB35:
FB100 call COM_RST := FP_RESET_OR_OP_PANEL;

A common commissioning error is to leave COM_RST tied to a level signal rather than an edge. If the operator holds the reset button, the integrator is forced to zero for the entire button-press duration, and the first half-second of flow after release is lost.

PLCSIM vs Real CPU Discrepancy

A frequently reported symptom is that the totalizer behaves correctly in PLCSIM but reports inflated or unstable values on the real CPU. Three root causes are most common:

Verification Procedure

1. Static verification (no flow): With all four flow meters isolated, force VALUE := 0.0 at the FB inputs. Run OB35 for one hour. Each Q_OUT must remain at 0.000.
2. Constant-input test: Force VALUE := 10.0, INTERVAL := T#1m, CYCLE := T#100ms. After one minute, each Q_OUT must reach 10.000 ± 0.001. If a value is significantly off, the CYCLE parameter is wrong.
3. Dynamic test: Apply a known flow (e.g. calibration rig at 60.0 m³/h). Run for one hour with INTERVAL := T#1h. Q_OUT must read 60.0 ± 0.05 m³.
4. Independence test: Apply different flows to each meter (e.g. 60, 45, 80, 30 m³/h). Run for one hour. Each Q_OUT must reach its individual setpoint, with no cross-channel influence visible in the VAT table.
5. Reset test: Trigger COM_RST for one network only. The corresponding Q_OUT must drop to 0.000 within the next OB35 call; the other three totals must continue accumulating without disturbance.
6. CPU diagnostic buffer check: Open PLC → Diagnostic Buffer in STEP 7. Confirm zero OB35 overrun errors. An OB35 overrun indicates that the cycle is too fast for the program length; extend the OB35 period or move logic to OB1.

Common Error Codes and Field-Notes

Field-Commissioning Summary

Four-channel totalization on the S7-300 is mechanically straightforward once three discipline rules are enforced: (1) every FB100 call receives a distinct instance DB, (2) the CYCLE TIME value is dimensionally identical to the OB35 hardware period, and (3) the VALUE input is pre-conditioned by both a scaling FC and a first-order filter. Floating-point edge cases are handled by switching to the 64-bit LREAL library only when the application demands it — hourly or shift-level totals on 32-bit REAL are reliably within tolerance on any current-generation CPU.

For additional reference, the SIMATIC S7-300 CPU 31xC and CPU 31x operating instructions document OB35 configuration, and the STEP 7 Standard Library reference manual documents the TI-S7 Converting Blocks collection. Both are available via the Siemens Industry Online Support portal at support.industry.siemens.com.