Stop Typing Weights: What a Scale Connected to Plex Actually Changes

Picture the receiving dock on a busy morning. A pallet comes off the truck, someone reads the scale display, walks to a terminal, and types the weight in. Three things can go wrong before lunch, and usually one of them does: the number is misread, mistyped, or entered against the wrong lot. Nobody catches it until a customer disputes a shipment weight, a count doesn't reconcile, or finance finds an invoice that doesn't match what actually shipped.

Now picture the same dock with the scale connected. The operator opens the receiving transaction, sets the pallet on the scale, and taps the weigh scale button — the reading lands in the transaction by itself. No walk to the terminal, no transcription, no second guess about which digits were on the display. That is the whole change, and it is bigger than it sounds — because weight is one of the few shop-floor numbers that gets typed by hand long after everything else got a barcode.

Listen to this post:

How it actually connects

This is the part most articles skip, and it is the part that decides whether the project is a weekend job or a science experiment. In Plex, the weigh scale connects through the Component Host weigh scale plugin:

  • It runs on Windows only, and the scale connects over a serial port — not USB plug-and-play, not the network.
  • Each computer can run a Primary Scale and a Secondary Scale, each with its own profile, so one station can capture two different values (say, gross on one scale and a sample weight on the other).
  • Once the plugin is configured and enabled, a weigh scale button appears on the screens that support it — receiving, container management, scrap, and production recording.
  • Configuration lives on each computer: Component Host status screen, Components, Weigh Scale, Manage Configuration. There is no central profile service, so a profile built on one station reaches the others by export and import, not by sync.

That last point matters for rollout planning: budget time per station, not just for the first one.

Where it pays first

Receiving. Receiving a container is a native weigh-scale action. The captured weight lands on the receipt itself, so over and short receipts surface before the material is put away, not at month-end. For catch-weight items, where the billed quantity is the weight itself, that captured net is what the supplier invoice gets checked against.

Production recording. This is the most detailed workflow in the documentation, and it is where a scale earns its keep daily. On the Record Production screen, the Quantity per Container weigh scale button pulls from the scale in a set order: quantity, then tare if no quantity came through, then gross. With auto-fill on and no quantity yet, the container quantity is computed from gross minus tare divided by piece weight — and that piece weight comes from the part or process routing, not from someone's memory. When a quantity is already present, the gross reading divided by pieces gives the average piece weight, and piece weight and quantity update together. A second button reads a sample for piece weight directly. Either way, yield and variance reports start running on real numbers instead of estimates.

Scrap. Recording scrap is also a native weigh-scale action, so scrapped weight is captured at the moment it happens rather than reconstructed later from memory or a tally sheet.

Containers. Adding and modifying a container round out the native actions — the weight that defines a container is captured, not typed.

Setup in plain terms

A scale profile is what tells Plex how to talk to a specific scale. Plex ships System Profiles, or you build a Custom Profile. Either way, two things have to be right:

The connection. Port, baud rate, parity, stop bits, and data bits are set on the Weigh Scale Configuration screen — and the computer and the scale must match exactly. A mismatch here is the classic "the scale is connected but nothing arrives" problem, and it is always settings, not hardware.

The parsing. Every scale sends its reading as a string of characters, and the profile says how to read it. The simple route is a grid: name each value type (gross, net, tare, piece weight, piece count, unit) and give the character positions where it sits in the string. The flexible route is a regular expression with named groups for the same value types, plus a stability value. Either way, the profile also carries the command that triggers a weighing, the terminator bytes, timeouts, and the stability string — the character the scale sends when its reading is stable (often "S") versus while it is still settling (often "M").

Profiles move between computers as JSON files: export from one station, import on the next. Imports are validated, and a profile name that already exists gets a suffix rather than overwriting. System profiles and profiles currently assigned to a Primary or Secondary scale cannot be deleted.

The gotchas (all fixable, all worth knowing before you buy)

A connected scale is not magic; it just moves the failure points somewhere more visible. Capture only a stable reading — the stability string exists for exactly this reason, and vibration and forklift traffic are why it matters. Tare discipline has to be in the SOP, not in someone's head, because a pallet left on the scale inflates everything after it — and tare is a first-class value in the profile, not an afterthought. Units come from the scale's own data string, so pounds on the scale and kilograms in the part master stop being a hand-conversion accident waiting to happen — as long as the profile parses the unit the scale actually sends. And when the serial cable comes loose, the terminal has to say so loudly; a silent fallback to manual entry defeats the entire purpose.

Two scope limits to plan around: the plugin is Windows-only, so a non-Windows terminal on the floor needs a different answer; and profiles are per-computer, so a ten-station rollout is ten configurations (or ten imports), not one.

Calibration deserves its own line. A scale reading half a percent high ships half a percent of everything free, quietly, for months. Treat calibration like any other equipment maintenance: scheduled, logged, with a tolerance that blocks use when it lapses.

The business case in one paragraph

Time one manual weigh-and-key cycle and multiply it by daily transactions — that is the labor. Add last quarter's weight corrections, carrier re-weigh fees, and invoice disputes tied to weight — that is the error cost. Then add the value of counts that actually happen on schedule and captured weights you can defend. Pilot it on one scale and one transaction (container receiving or production recording are the natural first pilots — both are native actions), measure for two weeks against a manual sample, and expand only if the numbers hold.

What these docs don't cover

The Plex weigh-scale documents behind this article do not cover shipping manifest weights or quality-checksheet capture, and they name no specific scale models — Plex-defined System Profiles exist, but which models they cover is a question for your Plex contact. Confirm those before promising them to a plant. The pattern is proven; the specifics above are verified, and the rest is yours to verify.

The plants that get this right share one habit: they stop treating weight as a number someone types, and start treating it as data a machine captures. Everything downstream — inventory accuracy, invoicing, shipping disputes, audits — gets easier the moment the number stops passing through someone's fingers.

Setup cheatsheet

Want the setup on one page? Download the free fillable Plex ERP Weigh Scale Setup Cheatsheet — document the module, the connection and profile settings, and the pilot checklist for one scale station.

Popular posts from this blog

Your Tool Crib Is Telling You Something: Cycle Counts as an Early Warning

Cybersecurity Awareness Month 2026: Don’t Make It Easy for Them

Ticket Triage for Plex ERP: How Small BA Teams Decide What Gets Fixed First