CJ1M Modbus RTU: CRC Memory Is Required, Not Optional

CJ1M Modbus RTU traffic can reach the CPU host port without producing a reply when the inherited slave ladder lacks its required memory image. In the recovered installation, restoring the original CPU12 program and loading the CRC table into PLC memory corrected the response. Treat serial settings as necessary prerequisites, but restore the matched program and .mem file before rewriting communications logic.

Implementation Approaches

The host-port design remains the shortest recovery path when the application normally communicates only every 5–10 minutes and the original program package is available. The serial-card approach is a redesign option, not the first correction for a previously operating installation. It becomes attractive when the matched ladder and memory image cannot be recovered or when future communications requirements justify dedicated serial hardware.

Recommended Recovery Baseline

1. Before anything else, identify the CPU model for which the program was built. The working baseline in this case was CPU12; testing converted code on CJ1M-CPU11 introduced suspected ladder or subroutine corruption.
2. Restore the original program to the matching CPU12. Do not move on until the programming environment reports a complete transfer and the intended Modbus slave task and receive task are present.
3. Load the companion .mem file specified by the application documentation. This memory image supplies the CRC table required by the ladder implementation.
4. Confirm that the memory transfer completed and that its target words contain data. A program transfer does not prove that a separate memory-file transfer occurred.
5. Return the PLC to its intended operating mode and poll one known slave address. Proceed to serial diagnostics only after the program and memory image form a matched set.

Keep a copy of the CPU project and .mem file as one controlled release. If either component changes, repeat the communications test before deploying it.

Serial Configuration Checks

1. Match the master to 9600,N,8,1 and select Modbus RTU.
2. Poll only one slave address and one simple request while troubleshooting. Do not move on until the communications LED flashes for each transmitted poll.
3. Monitor the receive count and the first-stage receive buffer online. A flashing LED with a count fixed at zero narrows the fault to frame admission, interrupt handling, port configuration, or the executing ladder path.
4. Check whether another task or instruction owns, resets, or reinitializes the same port or receive-memory area.
5. Confirm that the cyclic slave task scans and that the receive interrupt can call the expected routine. Watch an existing diagnostic word or add a temporary test counter only if project change control permits it.

No-Response Mechanism

The communications LED reports physical receive activity; it does not prove that the PLC accepted a complete Modbus request. A slave replies only after the serial layer receives a correctly framed message, the destination address matches, and the implementation validates the request.

Modbus RTU attaches a CRC to each frame. This ladder implementation depends on a CRC lookup table stored in PLC memory. If the required .mem contents are absent, the code cannot execute its intended CRC processing correctly, so a request may never reach the response-building path. Loading only the ladder therefore leaves a hidden runtime dependency unresolved.

The fixed receive count provides a second clue. If the LED flashes but the monitored count never increments, first determine whether that count records raw characters or only frames accepted by the application. Trace where the ladder increments or clears it. A counter that represents accepted messages may remain at zero after address, framing, or CRC rejection; a raw-byte counter remaining at zero points earlier toward interrupt or port handling.

CPU Conversion and Memory Integrity

Program conversion between CPU12 and CPU11 is not equivalent to proving runtime compatibility. The failed test involved code written for CPU12 and converted for CPU11; the converted ladder or subroutine was suspected of being damaged. The original code worked after it was returned to CPU12 and the CRC table was loaded.

1. Compare the converted project with the original at the task, subroutine, interrupt, symbol-address, and data-memory levels.
2. Check every communication buffer and CRC-table reference for truncation, overlap, or remapping.
3. Verify that the receive interrupt still targets the intended routine after conversion.
4. Do not diagnose the converted CPU and a missing .mem file at the same time. Establish operation on the original CPU12 baseline first, then perform a controlled CPU migration if required.

A successful program download proves syntax and transfer completion, not preservation of external memory tables. Archive the ladder, comments, symbols, task configuration, and memory image together to prevent the same partial restore.

Response Verification

1. Monitor the communications LED, receive count, request buffer, and response path simultaneously.
2. Send a single poll to the configured slave address using 9600,N,8,1.
3. Confirm one LED indication per request and verify that the receive count or accepted-message indicator changes.
4. Check that the response uses the requested slave address and that the master accepts its CRC.
5. Repeat the poll after a power cycle. This confirms that the CRC table and other required memory contents survive the installation’s normal restart sequence.
6. Allow the SCADA system to resume its normal 5–10-minute polling interval and confirm multiple successful transactions without counter resets, intermittent silence, or port reinitialization.

Frequently Asked Questions