Panel Meters for Batch Controller Pulse Input Applications P/N L8021DFR

Batch Controller Panel Meter Frequently Asked Questions

Why does Channel A handle totalizing while Channel B handles rate, when the same signal feeds both?

Splitting the single incoming pulse signal across two independently configured channels lets the meter apply two genuinely different measurement techniques simultaneously — Channel A simply accumulates pulses mathematically for total, while Channel B applies the inverse-period timing technique specifically to derive rate, which requires different internal processing than raw accumulation. Feeding the same physical signal to both avoids needing two separate sensors.

Can I reassign which relay handles the pre-warn function, or is Relay #2 always fixed to that role?

Relay assignment is documented as user-configurable — Relays #2, #3, and #4 can each be assigned by the user to Item #1, #2, or #3, so pre-warn is a documented example use of Relay #2 rather than a fixed, unchangeable role; the same flexibility lets a different relay be assigned to pre-warn, or a relay be assigned to an entirely different alarm function instead.

Do I need three separate remote displays to see all of rate, batch total, and grand total simultaneously, or can the controller itself cycle through them?

Both options exist — the controller itself can display any of the three tracked items on its own six-digit display, cycled via the RESET key, without additional hardware. The up-to-three remote display option is documented specifically for applications wanting all values visible simultaneously and continuously, rather than needing to press a button to cycle through them on a single display.

In the multi-controller chemical mixing application, does each controller need its own separate operator interface, or can they be managed centrally?

They can be managed centrally — this is specifically documented as facilitated by optional serial communications, where RS485 allows a single data line to handle multiple controllers for both setup and ongoing monitoring, meaning an operator doesn't need to physically visit each individual controller's front panel to configure or monitor the mixing operation.

Does the delay-between-batches setting apply globally, or can it be different for each batch cycle?

The documented delay is a single configured setting (selectable from 10 ms to 199.99 s) applied consistently between the end of one batch and the start of the next, rather than a per-cycle variable value — for applications needing the next fill to start only on an external trigger rather than a fixed timer, the controller can alternatively be set to wait for an external control input instead of the timed delay.

Can the discrete bottle-counting application track both individual bottles and completed sixpacks at the same time?

Yes — this is specifically documented as an application of the Grand Total function, which can be configured to track either bottles or sixpacks depending on setup, and combined with the controller's other tracked items (such as batch total configured to count bottles per sixpack), both individual bottle counts and completed sixpack counts can be monitored together.

Does the prewarn relay in drum filling actually stop the pump, or just slow it down?

Documented behavior specifically distinguishes these two relay roles: the Prewarn relay slows down the pump as it approaches the preset (to avoid overshoot), while the separate Batch relay is what actually stops the pump once the preset is reached — the prewarn function is a deceleration step, not the final shutoff itself.

Is down-counting batch control functionally identical to up-counting, just with the numbers reversed?

Conceptually similar but documented with a distinct emphasis — down-counting starts from a preset maximum and counts toward zero, with prewarn available to slow filling or emptying specifically near zero rather than near an upper preset; the underlying counting and relay-control mechanism is comparable, but the direction affects where in the batch cycle the prewarn slowdown becomes relevant.

Can peak rate specifically (not just current rate) be transmitted over the optional serial communications board?

Yes — this is specifically documented: the optional serial communications board transmits Items #1, #2, and #3, as well as peak for Item #3 (rate) specifically, meaning a connected data logger or SCADA system can capture not just the instantaneous flow rate but also the highest rate recorded during a batch, without needing separate hardware to capture that peak value.

Does using the same pulse signal for both totalizing and rate risk any interference between the two channels?

No — Channels A and B are documented as independently configured and processed, each running its own measurement technique (accumulation for Channel A, inverse-period timing for Channel B) on the shared incoming signal without one channel's processing affecting the other's result. Splitting a single sensor's output to two channels this way is a documented, supported configuration, not a workaround with inherent tradeoffs.

Batch Fill Overshoot & Two-Stage Dispensing Questions From the Field

Why do batch fill systems commonly use a two-stage (coarse, then fine) approach instead of a single constant fill rate?

Documented gravimetric dispenser design specifically describes a coarse/pre-dispensing stage at high flow rate delivering most of the dosage, followed by a slower making-up stage delivering the remainder — this structure exists specifically because a high flow rate throughout risks larger overshoot at the finish, while the slower final stage allows the fill to be stopped much closer to the exact target quantity.

Does the accuracy of the coarse stage in a two-stage fill actually matter, given that the fine stage corrects the final amount?

Yes — documented analysis specifically notes that it's desirable for the coarse stage's delivered quantity to differ as little as possible from its intended target, because a large discrepancy at the end of the coarse stage forces an undesirably long making-up (fine) stage to compensate, which slows down the overall fill cycle even though the fine stage can technically still correct the final total.

What physically causes fill overshoot in a valve-controlled batch system, beyond simply "the valve being slow"?

Documented analysis of batch mixing systems identifies overshoot as caused primarily by the finite closure time of the control valve, but also names additional contributing factors: signal lag time, the interval between consecutive measurement readings, and valve clogging — meaning overshoot troubleshooting shouldn't stop at just checking valve speed if these other factors haven't also been ruled out.

If a batch's first ingredient doesn't hit its exact target weight, is the whole batch's ratio automatically thrown off?

Not necessarily, if the system is designed to compensate — documented batch mixing technology specifically describes automatically recalculating the target weights of subsequent ingredients based on the actual (not just intended) added weight of a key ingredient added first, which preserves the critical ingredient ratios within close tolerance even when the first ingredient's fill wasn't perfectly exact.

Is overshoot compensation something that has to be manually tuned for each batch, or can it be handled automatically by the control system?

Documented systems specifically describe automatic overshoot compensation as a built-in feature rather than a manual per-batch adjustment — the compensation logic (recalculating subsequent target weights based on actual measured results) operates automatically as part of the batch sequence, without requiring an operator to manually recalculate or re-tune ratios between batches.

Does the transition point between coarse and fine stages need to be fixed, or can it adapt based on how the fill is actually progressing?

Documented dispenser design treats the coarse-to-fine transition as a configured setpoint based on the predetermined target dosage, structured around minimizing discrepancy at the transition specifically so the fine stage doesn't need to compensate for large errors — while the fundamental two-stage structure is a design choice, the actual switchover point is tied to how much of the target dosage has already been delivered, not a purely time-based schedule.

Why does a slower fine-stage flow rate actually improve final fill accuracy rather than just slowing down the process unnecessarily?

A slower flow rate reduces the amount of product delivered per unit of valve-closure delay — since overshoot is fundamentally tied to how much material continues to flow during the finite time it takes a valve to fully close, a lower flow rate at the moment of shutoff means less material passes through during that closure delay, directly reducing the magnitude of overshoot at the final target.

Can key-ingredient-first sequencing and overshoot compensation both be used together in the same batch cycle, or are they alternative approaches?

They're complementary, documented as working together in the same system — the key ingredient is added first using the same overshoot-prone valve-controlled dispensing process, and its actual (not nominal) delivered weight then becomes the basis for recalculating the targets of the ingredients that follow, meaning overshoot compensation on the first ingredient directly feeds into and improves the accuracy of the ratio-based sequencing for the rest of the batch.