Remote HMI project connection fails while web and FTP work

Why do the web server and FTP work when the project connection fails?

The web server, FTP and the project transfer are three separate services on three separate ports, 80, 21 and 9999. Reaching two of the three ports tells you nothing about whether the third is open. The three services run independently inside the panel, and the network treats them independently too. A firewall, a NAT rule or a VPN at either end passes traffic port by port, so a rule set that forwards 80 and 21 can still say nothing to port 9999. The two working services are evidence of the path and nothing more. The failing one needs its own test.

What each symptom points to

• Web page loads and FTP logins succeed from the remote PC: the wide-area path is up and ports 80 and 21 pass.
• Browse finds nothing: browse is a broadcast, and the next section covers why that dies at the first router.
• The IP entry sits in the offline link list but the indicator goes red in about 1 second: the unicast attempt is running out of time or being refused, and the next two sections separate those cases.
• Ping succeeds with replies around 1 second: the IP path is fine and the connection timeout is too short.
• Ping fails: repair the path first, because no software setting substitutes for a working route.

Why can't the software find the panel when I browse?

Browse is a broadcast, and a broadcast stops at the first router. A panel on the far side of a site-to-site VPN or the open internet never appears in the list, no matter how healthy the link is. Discovery asks every device on the local subnet, and routers do not carry that question onward. A remote panel never answers a call that dies at your own gateway. The working method skips discovery entirely and dials the panel directly, which the offline link list in the next section does. On some older installations the broadcast side has its own settings; configuring older broadcast settings across routers covers what those settings change.

How do I add a remote panel by its IP address?

You type the panel's IP address into the offline link list in the engineering software: open the read-from-panel connection setup, choose Ethernet, open the Offline Link List tab, select Add, enter any name plus the panel's IP, then select OK and pick the entry. The entry stays for every later session. The steps:

1. Open File > Read From Panel in the engineering software.
2. Under Connection Setup, check Ethernet.
3. Open the Offline Link List tab and select Add.
4. Enter a name for the entry and the panel's IP address. The name is a label for your list only and never has to match the panel's own name; the IP address is the part the software dials.
5. Select OK, select the new entry from the list, and select OK again. The software now sends a unicast connection to that address, and unicast crosses routers and tunnels.
6. Select Read Project to pull a copy of the running project onto the PC.

Check it worked: reopen the Offline Link List, confirm the entry's address matches the address that answers ping, and connect. A panel absent from browse results is normal at this distance and is not a fault.

What does a red light after about one second tell me?

A red indicator after about 1 second means the software's connection attempt timed out. On a link whose ping replies need 884 to 1158 ms to come back, the panel's answer arrives after the software has already given up. Measure before changing anything. From the same PC, on the same network, at the hour you usually work, ping the panel and write down the minimum and maximum reply time. The maximum is the number that matters, because a timeout has to clear the worst reply, not the best one. Distance, shared links and aging equipment set that delay long before the software runs; connecting a remote HMI screen 1,500 feet from the PLC walks the physical side of a long panel link.

The other suspect at this stage is the port. Web and FTP answers reach their own services and do not prove the transfer port is forwarded. Firewalls pass ports one by one, and 9999 can still be closed at either end. With ping clean and the light still red, the port becomes the next check, and HMI remote access port forwarding: test each step tests each hop in order.

Worked example: can a worst reply of 1158 ms survive a 1-second connection timeout?

No. With that worst round trip, the answer to the connection request lands 158 ms after a 1000 ms timeout expires, so the attempt fails while the panel is answering the whole time.

The case: web and FTP answered from the remote PC, browse found nothing, the IP entry turned red in about 1 second, and ping measured a minimum of 884 ms and a maximum of 1158 ms. Call that maximum W and walk the numbers:

• Opening a connection costs at least one full round trip: request out, answer back. Worst measured reply: W = 1158 ms.
• Red after about 1 second sets the effective timeout at 1000 ms. W - 1000 ms = 158 ms, so at the worst reply the answer arrives after the software has already quit.
• Even the best reply, 884 ms, fits the first round trip and leaves 1000 ms - 884 ms = 116 ms, while the software's own session opening needs at least one more round trip. Both cases fail.
• Sizing rule: budget three round trips at the worst reply, one to open the connection, one for the session exchange and one in reserve for the panel's load: 3 × W = 3474 ms. Enter 4000 ms, which leaves 4000 ms - 3474 ms = 526 ms of margin.

Retry and read the timing of the result:

• Red after about 4 seconds: the attempt sat silent through the whole timeout, so nothing answers on the transfer port. Ping still returning in about 1 second plus 4 silent seconds points at a firewall dropping the port.
• Red after roughly 1 second, about one round trip: something refused the attempt quickly, so the port is closed at the far end and the timeout was never the cause.
• Connection completes: timing was the cause, and the session is yours.

A packet analyzer on the engineering PC shows the same picture in raw form: whether the attempt leaves the PC and whether anything answers it.

Where do I change the connection timeout, and what value do I enter?

In the software's connection or transfer settings. Where a release keeps no dialog field for it, the values sit in a plain-text configuration file in the software's install folder, and the documentation for your exact release names the file and entries. Close the software first, and copy the file to a backup before you edit it. Change one thing: the connection timeout, to 4000 ms from the worked example. The software is designed to read the edited value on its next start, so restart it and retry the unicast connection from the offline link list. Write down what you changed and what happened, because you may need to walk it back.

Keep the change in bounds. A timeout of 3 to 5 seconds fits a link with replies in the 884 to 1158 ms range. Pushing it to 30 seconds turns every genuine failure into a long wait and buries the timing evidence you just used. If the connection still fails after one controlled change, restore the backup and go back to the network checks, because a timeout cannot open a closed port.

The same race between reply time and patience decides serial links; an HMI to PLC serial timeout with a dead com light is that race on a serial run. And if panels that used to connect locally start failing after your edits, restore first, then check the switch path; a panel project download that fails through the network switch gives the test order.

Can the pass-through port give me access to the PLC program?

No. Pass-through exists so several client panels can share the server panel's single PLC connection, and the pass-through service, reported on port 11110, cannot carry PLC programming traffic. The client panels sit on Ethernet, the server panel holds the one connection to the PLC, usually serial, and PLC requests relay through it. That relay serves runtime traffic between panels, nothing else. PLC logic changes go through the PLC's own programming software on its supported connection, on site or over the remote path the PLC vendor supports. Opening extra services to the internet as a workaround only widens the exposure.

What to have ready before you push a project to a panel 1,000 miles away?

Have the running project copied to the engineering PC and to a file at the site, do the write during planned downtime, and treat every remote write as a transfer that may fail and need the local copy restored. A read is the safe direction: Read Project copies the running project to your PC and leaves the panel as it was. A write replaces the project the panel is serving, and on a panel operators are watching, a wrong or half-loaded project misleads the people acting on it. Keep one safety rule: do the write in a planned window, with a person at the panel who can cycle power and reload the local copy if the transfer dies mid-write.

The PLC keeps its own logic and schedules while the panel is down; keeping PLC schedules running when the HMI panel is offline covers what continues and what waits.

Recommendation: For any panel you service over a wide-area link, enter it on the offline link list by IP, ping before every session and keep the worst reply time. When replies run near a second, raise the connection timeout to 4000 ms before you suspect the panel, the project or the VPN. Read from the panel before you write, do writes in planned windows, and open only the ports the transfer service needs.

Questions