LT DIN Rail Digital Transmitters with Serial Data Communication and Analog Outputs for Pulse Input Totalizer Applications

Pulse Input Totalizer DIN Rail Transmitter Frequently Asked Questions

Why does the documented machine utilization example connect Channel A to switched AC and Channel B to the AC line, rather than both channels to the same signal?

Documented setup specifically distinguishes these two connections by purpose — Channel B connected to the continuous AC line provides a constant reference representing total elapsed time, while Channel A connected to switched AC only counts cycles while the machine is actually powered on; the A/B ratio of these two genuinely different counts is what produces a meaningful duty cycle figure, which wouldn't be possible if both channels measured the same signal.

Why does the documented duty cycle example specifically apply a 100 multiplier to the A/B ratio?

Documented instruction specifically calls for a 100 multiplier because the raw A/B ratio (machine-on cycles divided by total line cycles) is inherently a fraction between 0 and 1 — multiplying by 100 converts that fraction into a directly readable percentage figure for the displayed and transmitted duty cycle value, rather than requiring the user to mentally convert a decimal ratio into percentage terms.

Does counting AC line cycles for machine ON time require any special sensor beyond connecting to the AC line itself?

Documented description specifically frames this as counting AC line cycles directly, with the switched-AC connection serving as the "on" signal — since the AC line's own cycling (50 or 60 Hz) provides a naturally occurring, steady pulse train, no separate pulse-generating sensor is documented as necessary; the AC waveform itself is the counted signal, scaled to hours via the transmitter's scaling functions.

Does the up/down totalizing mode's Channel B direction input need to be a continuous signal, or can it be a simple discrete state?

Documented description specifically frames Channel B's role as a direction input governing whether Channel A pulses are added or subtracted — this is consistent with a simple discrete (on/off or high/low) state input rather than requiring a continuous pulse train itself, since its function is to determine the sign of the counting operation, not to contribute its own pulse count to the total.

Can the same Channel B input be used both to control counting direction and to inhibit counting, or are these mutually exclusive documented modes?

Documented description presents these as two separate modes of the Extended totalizing transmitter — one where Channel B controls add/subtract direction, and another where a Channel B input inhibits Channel A counting entirely — the page describes them as distinct configuration options rather than confirming they can be combined simultaneously on the same input.

Does external reset of totals via the three-position screw terminal reset both Channel A and Channel B totals simultaneously, or can they be reset independently?

The page documents external reset as a general capability tied to the up/down counting with preset functionality, without separately detailing independent per-channel reset control at that specific connector — this is documented as the mechanism for external total reset generally, with channel-specific reset behavior best confirmed against the specific configuration in use.

Why does the "up or down counting with preset" application specifically require the dual relay option?

Documented description specifically states the dual relay option is required for this application, consistent with each relay being used to signal completion of one of the two repetitive fill operations being tracked — since the application involves monitoring two separate preset-based counts, having two independent relay outputs is what allows each fill operation's completion to be signaled and acted upon separately.

Does square root extraction being "standard" on this transmitter's Standard main board work the same way for totalized readings as it does for rate readings?

Documented capability lists square root extraction as standard on the Standard main board without separately distinguishing its application to rate versus total — since a totalized reading is fundamentally an accumulation of the (potentially square-root-corrected) rate over time, square root extraction is documented as applying at the underlying signal-conditioning stage before totalization occurs, so both the rate display and the accumulated total benefit from the same correction rather than needing separate extraction steps.

Does custom curve linearization "extend transducer range" mean it lets a transducer physically measure beyond its original design range, or something else?

Documented phrasing specifically describes linearization as extending the working range and accuracy of flow transducers — this refers to extending the usable accurate measurement range within the transducer's own physical capability (particularly at the low end, where many flow transducers are documented elsewhere as nonlinear), not literally exceeding the transducer's physical measurement limits; linearization corrects how accurately the existing signal is interpreted, it doesn't change what the sensor can physically detect.

