LOMA CW3 · Industrial

LOMA checkweigher data in Power BI, the right way.

Read-only Go collector, full metal-detector data captured, wire fingerprinting against machine identity flips. Production-tested across three generations of plant-floor deployments.

The work

Why LOMA checkweigher integration is harder than it should be.

The LOMA CW3 is the most widely deployed checkweigher on Australian food and FMCG production lines. The protocol is documented, the data is rich (weight, target, deviation, reject state, full metal-detector telemetry, PVS performance validation, head config), and the machine exposes it over a plain TCP socket on port 10010.

And yet most CW3 integrations we walk into are either broken, fragile, or silently losing the half of the data nobody documented. Passive packet captures collapse under shift-long load. Active polling implementations hammer the machine with bare TCP resets that have been linked to embedded-stack failures. Field-count drift between protocol 1.5 and 1.6 silently misaligns parsers. Metal-detector data, the exact record HACCP auditors ask about, quietly gets dropped at the parser layer.

We ship a different pattern. A production-tested Go collector built on three generations of real-world LOMA driver lineage. Read-only enforced at the type-system level, so write commands literally cannot be expressed in our source. Full MD data capture. Wire fingerprinting to catch firmware drift and machine identity flips before they cause silent data quality problems. Live streaming into Power BI, Microsoft Fabric, or TimescaleDB.

Common failure modes

Six ways LOMA checkweigher integration usually goes wrong.

Every CW3 rescue or rebuild we've done lands on at least three of these. If two or more sound like your environment, the architecture above fixes them. The only question is how quickly we can ship it.

Passive packet capture (libpcap / tcpdump) collapses under load

Most first-pass LOMA integrations we walk into use Wireshark-style packet capture sitting on a SPAN port. Works for a one-day proof-of-concept; falls over the moment the line runs all shift. Dropped frames, no recovery, no protocol-aware parsing of partial messages. We move to an active TCP poller with persistent socket and reconnect backoff.

Active polling without graceful reconnect

Early polling implementations hammer the CW3 with a fresh socket every poll cycle or a tight reconnect loop after a drop. We have logged incidents where a bare TCP RST coincided with the CW3's embedded B&R stack dying ~15 minutes later. The collector uses graceful FIN teardown and gentle backoff instead, which is kinder to the machine and more reliable over weeks of uptime.

Field-count drift on LOMA protocol updates

LOMA protocol 1.5 vs 1.6 added a reserved 21st MD field. Naive parsers silently drop or misalign on the new field, and the data looks fine until QA notices something is off three weeks later. Our parser tracks ProtocolVersion, CW3 software version, IQ3/MD firmware, and MachineType, and surfaces field drift as a structured warning so new firmware is visible, not invisible.

Metal-detector data silently lost

The LOMA CW3 stream carries metal-detector telemetry alongside checkweigher data: Fe/NFe/SST contaminant counts, PVS performance-validation runs, head config. Many integrations grab only the weight frame and lose the MD record entirely. The result: HACCP auditors ask about contaminant rejects and the data isn't in the warehouse. We capture the full frame and surface MD events as first-class data in the dashboard.

Write paths exposed (catastrophic risk)

LOMA CW3 has a write channel (port 10011, Channel 2) that can issue commands to the machine: change limits, reset state, modify configuration. An integration that accidentally exposes this is one bug away from operators discovering production-line parameters changed remotely. Our collector excludes write commands at compile time. The Go type system has no type for them, so they cannot be invoked from our code. Read-only isn't a runtime check, it's an architectural property.

Machine identity flips without alerts

A CW3 IP gets reassigned. A swapped backplane. A factory-restored firmware. Standard integrations keep streaming data tagged with the old identifier, and the historical log silently merges two physical machines. We capture a wire fingerprint on every connect (machine type, firmware, protocol version, configured fields) and compare it against the previous fingerprint. Drift triggers an alert; collisions across the registry trigger another. Identity is verified, not assumed.

What we build

The LOMA CW3 integration stack we ship.

LOMA CW3 ASCII protocol driver

Production-tested Go implementation of the LOMA CW3 ASCII protocol (STX/ETX/US framing, byte-by-byte parse state machine, checksum verification over payload). Eight documented read-only query commands. Three-generation lineage from .NET to Python to Go, so the protocol knowledge isn't new code.

Read-only by architectural design

Write commands (Channel 2 / port 10011) cannot be expressed in the collector source. The Go type system defines only query types, so there's no syntax to construct a write command. Read-only enforcement happens at compile time, not at runtime, not by convention.

Full metal-detector data capture

