An FX3GE can remain reachable through its web monitoring interface while GX Works2 remote access fails. That result confirms only that the web service reaches the PLC through the router; it does not confirm that the GX Works2 engineering connection follows the same port or configuration path.
Separate Web Monitoring from GX Works2 Access
Start by treating web/data monitoring and GX Works2 programming as separate connection tests. In the reported case, the PLC had a static IP and web monitoring worked, but forwarding port 5556 did not establish a GX Works2 connection. No incoming GX Works2 connection was visible in the web monitoring tool.
Do not interpret this as proof that port 5556 is incorrect. The evidence shows only that forwarding it was insufficient under the tested configuration.
Resolve the Port and Router Ambiguity
| Item | Evidence | Engineering decision |
|---|---|---|
| Port 5556 | Forwarded for the attempted FX3GE/GX Works2 connection, without success. | Do not assume forwarding this port alone completes the route. |
| Port 5551 | Reported for GX IEC Developer communicating with an FX3U CPU. | Do not transfer this value to FX3GE/GX Works2 without Mitsubishi confirmation. |
| GX Works2 port | Reported as not user-changeable. | Determine the port used by the software and configure the router around it; do not search for an unsupported port override. |
| Router Relay function | Raised as a possible required setting, including the router IP address. | Inspect the existing FX3GE Ethernet configuration and verify whether this function applies; the evidence does not establish that it is mandatory. |
Troubleshoot Without Exposing the PLC
- Confirm the PLC static IP and web/data monitoring access, recording which service succeeds.
- Check the router rule for the engineering connection independently of the web rule. Confirm that it targets the FX3GE address.
- Inspect the configured Router Relay function and router IP address, if present. Treat this as a diagnostic check rather than a confirmed requirement.
- Ask Mitsubishi through an official support channel to verify the exact ports required by FX3GE with GX Works2. The available evidence does not resolve whether 5556 is sufficient or whether additional ports are involved.
- Forward only the confirmed ports and retest GX Works2. Do not leave the PLC in a DMZ merely because that restores access; the reported DMZ configuration exposed all ports.
Control the Risk of Remote Program Changes
One reported installation lost Ethernet access after a remotely modified program was uploaded because the remote GX Works2 session did not provide access to the Ethernet parameters. Recovery required a USB connection to restore those parameters, and the PLC reportedly needed a power cycle between Ethernet setting changes. Treat this as observed behavior rather than a confirmed characteristic of every FX3GE.
Before a remote upload, record the working Ethernet settings and ensure local USB recovery is available. After the upload, verify web monitoring and GX Works2 access separately. If Ethernet settings must be changed, plan for the reported power-cycle requirement and confirm the result after each change.
FAQ
Why can I monitor an FX3GE remotely but not connect with GX Works2?
Web/data monitoring and GX Works2 use separate connection paths. Working web access confirms the static IP and web route, but it does not verify the port or router settings required by GX Works2.
Can I change the GX Works2 Ethernet port to 5551 or 5556?
The evidence reports that the GX Works2 port cannot be changed. Port 5551 was associated with GX IEC Developer and an FX3U CPU, while forwarding 5556 did not by itself establish the reported FX3GE connection.
Should I put an FX3GE in a DMZ for remote programming?
No permanent DMZ deployment is supported by the evidence: it restored access in one case by exposing all ports. Verify the required FX3GE/GX Works2 ports with Mitsubishi and forward only those ports.