Delta DVP-26SE: Can X10 Inputs Count Flow Meter Pulses?

The panel looks fine. No fault light, no diagnostic bit, the counter in your program is incrementing, and the flow number on the HMI moves when the pump runs. Then someone compares your totalized volume against the reading on the flow meter's own display and you are 8% low. At low flow you match. At full flow you are 20% low. Nothing in the PLC is broken.

You are sampling a pulse train with a scan-based input. Every pulse shorter than one program scan is invisible, and the faster the flow, the more of them you drop.

Skip These Fixes First

These are the four things engineers try on a Delta DVP-26SE when a pulse-derived flow value reads low. None of them fix the mechanism.

Attempted fix	What you observe	Why it fails
Count rising edges of X10 inside a 1-minute timer window	Number looks stable, reads low and gets worse with flow	The input image is refreshed once per scan. A pulse that starts and ends between two refreshes never appears. Averaging a biased sample keeps the bias.
Scale the result with a correction factor from historical flow data	Matches at the flow you calibrated at, drifts everywhere else	The loss is a function of pulse rate, so it is flow-dependent and non-linear. One multiplier cannot track it.
Strip the program to shorten the scan	Small improvement, still short	Halving scan time roughly doubles the frequency you can survive. If the meter runs at hundreds of Hz you need two orders of magnitude, not two.
Reduce the X-input digital filter time to minimum	Marginal gain	The filter sets the minimum electrical pulse the hardware acknowledges, but the scan-based sampling above it is still the limit. Necessary, not sufficient.
Measure time between two pulses on a standard input	Flow value quantized in steps, reads garbage near zero flow	Timestamp resolution is one scan. Rate resolution collapses when the pulse period approaches the scan time, and the method has no way to output zero.

That last one deserves a note, because it is the one that looks clever. Period measurement is the right idea on hardware that can latch a timestamp. On a scan-refreshed input it just moves the aliasing from the count into the timebase.

Understand the Sampling Limit

A standard DVP input goes through three stages: input circuit and hardware filter, digital filter time, then the input image refresh at the top of each scan. Your ladder logic only ever sees the image table.

The capture rule that follows from that:

• A pulse must be electrically present for longer than the configured input filter time, or the hardware discards it as noise.
• It must then still be present at an input refresh, which means the practical minimum is pulse width ≥ 2 × worst-case scan time plus the filter delay. One times scan is a coin flip; two times is the working margin.
• The gap between pulses has to obey the same rule, or two pulses merge into one edge.

Worst-case scan is the number that matters, not average. A communication burst, a recipe move, or an alarm block firing on one scan is enough to swallow a pulse. Read the current and maximum scan time registers documented in the DVP programming manual and use the maximum, with margin.

Both counting schemes alias. Fixed-time counting misses pulses. Fixed-count timing quantizes the period. Neither method rescues you once the pulse rate approaches the scan rate, so the fix is always to change the pulse rate, the pulse width, or the input hardware.

Do the Pulse Budget Before You Write Any Code

Two numbers decide everything. Get them before you touch the program.

1. Read the meter's configured volume per pulse (V_p) and pulse width from its own setup menu. On a full-bore electromagnetic meter both are usually user-settable.
2. Take the maximum process flow rate Q_max in m³/h from the line sizing, not from today's operating point.
3. Compute worst-case pulse frequency: f_max [Hz] = Q_max / (3600 × V_p) with Q_max in m³/h and V_p in m³/pulse.
4. Compute the minimum period: T_min [ms] = 1000 / f_max. The meter's on-time is some fraction of that; a fixed-width output stays constant while the gap shrinks.
5. Compare against 2 × T_scan_max + T_filter.

If T_min is not comfortably larger than that sum across the whole flow range, standard inputs are out. Note also the output type: reed-relay pulse outputs bounce and are limited to a few Hz, while open-collector or transistor outputs are clean but fast. A bouncing contact double-counts, which hides the under-count and makes calibration look accidentally correct.

Option A: Slow the Meter Down

The cheapest fix costs no hardware. Go into the meter and increase the volume per pulse and the pulse width until the train fits inside your scan budget.

• Raise V_p so f_max drops to a few Hz. Ten times the volume per pulse means one tenth the frequency.
• Set the pulse width to at least twice your worst-case scan time, and confirm the meter can still complete the pulse before the next one is due at full flow. If width × f_max approaches 1.0, the output saturates and the meter starts truncating pulses on its own.
• Keep the standard input, keep the edge-triggered counter, and accumulate volume as count × V_p.

