QJ71E71-100 Communication Error Troubleshooting Guide

Why QJ71E71-100 Faults Are Often Misdiagnosed

A communication alarm on the HMI does not prove that the QJ71E71-100 module has failed. It only means that one device in the communication path cannot exchange data as expected. The Ethernet module is one part of that path. The actual fault may be in the HMI project, PLC CPU status, cable, network switch, IP settings, connection configuration or the device trying to communicate with the PLC.

The safest approach is to separate the system into layers and test each layer in order. If the physical link is down, open settings do not matter yet. If the PLC CPU is in STOP or ERROR state, an HMI may report communication failure even though the Ethernet module is electrically healthy.

Common Symptoms and What They Usually Mean

Start with the Physical Link

It is tempting to open software first, but the physical layer should be checked before spending time on parameters. A damaged RJ45 plug, poor cabinet cable, failed switch port or missing switch power can produce the same visible symptom as a configuration problem.

Physical Link Checklist

• Check whether the Ethernet link LED is on at both module and switch.
• Replace the cable with a known-good short cable for testing.
• Move the cable to a known-good switch port.
• Check whether the cabinet switch is powered from the same 24VDC circuit as other failed devices.
• Inspect RJ45 plug locking tab, bent contacts and corrosion.
• Check whether the cable is routed near high-noise motor, inverter or power wiring.
• Check whether communication fails when the cabinet door moves or vibration occurs.
• Confirm cable length and quality are appropriate for the installation.

If the link LED never appears with a known-good cable and switch port, then the module port, switch, or client-side port should be investigated. Do not change PLC parameters until the physical link is stable.

Ping Is Useful, But It Does Not Prove PLC Communication Works

A successful ping only confirms that a device responds at the IP layer. It does not prove that the HMI driver, SCADA protocol, TCP open setting, fixed buffer, port number, device address or PLC program access is correct.

When Ping Works but Communication Fails

• The HMI or SCADA uses the wrong PLC driver.
• The port number does not match the module open setting.
• TCP is configured on one side while UDP is expected on the other.
• The open setting was not downloaded after module replacement.
• The client requests a device area or address range not supported by the project.
• The connection count is already used by other clients.
• Network routing allows ping but blocks application-level communication.
• PLC CPU is not in the expected operating state.

IP Address, Subnet and Duplicate Address Checks

Many QJ71E71-100 problems are not hardware failures. They are ordinary network problems inside a control cabinet. A duplicate IP address can create intermittent faults that seem random. A wrong subnet can allow local testing from one laptop but fail from the HMI or SCADA station.

Duplicate IP Clues

• Communication works after reboot but fails again later.
• Ping response time changes unexpectedly.
• The HMI connects sometimes, while SCADA or a PC disconnects.
• A new device was added to the cabinet or plant network recently.
• Only one client can communicate reliably at a time.
• Switch MAC address table or network scan shows inconsistent mapping.

Open Settings: The Part People Often Forget After Replacement

The QJ71E71-100 is not only an Ethernet port. It must be configured for the intended communication method. After a module replacement, a physical swap may not restore operation unless the same IP address, open settings and related parameters are restored.

Open Setting Troubleshooting Questions

• Was the module recently replaced?
• Was the PLC parameter file downloaded after replacement?
• Does the HMI or SCADA use TCP or UDP?
• Does the client connect to the correct port number?
• Is the module configured as expected for passive or active connection behavior?
• Does the PLC program use fixed buffer communication?
• Are there enough open connections for all clients?
• Does engineering software occupy a connection during testing?

Connection Count and Polling Load

Intermittent communication may appear when too many devices poll the PLC too aggressively. A typical line may have one GOT HMI, one SCADA server, one engineering laptop, one data collector and one gateway. Each device may be harmless alone, but together they can create timing and connection-management problems.

Polling and Load Checks

• Check how many clients connect to the module at the same time.
• Reduce SCADA or OPC polling rate during troubleshooting.
• Temporarily disconnect nonessential clients.
• Check whether communication fails during shift start, recipe download or reporting upload.
• Check whether engineering software is connected while the HMI and SCADA are also active.
• Review whether new data-collection software was added recently.
• Group data reads efficiently rather than polling many scattered addresses.

