A scale can be physically connected and still deliver the wrong value to a business record. The tablet must receive a complete message, interpret the scale's status, weight type, sign, decimals and unit, and bind that observation to the intended product, container or job. A number left on screen from the previous load is not a new weighment.
This guide is for industrial weighing project owners, warehouse and production teams, application integrators and rugged-tablet buyers. Its messages and identifiers are editorial, not output from an AIDC GO device or a customer installation. Start with the rugged-tablet category, rugged-tablet field operations, Integration Support and Contact only after the exact scale, interface and application contract are known.
Define the complete connection, not just the connector
Record the scale or weighing-terminal model and firmware, fitted interface option, electrical standard, cable or adapter, tablet port, operating-system driver and application communication method. A USB receptacle can expose different device classes; it does not establish that the tablet has the required driver or that the scale presents a generic data stream. A serial connector does not establish pinout or signal level.
The rugged-tablet serial guide covers port, cable, driver and message framing. A scale project must add weighing-specific meaning: which value is sent, when it is valid, and which load or task owns it.
For one exact example, the METTLER TOLEDO ICS685/ICS689 user manual, document 30243688_G, describes model-specific RS-232, optional RS-422/RS-485, Ethernet, WLAN and USB communication choices. Its menu lists modes including manual print, automatic print of stable results, instant output, dialog and continuous dialog; it also allows selected Net, Gross and Tare values in relevant modes. These capabilities belong to the named terminal and installed options, not to every scale or tablet.
Preserve status, weight type, value and unit
Do not reduce the incoming message to a decimal number. The application needs enough context to decide whether the value can be used.
| Parsed field | Editorial value | Question before acceptance |
|---|---|---|
| Scale identity | SCALE-07 |
Is this the approved device for the active station? |
| Acquisition mode | on-demand |
Was this response requested for the current task, or was it unsolicited continuous output? |
| Stability | stable |
Does the exact protocol say this value meets its stable-state condition? |
| Weight type | gross |
Does the workflow require gross, tare or net? |
| Value and unit | +12.480 kg |
Are sign, decimal position and unit accepted without silent conversion? |
| Observation identity | W-901 |
Can the UI distinguish this observation from the previous container's value? |
| Business context | JOB-62 / BIN-B |
Was the observation bound to the intended item, container or task before confirmation? |
The ICS685/ICS689 manual distinguishes ongoing output of all weight values from automatic output of stable results and describes Gross, Tare and Net selection. It also documents communication settings such as baud rate, parity, handshake and termination choices for the named interfaces. Use the actual model manual; do not treat its defaults as universal settings.
Keep gross, tare and net meaning explicit
Gross is the loaded total under the project's definition. Tare is the container or preset subtraction used by the weighing process. Net is the resulting content value. A field named weight is ambiguous until the protocol and workflow state which one it contains.
The same METTLER TOLEDO manual describes a model-specific tare preset entered numerically, by barcode or with an SICS command, after which the terminal displays net weight. That example proves that tare state can affect the displayed or transmitted result; it does not prove that any connected application knows which container supplied the tare.
For regulated commercial weighing in the United States, NIST's Handbook 44, 2026 edition is one official reference for applicable devices and systems. Project teams must identify the jurisdiction, device configuration and intended use. This article does not determine legal-for-trade suitability or replace local approval.
Walk through a stale-value editorial example
Assume the operator has completed container BIN-A. The application still shows its last accepted observation: gross 12.480 kg, ID W-901. The operator selects the next task, JOB-62 / BIN-B, but the scale cable has disconnected. If the screen simply keeps the number visible, a tap on Confirm can misattach BIN-A's weight to BIN-B.
The safer flow changes the weight field to waiting for a current observation when business context changes. It records the selected scale, invalidates the previous observation for confirmation, and requests or waits for a new complete message. Suppose the connection recovers and a new editorial message is normalised as W-902 / stable / gross / +8.215 kg. The application shows scale SCALE-07, observation time, gross status, unit and BIN-B, then requires confirmation. Only the backend acknowledgement changes the job to weight accepted.
If W-902 is unstable, has an unapproved unit, lacks its terminator, or reports net when the task requires gross, keep it visible for diagnosis but reject it as the task result. These normalised records are constructed examples, not METTLER TOLEDO protocol frames and not measured values.
Handle continuous output, repeated values and reconnects
Continuous transmission can deliver many observations while the load settles. Equality of two numeric values does not by itself show whether they are duplicates, distinct samples or a new container with the same weight. Define the acceptance trigger: an explicit application request, a scale print event, a stable transition, an operator confirmation or another documented event supported by the exact scale.
On disconnect, mark the current connection and observation stale. On reconnect, re-identify the interface, confirm configuration and obtain a new eligible observation before enabling Save. Do not turn the last cached value into a new read merely because the connection icon becomes green.
If a save request times out, query the backend using the business record and submission identity before sending another transaction. The background-sync guide explains why local completion and server receipt remain different states. The scale link and the business transaction each need their own status.
Bind the weight to the correct item, container or job
A correct weight can still be filed under the wrong object. Resolve the active product, container or task before the application accepts the observation. When the operator changes context, invalidate any unconfirmed weight from the previous context. Preserve the source scale, raw message or approved diagnostic representation, parsed fields, conversion rule if any, and server record.
The unit-of-measure guide addresses each, case and pallet quantity conversions. Weight integration has a different boundary: unit conversion is allowed only under an explicit rule, with the original value retained. A displayed 12.480 without kg, lb or another documented unit is not an acceptable business input.
Test at least two adjacent containers, equal-value loads, negative or out-of-range output, unstable output, gross/net mismatch, changed units, half a message, continuous repeats, disconnect with an old value still visible, reconnect, timeout after backend acceptance and a deliberate context switch.
Approve the entire weighing route
Confirm the physical assembly at the actual workstation: tablet mounting, scale cable retention, power, port occupancy, driver, application focus and safe operator reach. Then compare the scale display, captured message, parsed result, task context and backend record for every test case. Do not infer measurement accuracy from successful data transfer.
Ask for the exact scale manual, option list, protocol revision, driver package, cable diagram, unit and decimal rules, stability/status definitions, gross/tare/net behavior and regulatory evidence applicable to the project. Ask AIDC GO for only the model-specific tablet and interface documents supported by approved product material. No AIDC GO scale driver, SDK, weighing certification or universal USB compatibility is implied.
The purchase decision is ready when one named scale–interface–tablet–application combination can produce a current, correctly interpreted observation and attach it to the intended business record. “The tablet shows a number” is only an intermediate check.