Contaminant counts (Fe / NFe / SST), signal levels, PVS performance-validation log entries, head configuration changes. The MD data is captured as first-class events alongside weight frames, which is exactly the record HACCP auditors ask about.

Wire fingerprinting + identity-flip alerts

Per-machine wire fingerprint captured on connect, compared every cycle. Firmware updates and machine swaps surface as alerts before they cause silent data drift. Registry-level cross-scans catch IP / identity collisions across the CW3 fleet.

Real-time event streaming to Power BI / Fabric

Standard pipeline: LOMA CW3 → Go collector → Redpanda (Kafka API) → TimescaleDB → Power BI / Microsoft Fabric. Live per-pack events, SPC charts, reject piston state, MD contaminant logs, and OEE roll-ups, all on the same Microsoft stack the rest of the business uses.

Hand-over runbook for plant IT

Documented protocol driver, documented network requirements (TCP/10010, persistent socket, gentle backoff), documented Power BI semantic model, documented alert thresholds. Plant IT can keep the system running without further consulting, or retain us on monthly support.

Stack

What we work with.

The collector runs as a Windows service on-site or as a Docker container on Azure, whichever fits the plant IT model. The data layer is Kafka-API event streaming into time-series storage, modelled cleanly for the Power BI / Microsoft Fabric layer above it.

LOMA CW3 (ASCII protocol over TCP/10010, read-only)
Go collector (3-generation-proven, NET → Python → Go lineage)
Compile-time command whitelist (write paths cannot be expressed)
Redpanda / Kafka API for industrial-grade event streaming
TimescaleDB (PostgreSQL + Timescale extension) for time-series
Power BI Desktop / Service / Fabric capacity for dashboards
Azure VM or on-prem Windows service edge deployment
Multi-channel alerts: email · Teams · SMS · escalation chains

FAQ

Frequently asked

Can you read data off a LOMA CW3 without disrupting the line?

Yes, and this is the whole point of the architecture. Our collector polls the CW3 over TCP/10010 with a persistent socket, SO_KEEPALIVE, and gentle reconnect backoff. It only issues the eight documented query commands; the write paths (port 10011 / Channel 2) literally cannot be invoked from our code because they are excluded at the Go type-system level. The CW3 sees a well-behaved read-only client. No operator workflow changes, no line downtime, no risk of accidentally pushing a command.

Do you capture metal-detector data, or just weight events?

Both. The standard LOMA CW3 stream carries checkweigher statistics (weight, target, deviation, reject state) AND metal-detector telemetry (Fe / NFe / SST contaminant counts, signal levels, PVS performance-validation runs, head configuration). Most integrations we audit capture only the weight side and silently lose the MD record, which is exactly the data HACCP auditors ask about. We capture the full frame.

What happens when LOMA firmware changes the protocol slightly?

We tracked the field-count drift between LOMA protocol 1.5 and 1.6 (the reserved 21st MD field) and our parser surfaces it as a structured warning rather than silently dropping the new field. Per-machine wire fingerprints are captured on connect and compared every cycle. If a CW3's firmware updates or an IP collision points us at a different machine, the registry raises an alert before the data quietly drifts.

Can we get this onto Power BI or Microsoft Fabric?

Yes. The standard pattern is LOMA CW3 → Go collector → Redpanda (Kafka API) → TimescaleDB → Power BI / Fabric. Time-series storage in Timescale handles the high-frequency event rate without dragging Power BI through expensive DirectQuery; Power BI lives entirely against the warehouse. You get live per-pack weight events, SPC, reject piston state, MD contaminant logs, and OEE roll-ups, all on the same Microsoft stack your finance and exec teams already use.

Will polling slow down the line?

No. The CW3 was designed for this. The polling cadence is configurable and stays well under what the machine handles in normal operation. Compared with passive packet capture (libpcap / tcpdump) approaches, active polling is far more reliable: the collector knows exactly which commands it's sending, what response to expect, and how to recover when a frame is dropped. Hardware never sees more than a well-formed query stream.

How long is a typical LOMA integration engagement?

Two-week discovery (which machines are in scope, network access, downstream destination, KPI definitions) then a 4 to 8 week build sprint. The first machine takes the longest: protocol commissioning, fingerprint baseline, Power BI suite or TimescaleDB schema. Subsequent CW3s on the same site are typically a few hours each because the driver is identical across the LOMA fleet. We don't run open-ended discovery.

Connected services

Industrial Tech

LOMA data trapped in the vendor console?

Tell us what is breaking or what you wish you had visibility on. We'll tell you what we'd scope, what we'd deliver, and how long it would take.

sales@onsignal.com.au Start a Conversation