What you give up is rate resolution. With a large V_p, low flow produces a pulse every several minutes, so a derived flow rate updates far too slowly for closed-loop control or leak detection. This option is correct for totalizing and batch volume. It is the wrong option if the number feeds a PID.

Option B: Move the Wire to a High-Speed Input

This is the fix that works at any pulse rate, and it is what plants running this process have standardized on. High-speed counter channels latch edges in hardware, independent of the program scan, so scan time drops out of the problem entirely.

1. Check the DVP-26SE terminal-to-counter mapping in the hardware manual. High-speed counter channels are hard-wired to specific low-numbered X terminals. You cannot promote X10 to high-speed in software — the wire has to move.
2. Enable the counter with the high-speed counter instruction and set its enable bit, then confirm the counter's associated special bit is active. Delta also provides a direction bit that flips the counter to count down; that is what you use if the meter is wired for reverse-flow indication.
3. For flow rate, use SPD. It counts edges on the high-speed input over a sampling window you specify and returns the count for that window, which is exactly the fixed-time measurement you wanted — just with hardware capture behind it.
4. Derive rate from the SPD result: Q [m³/h] = (pulses_in_window × V_p × 3600) / T_window [s].
5. Totalize separately from the free-running high-speed counter, not from the SPD result, so window boundaries never lose a pulse from the total.

If the CPU's built-in high-speed channels are already committed to encoders or other duty, add a counter module. Integrating rate and total from one hardware counter is less code and less drift than two independent calculations.

Option C: Convert the Signal Before It Reaches the PLC

When only one flow signal is involved and the high-speed inputs are unavailable, a pulse-to-analog converter is a legitimate answer. The converter counts in its own hardware and outputs 4-20 mA proportional to frequency; you read it on an analog input and scale it like any other transmitter.

Better still, if the meter offers a 4-20 mA rate output natively, use it and keep the pulse output for totalizing only. A meter that reports a flow value directly removes the sampling problem instead of working around it.

Watch the converter's response time. Most apply a filter or averaging window of a second or more to get a stable current output, and that lag lands in your control loop. Check the specification before you put it inside a fast dosing or blending loop.

Build the Rate Calculation Correctly

Once the pulses are captured reliably, the arithmetic is straightforward — but two details bite people.

1. Period-based rate. Measuring the interval between pulses gives the fastest response at high flow. The general form is Q [m³/h] = V_p × 3,600,000 / T [ms]. The shorthand 3600 / T[ms] is only valid when the meter is configured for exactly 1 m³ per pulse. If V_p is 0.1 or 10 m³, that shortcut is off by a decade.
2. Zero-flow timeout. Period measurement can never produce a reading of zero, because zero flow means no pulse ever arrives. Run a watchdog timer that resets on every pulse; if it expires, force the rate to 0. Set the timeout longer than the pulse period at your minimum measurable flow, or you will chop the bottom of the range.
3. Hybrid the two. Use period measurement above the flow where pulses arrive faster than your update requirement, and fixed-window counting below it. Cross-fade between them rather than switching hard, so the trend does not step.
4. Guard the divide. Trap T = 0 and any negative interval caused by a timer rollover before the division executes.

Verify Against the Meter's Own Totalizer

Do not trust a number that only exists inside your PLC. The meter has already counted the water; use it as the reference.

1. Put a scope or logic analyzer across the input terminal and measure the actual pulse width and worst-case period at full flow. Confirm the width exceeds 2 × T_scan_max + T_filter. This single measurement settles the argument faster than any code review.
2. Log the maximum scan time register over a full production cycle, including communication load and alarm activity. Use that peak in the budget, not the idle value.
3. Compare deltas. Agreement should be within one pulse of resolution. If the error is near zero at low flow and grows with flow rate, you are still losing pulses — that pattern is the signature, and no scaling factor will fix it.
4. Inject a pulse train from a signal generator and sweep from a few Hz up past your calculated f_max. The frequency at which the PLC count starts diverging from the generator count is your real ceiling. Keep the operating maximum below half of it.
5. Check reverse and stopped conditions: with flow stopped, the rate must go to 0 within the watchdog period and the totalizer must not creep from electrical noise on the input.

If the pulse output frequency still cannot be reduced within the meter's own configuration limits, contact Octave through the meter supplier for the correct pulse-width and volume-per-pulse ranges for your firmware and output type. If the high-speed counter terminal mapping or the SPD sampling behavior on the DVP-26SE does not match what the programming manual states, raise it with Delta technical support with your scan-time log and scope capture attached. Do not spend another shift adjusting correction factors — a flow-dependent error is a capture problem, and it will not calibrate out.

FAQ