TCP vs UDP: Check Both Sides

When one side expects TCP and the other side is configured for UDP, communication will fail even if the Ethernet link and IP address are correct. The same problem happens when the port number or connection role differs from the client configuration.

Protocol Mismatch Clues

• Ping succeeds, but application connection always times out.
• One SCADA driver works while another fails.
• Communication fails only after project download or module replacement.
• The external device log shows connection refused or no response.
• The HMI uses a different Mitsubishi driver than the original project.

HMI Cannot Connect to QJ71E71-100

When a GOT or third-party HMI cannot connect to the PLC through QJ71E71-100, check the HMI project and the Ethernet module together. The HMI screen may show a simple communication alarm, but the root cause may be very specific.

HMI-Side Checks

• Confirm the HMI project is the correct machine version.
• Compare HMI communication settings with a backup or old screenshot.
• Check whether the HMI can communicate with another known-good PLC.
• Check whether the PLC can be reached from an engineering PC through the same switch.
• Confirm whether the HMI and PLC are on the same subnet.
• Check whether the HMI was replaced and downloaded with a default project.

SCADA, OPC or Data Logger Cannot Read PLC Data

SCADA and data-collection faults are usually more subtle than HMI faults. The machine may still operate, but production data, alarms or historian records stop updating. In this situation, do not replace the Ethernet module before reviewing the client driver and polling behavior.

SCADA Troubleshooting Checklist

• Check whether the SCADA driver supports the exact Mitsubishi communication method used.
• Confirm tag addresses and data types.
• Reduce polling rate and test a small group of tags.
• Check whether the problem affects all tags or only one data block.
• Review whether a firewall, VPN, VLAN or router was changed.
• Confirm whether the PLC CPU is in RUN and updating the requested data.
• Check whether another client already uses the expected connection.
• Compare current SCADA settings with the last known working backup.

When to Suspect Hardware Failure

After physical link, IP settings, open settings, client configuration and PLC status are checked, the module itself may become the likely suspect. Hardware failure is more likely when symptoms remain consistent across known-good cables, known-good switch ports and restored parameters.

If a module is suspected to be damaged by surge, grounding fault or cabinet contamination, check the root cause before installing another unit. Otherwise the replacement module may fail again.

Replacement Checklist for QJ71E71-100

Replacing QJ71E71-100 should be treated as a controlled maintenance task. Record the old module, backup the project, verify parameters and validate communication after installation.

Before Buying a Replacement Module

• Confirm the exact model is QJ71E71-100.
• Photograph the current module label and rack slot.
• Confirm whether the module is connected to HMI, SCADA, OPC, gateway or robot.
• Check whether Ethernet parameters are available in the PLC project.
• Confirm whether a same-model spare is required urgently.
• Ask whether the offered part is new, surplus, used or refurbished.
• Request real photos of the exact unit.
• Request test evidence if the unit is not factory sealed.
• Confirm warranty and return conditions before shipment.

What Test Evidence Should a Supplier Provide?

For an Ethernet module, a useful test is not only a photo of the front label. The buyer should ask for evidence that the module powers on, is recognized, and can perform the communication function relevant to the repair situation.

Field Case: HMI Alarm After QJ71E71-100 Replacement

A common field situation is straightforward: the old module was replaced, link LEDs appear normal, but the HMI still shows communication error. In many cases, the replacement module is not the issue. The missing step is parameter restoration.

What to Do

• Compare old and new module IP settings.
• Restore PLC parameters from the known-good project.
• Confirm open settings and port numbers.
• Confirm HMI driver and target address.
• Power cycle according to the maintenance procedure if required.
• Test with engineering PC, HMI and SCADA separately.

Recommended LcdChip Parts and Related Content

QJ71E71-100 is often sourced together with Q Series CPUs, GOT HMI panels and migration-related parts. If communication faults appear on an older production line, record the full system instead of asking for only one module.

How to Prepare a QJ71E71-100 RFQ

A good RFQ should help the supplier confirm the exact part and understand the communication problem. If the machine is stopped, include photos and symptoms rather than only a model number.