Repeated PLC timeout and invalid checksum errors on an HMI are communications-path faults, not a broken screen project. A timeout means the panel got no usable reply from the endpoint it addresses; a checksum error means frames arrived but failed the integrity check. Confirm the documented host port first, then match baud rate, data bits, parity, stop bits and station address at both ends, then check the cable.
Repeated PLC timeout and invalid checksum errors on an HMI have one meaning: the panel and the controller are not exchanging valid frames. The fix that clears this pair most often takes under 10 minutes: put the panel cable back on the port the controller manual documents for an HMI, set both ends to the same five serial values, for example 9600 baud, 8 data bits, no parity, 1 stop bit, with the station address matched on each side, and verify one read. A timeout says the panel received no usable reply from the endpoint its driver is configured to address. An invalid checksum says bytes arrived but failed the integrity check the protocol applies to every frame. Both faults live in the communications path, so work the path in that fixed order. Rebuilding the screen project comes last, and it almost never fixes this pair.
What each error points to
Read the two messages separately, because each one narrows the search.
- PLC timeout, on every poll. The panel asked and nothing usable answered. Mismatched serial parameters between panel and controller produce this immediately, and so does a driver aimed at a port the cable never reaches.
- Invalid checksum received PLC 0. Frames arrived but failed the integrity check. Wrong cable wiring, a missing signal common or electrical noise garbles bytes this way, so treat the screen project as the last suspect for this message.
- Timeouts on some polls, checksum errors on others. The link is alive but marginal. Expect a loose terminal screw or a damaged conductor before you suspect the settings again.
- The errors started after a communication module went into the rack. Check whether that module is documented as a host interface for this panel before configuring anything on it.
Panels print the timeout under different codes; one widely used family documents it as PLC-001 in its error table, which lists the same causes worked through below.
Confirm the driver and the cable reach the same documented port
This check needs no tools, and when it finds the fault you are done diagnosing.
- Record the controller model and firmware version, the panel model and firmware version, every communication module in the rack, and the full cable path from panel to controller.
- Name the endpoint the panel driver is configured to address, and name the physical port the cable terminates on. If the two names differ, you have found the fault before touching a setting.
- Open both manuals and confirm that port is documented as a host interface for the panel's protocol. A serial module added to a rack to serve other devices serves the panel only if the module documentation lists the panel's protocol and controller family.
- Test on the documented port before buying hardware: connect the panel to that port with the cable and wiring the manual specifies, and leave every other drop exactly as it is.
- If no manual documents a supported host and interface for this pair, stop swapping ports and confirm the supported combination with the manufacturer's documentation or support line before changing anything else.
A project that builds and runs can still target the wrong endpoint, so run this check even when the screens draw perfectly. A port that refuses to open at all is an earlier failure stage; the CODESYS COM.Open error 5004 fix covers that case on a serial port.
Match the five serial settings at both ends
Both ends must agree on five values. In the panel project they live in the driver or device entry for the controller; on the controller side, in the port configuration of the software that owns the link.
- Baud rate: the bits-per-second speed of the line, written for example as 9600 baud. It has to match exactly.
- Data bits: 7 or 8, most often 8.
- Parity: none, even or odd. Parity is a simple error detection bit, so a mismatch shows up as rejected frames.
- Stop bits: 1 or 2.
- Station address: the endpoint number both devices use to recognize each other's frames.
Set both ends to the values printed in the two manuals. Where a manual is missing, 9600 baud, 8 data bits, no parity, 1 stop bit is the most common factory default in serial equipment and the first pair of values to try; station addresses 0 and 1 are the usual starting points. Read the values back from each port instead of carrying them over from another port or module, and check that the protocol you selected is supported on the physical port you chose, not merely present in the driver list. If your protocol is Modbus RTU, these same five values decide a no-reply; the Modbus RTU no-reply and address fix walks that protocol end to end.
Scenario: a new install reports PLC timeout and invalid checksum received PLC 0
The inputs, as the installer recorded them:
- The panel project builds, the runtime runs and the screens draw, but no I/O value ever updates over 15 minutes of watching.
- Two errors repeat on screen: "PLC timeout" and "invalid checksum received PLC 0".
- The panel polls every 1000 ms over a 3 m cable that terminates on a serial communication module added to the controller rack to serve several RS-232 signal conditioners.
- The module manual documents that module for a different controller family; the controller's on-board serial port is the port its own manual gives for an HMI.
The rule the messages follow: a timeout means the panel received no usable reply from the endpoint it addresses inside its response window, and an invalid checksum means bytes arrived but failed the integrity check. Together they say the panel is talking into a port where no host for it is listening, or where its frames share wire with other traffic.
The check is arithmetic, which is why wiring shows up here. Take a simplified frame that ends in an additive checksum: the data bytes are 0x02, 0x41, 0x00 and 0x02, so the sender appends 0x02 + 0x41 + 0x00 + 0x02 = 0x45. A crossed transmit line or a burst of noise flips one bit in the second byte, and 0x41 becomes 0x61, a change of 0x20, which is 32 decimal. The receiver computes 0x02 + 0x61 + 0x00 + 0x02 = 0x65, the comparison against 0x45 fails, and the panel prints invalid checksum received. Most industrial protocols use a CRC instead of a plain sum, and a CRC catches the same single-bit change, so the outcome is identical: one wrong bit rejects the frame.
Result: the endpoint the driver names and the port the cable reaches are different devices. The added module is not documented as a host for this panel, so the polls go to a port that never answers as one, and the frames the panel does hear arrive from a shared serial path around the conditioners.
Decision: move the panel cable to the on-board serial port the controller manual documents for HMI use, leave the module and its conditioner drops exactly as they were, match the five serial settings on the new port, and verify a single read. If the module manual had documented the module as a valid host for this panel, keep the topology and work through settings and cable instead.
Check the cable before you change the project
Bring the machine to a safe state before you disconnect or re-terminate anything.
- Match the wiring the manual prints, end to end. On the common 9-pin D-sub RS-232 connector, a link between two DTE ends needs pins 2 and 3 crossed, and a DTE-to-DCE link is straight through; the DTE/DCE line in each manual decides which one yours is.
- Verify the signal common is wired and that the shield lands where the manual says.
- Inspect for loose terminal screws, damaged conductors and runs that share a tray with motor or power wiring.
- Bench-test with a short known-good cable, 2 m or less, if you have one.
- Make one correction, retest, then make the next. Changing wiring and settings together hides which one fixed the fault.
- Do not add termination or bias hardware on a guess; a panel-length RS-232 link needs none.
Retest with one read, then restore the rest
- Clear or acknowledge the displayed errors using the panel's documented procedure.
- Read one value that changes on its own, such as a clock or counter register the controller documentation lists, and confirm it updates across several polls over 2 minutes.
- Test a write only on a noncritical point approved for commissioning, and only if the control design permits panel writes at all.
- Reconnect the other serial drops one at a time, and watch for recurrence after each.
- If the path tests clean and conflicts continue, update firmware: outdated firmware on either device can produce them, so bring both to the versions their manufacturers document and retest.
When a clean read works but tags then fail to resolve, that is the next stage; fixing HMI invalid address errors when tagging PLC memory covers it. Keep the panel dedicated to the machine; a separate shop-floor notice display can carry the shift board and announcements beside it.
The order to work in
- The documented host port for the panel's driver.
- Five serial settings matched at both ends.
- Cable wiring, signal common and shield per the manual.
- One verified read, then the remaining drops one at a time.
- Firmware and hardware changes last.
Recommendation: When a panel shows PLC timeout and invalid checksum errors together, put its cable back on the port the controller manual documents as a host interface, set both ends to the same five serial parameters, and verify one read before restoring anything else. Replace modules or cables only after a controlled test on a documented port has failed.
Questions
The timeout appears every few minutes instead of constantly. What does that tell me?
The link is alive but marginal. A settings mismatch produces an immediate, constant timeout; an intermittent one points at the physical layer. Re-terminate both cable ends and tighten the terminal screws, inspect the conductors for damage, and move the cable out of any tray that shares motor or power wiring. Make one change and retest before the next. If the wiring checks clean, outdated firmware on either device can also cause intermittent conflicts, so bring both devices to the versions their manufacturers document and retest.
The checksum message names PLC 0 but my controller is set to station 1. Why?
The trailing number is the station the panel was exchanging with when the check failed. If your controller answers as station 1, the panel driver is still addressing station 0, so at least one device is processing frames addressed to nobody. Set the station address in the panel driver entry to match the controller's configured station, and verify the same baud rate, data bits, parity and stop bits on both sides while you are in there.
How long should the full check take?
Plan 30 minutes for the whole sequence: 5 minutes to confirm the driver points at the port the controller manual documents for an HMI, 10 minutes to read back and match the five serial settings at both ends, and 15 minutes to inspect and correct the cable. Budget more only if the port is not documented as a host interface, because then you are confirming the supported combination with the manufacturer before you touch anything.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.