Can the simultaneous rate-and-total display feature be used together with the arithmetic functions (A+B, A/B, etc.) on the same transmitter?

Documented description lists simultaneous rate/total display and the five arithmetic functions as separate Extended-board capabilities without stating they're mutually exclusive — since arithmetic functions are documented as applicable to "scaled rates" and "scaled totals" alike, and simultaneous display is documented as showing scaled rate or total for the same input, the two capabilities address different aspects of the same underlying data (what's calculated versus what's displayed) and are consistent with combined use on one Extended-board transmitter.

Machine Utilization & OEE Monitoring Questions From the Field

What is OEE, and how does it differ from a simple machine utilization percentage?

Documented explanation specifically describes OEE (Overall Equipment Effectiveness) as combining three separate factors — Availability (uptime versus planned time), Performance (actual speed versus ideal speed), and Quality (good parts versus total parts) — into one composite score, whereas a simple utilization percentage is documented as a narrower, single-dimension metric describing only how much of available time the machine is actually running, without capturing speed or quality losses.

Is manually tracked machine runtime data documented as reliable compared to automated monitoring?

No — documented industry analysis specifically notes that manual OEE tracking (using paper sheets, spreadsheets, or tracking cards) is commonly overestimated by 10-25%, which can distort improvement decisions; this documented gap between manual and automated tracking is cited as a specific reason for moving toward automated, sensor-based runtime data collection.

Does a documented best practice exist for separating planned downtime from unplanned downtime when calculating machine utilization?

Yes — documented guidance specifically recommends separating planned downtime (scheduled breaks, planned maintenance) from unplanned downtime, and using consistent time windows (shift, day, week) across all machines and operations, specifically so that utilization and OEE figures remain comparable across different machines and time periods rather than being skewed by inconsistent counting rules.

Is there a documented typical range for machine utilization in discrete manufacturing that helps put a specific measured percentage in context?

Yes — one documented industry dataset specifically reports average CNC machine utilization around 25.9%, with most shops operating between roughly 17-20% and high-performing shops reaching around 60%, illustrating that even a utilization figure that sounds low in isolation may be broadly consistent with typical industry figures, while also showing substantial documented room for improvement exists between typical and high-performing operations.

Does simply tracking how much downtime occurs provide the same improvement value as also tracking why it occurred?

No — documented guidance specifically distinguishes these: tracking downtime duration alone tells you how much time is being lost, but capturing structured reason codes (mechanical failure, tooling change, material wait, operator break, and so on) is documented as necessary to know where to focus improvement efforts; a Pareto-style analysis of downtime reasons is documented as a common technique for identifying which causes drive the majority of total losses.

Is a documented "world-class" OEE benchmark figure a realistic target for every operation to reach immediately?

Not typically — documented industry guidance cites roughly 85% as a commonly referenced world-class OEE figure in discrete manufacturing, while also documenting that most shops start well below that benchmark; this framing treats world-class OEE as an aspirational long-term target reflecting significant improvement effort, not a baseline expectation for a newly instrumented machine.

Does a documented performance loss (running below rated speed) show up clearly in a simple ON/OFF runtime measurement?

No — documented analysis specifically notes that a machine running at, for example, 90% of its rated speed doesn't look like an obvious problem in isolation, but that 10% speed loss compounds significantly when multiplied across many cycles per shift; a basic ON-time or utilization measurement documents whether the machine was running, but doesn't by itself reveal this kind of speed-based performance loss, which is why full OEE tracking documents speed as a separate, additional factor.

Does documented practice suggest that automated monitoring data alone is sufficient to answer why a specific inefficiency occurred, without cross-referencing other data?

Not always — one documented field example specifically describes a case where automated machine-cycle data alone showed a long unexplained gap between production cycles that only became understandable when cross-referenced against separately logged operator/job data; documented guidance from this example suggests that combining automated machine data with other operational context can reveal insights that machine data alone would leave as an open question.