Digital Panel Meter for Batch Controller Pulse Input Applications P/N L70405FR

Batch Controller Digital Panel Meter Frequently Asked Questions

Why does the batch controller apply the same physical signal to both Channel A and Channel B rather than using two separate sensors?

Documented setup specifically applies the same turbine flow meter signal in parallel to both channels — since totalizing and rate calculation are computed differently internally (accumulated count versus inverse-period timing), running both calculations from the same underlying pulse stream lets one flow sensor simultaneously support both the batch total and the live fill rate, without needing a second sensor.

Can Item #2 track grand total and number of batches simultaneously, or is it one or the other?

Documented capability specifically describes Item #2 as selectable during setup to be either grand total or number of batches — meaning it's one assignment at a time rather than tracking both simultaneously; an application needing both values would need to use Item #2 for one and find another way (such as calculating batches from grand total divided by typical batch size) for the other.

Does assigning Relay #2 to a pre-warn function on Item #1 require it to use the same preset value as Relay #1's batch-complete setpoint?

No — the documented pre-warn example specifically uses a lower setpoint than the main batch relay's target, intentionally triggering earlier so the fill can slow down before reaching the final batch total; Relay #2's setpoint on Item #1 is independently configurable from Relay #1's batch-complete setpoint.

If a fourth relay is available, does it have to be assigned to a genuinely different item than the other three relays?

Documented flexibility specifically states relays #2, #3, and #4 can each be assigned by the user to Items #1, #2, or #3 — there's no documented requirement that each relay track a different item; a fourth relay could, for example, provide a second alarm threshold on the same item Relay #2 already monitors, if that's what an application needs.

Does the peak value transmitted for Item #3 represent the peak rate during the current batch, or an all-time peak?

Documented capability specifically states the optional serial communications board can transmit peak for Item #3 (rate) alongside Items #1, #2, and #3 themselves — the specific peak-tracking window (per-batch versus cumulative) isn't detailed on this page, so confirming that behavior against the counter's documented peak/valley capture settings is worth doing if the distinction matters for a given application.

Can up-counting and down-counting batch control both use the same prewarn relay concept, or is prewarn only available for one counting direction?

Both documented modes specifically include a prewarn capability — up-counting batch control documents a prewarn level to slow filling near the preset maximum, while down-counting batch control documents an equivalent prewarn level to slow filling or emptying near zero; the underlying concept works symmetrically for either counting direction.

In the discrete filling and batch counting example, does the Grand Total need to be reconfigured to switch between tracking bottles and tracking six-packs?

Yes, in effect — Grand Total is documented as being usable to track either bottles or six-packs in that specific example, which implies it's configured for one or the other based on which item and scaling the application assigns to it; switching what physical quantity it represents would mean reconfiguring which count (individual bottles versus grouped six-packs) feeds that specific tracked total.

Does the delay-between-batches setting and the external-control-input start option work together, or are they mutually exclusive ways to trigger the next fill?

Documented capability describes fill operations as repeating continually with a programmable delay, or based on an external control input — this is presented as a choice between two triggering methods for starting the next batch cycle, rather than both operating simultaneously; an application would configure the meter for one triggering method or the other depending on whether batches should proceed automatically on a timer or wait for an external signal.

Does Channel A's totalizing function stop updating while Channel B is busy calculating rate, or do both run continuously and independently?

Documented architecture specifically describes Channels A and B as used independently even though they share the same input signal — Channel A's totalizing and Channel B's inverse-period rate calculation are separate, parallel processes rather than a shared computation the meter alternates between, so both the running batch total and the live rate continue updating simultaneously.

Can the delay between batches be set differently for different batch sizes, or is it a single fixed setting for all cycles run on that meter?

The documented delay-between-batches setting (10 ms to 199.99 s) is a single configured value applied between cycles — it's not documented as varying automatically based on the batch size just completed, so an application needing different pause durations for different product runs would need to reconfigure that setting when switching between batch types, rather than expecting the meter to adjust it automatically.

Turbine Flow Meter K-Factor & Calibration Questions From the Field

What exactly is a turbine flow meter's K-factor, and how is it actually determined?

Documented explanation specifically defines K-factor as the number of pulses generated per unit of volume passing through the meter — determined by passing a known quantity of fluid through the meter at a given flow rate, counting the total pulses generated, and dividing pulses by that known volume, producing a calibration constant unique to that individual meter.

Is a turbine flow meter's K-factor genuinely constant across its entire rated flow range?

Not entirely — documented analysis specifically describes the meter's response as having a linear section (roughly two-thirds of its working range, with characteristics tied to sensor geometry and fluid viscosity) and a nonlinear section, where bearing friction and fluid viscous resistance have a greater effect — for the highest-accuracy or custody-transfer applications, documented practice specifically applies a multi-point linearization curve with several K-factors across the range rather than a single constant value.

Does entering the wrong K-factor into a batch controller cause a random, unpredictable error, or a specific, calculable one?

A specific, calculable error — since K-factor is a direct multiplier converting raw pulse count into volume, a K-factor mismatch produces a proportional, systematic under- or over-reporting of every batch total, documented as directly affecting dosing accuracy, inventory management, and regulatory compliance rather than introducing random noise.

Can a turbine meter's K-factor genuinely drift or change over the life of the installed meter?

Yes — documented field examples specifically describe a real fuel distribution terminal that discovered an average 1.5% discrepancy between delivered and billed volumes on high-precision turbine meters after 18 months of continuous operation, illustrating that K-factor stability isn't guaranteed indefinitely and periodic verification remains genuinely important even for well-regarded meter technology.

What documented installation or maintenance practices specifically help preserve a turbine meter's K-factor accuracy over time?

Documented best practices specifically include using clean, filtered, or strainer-conditioned flow to prevent rotor fouling and bearing damage, maintaining the manufacturer's recommended straight-run pipe lengths upstream and downstream to avoid a distorted flow profile, and re-verifying calibration specifically after any cleaning, repair, or exposure to abnormal operating conditions before returning the meter to service.

Does the turndown ratio of a turbine flow meter affect how reliable its K-factor is at low flow rates within that meter's rated range?

Yes — documented specification cites turbine meters as inherently linear within a known turndown range, commonly around 15:1, based on fluid velocity through the meter; operating meaningfully outside that documented turndown range pushes the meter into its nonlinear response region, where the single-point K-factor becomes progressively less representative of actual flow.

Is it accurate to assume two turbine meters of the identical model and size share the exact same K-factor?

No — documented guidance specifically notes that while batch-produced meters of the same design are likely to have very similar K-factors, each individual meter's K-factor is unique to that specific device as measured on its own calibration certificate — using a generic, nameplate-style K-factor rather than the individually calibrated value for that specific meter introduces avoidable error.

Does distinguishing between "of full scale" (FSD) accuracy and "of reading" accuracy actually matter when comparing flow meters for a batch controller application?

Yes — documented industry commentary specifically flags this distinction as one suppliers don't always clarify, and notes that linearity-related reading accuracy has a particularly significant impact on flow meter performance at the low end of its flow range; understanding which accuracy convention a given meter's spec sheet is actually quoting matters specifically for applications with a wide operating flow range or frequent low-flow batches.