A CRC error is a peculiar kind of fault because the device did answer - the reply just arrived damaged. The master received a frame, ran its integrity check, found the numbers did not match, and threw the message away as corrupt. That single behavior tells you a lot: the device is alive and reachable, but something on the line is scrambling bits between the two ends. This page explains what a CRC check actually validates, why intermittent CRC errors point to a physical problem rather than a dead device, and how a climbing CRC error count is an early warning of a link about to fail.
CRC error in one line: A CRC error occurs when a received serial frame fails its cyclic redundancy check - the checksum the sender appended does not match the checksum the receiver recomputes over the data - so the master treats the frame as corrupted and discards it. It means a reply did arrive but was garbled in transit, which points to line noise, grounding, bad termination, or a baud mismatch rather than a device that is offline.
Serial protocols such as Modbus RTU append a checksum to every frame - a CRC value calculated from the frame's contents. The sender computes it and attaches it; the receiver runs the same calculation over the data it received and compares. If the two match, the frame is accepted as intact. If they differ, even by a single flipped bit, the receiver knows the message was altered somewhere between sending and receiving and discards it rather than acting on bad data. Some serial protocols use an LRC instead of a CRC, but the principle is identical: a mathematical fingerprint that betrays any corruption of the frame.
The crucial point is what a failed check does and does not tell you. It does not tell you a device is missing - the frame arrived, so something answered. It tells you the frame's integrity was destroyed in transit. The CRC cannot repair the damage or say which bit flipped; it only catches that damage occurred, and its job is to make sure a corrupted value never reaches the process database. A discarded frame is then handled like any lost message: the master retries. So a CRC error is a caught corruption, not a delivered wrong value, which is exactly the behavior you want.
Because a CRC error means bits were flipped in transit, its causes live in the physical and electrical layer, not in device configuration. Electrical noise coupling onto the cable is the classic source - a variable-frequency drive, a switching contactor, or a motor starting nearby can inject interference that corrupts frames intermittently. Grounding problems and ground-loop currents on an RS-485 network do the same. Poor or missing bus termination causes signal reflections that garble data, and those reflections often worsen as cable runs get longer or baud rates get higher.
The intermittent, random pattern is itself the clue. A dead device fails every poll; a wrong address fails every poll the same way; but line noise corrupts some frames and lets others through, so CRC errors come and go, cluster when a noise source runs, and rarely affect every message. A baud, data-bit, or parity mismatch can present similarly, because the receiver samples the bits at the wrong moments and the resulting frame fails its check - which is why confirming both ends use identical line settings is part of chasing CRC errors. When errors correlate with a piece of equipment cycling, with wet weather on an outdoor run, or with a specific long cable, the physical cause is usually close at hand.
The most valuable thing about CRC errors operationally is that they are a leading indicator. A link does not usually die all at once; it degrades. Marginal termination loosens, a shield corrodes, a new drive gets installed nearby, and the CRC error rate creeps up long before the link fails outright. If a system tracks a communication-errors counter per device, a rising count is a warning that a connection is becoming flaky and deserves attention before it starts dropping data or triggering comms-fail alarms. A link with an occasional CRC error is healthy; one whose error rate is climbing week over week is trending toward failure.
That is why exposing the counter, not just the final alarm, is so useful in the field. It helps a technician when a platform shows the CRC error rate on each serial link over time, because a slow climb becomes visible as a maintenance item rather than surfacing only as an eventual outage. A cloud SCADA platform such as Merobix can trend those communication-error counts per device and let an operator spot the link whose integrity is deteriorating, so a noisy cable or a failing termination gets fixed on a planned visit instead of causing a data gap that someone has to scramble to explain later.
No - a CRC error means a reply did arrive but was corrupted in transit, so the device is alive and reachable. The master discards the garbled frame and retries. An offline device produces a timeout with no reply at all. Getting CRC errors tells you the problem is in the line quality, not in whether the device is present.
Physical-layer problems: electrical noise from nearby drives, contactors, or motors coupling onto the cable, grounding and ground-loop issues, missing or poor bus termination causing reflections, and long cable runs at high baud rates. A serial line-setting mismatch can also produce failed checks. The intermittent, comes-and-goes pattern is the clue that it is line quality rather than a dead device or a bad address.
Because it is an early warning. Links degrade before they fail - marginal termination, a corroding shield, or a newly installed noise source pushes the error rate up well before data actually drops. Tracking a per-device communication-errors count lets you spot a link trending toward failure and fix it on a planned visit, instead of waiting for it to become an outage.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.