A project transfer that fails over a remote link is a path problem before it is a timeout problem. The documented default connection timeout is 3 seconds, entered in whole seconds, which already covers about 13 round trips on a 230 ms link. Add the panel by IP on the offline list and open TCP 9999 before touching any timeout value.
The timeout you are after is measured in seconds, not milliseconds. The connection between the panel's programming software and the panel defaults to 3 seconds, and the value is entered as whole seconds. A 230 ms ping is 0.23 s, so that default already gives a remote link about 13 round trips per attempt before it gives up. When a panel takes a project at the office but the same transfer fails from home, the cause is almost always the route: online discovery does not cross a VPN, so the panel has to be added by IP address on the offline list, and TCP 9999 has to pass end to end, because that is the only port project transfer uses. Work the path first and the timeout last.
The timeout is in seconds, and 3 is the default
The setting lives in the programming software's configuration file, EA_.ini, and the documented default reads PanelTimeout=3. The units are seconds, so the software allows 3 s for the connection to the panel, more than ten times the 0.23 s round trip you measured from home. The key covers one operation only: the connection between the programming software and the panel while a project transfers. It has nothing to do with the panel's logging, its log email, or its polling of the PLCs. Treat it as the last check in the job: first the link entry, then the port, then the timeout. A value typed in milliseconds lands a thousand times too large, which is why the units come before any number you enter.
Symptoms and what each points to
- The panel appears in the online list at the office but never from home. Online discovery does not cross a VPN tunnel. Add the panel on the Offline Link List tab by typing its IP address.
- The PLCs respond from home but the panel entry will not connect. The PLCs and the panel listen on different ports, so a working PLC link says nothing about TCP 9999.
- The panel connects and the transfer starts, then dies part way. A rule on the route is dropping the session mid-transfer. Test the port before touching the timeout.
- The transfer fails instantly after you raised the timeout. An instant failure is a wrong address or a closed port; a large timeout would fail slowly, not instantly.
- The panel's nightly log email fails while daytime project transfers work. That is the log transfer on its own path; the project-transfer timeout has no effect on it.
A transfer that crawls everywhere, the plant network included, is a separate fault; a project download that takes 2 minutes has its own causes and its own fixes.
Scenario: the same panel from the office and from home
On the plant network the panel answers a ping in about 32 ms. From home over a cable link the same panel answers in about 230 ms. The default timeout is 3 s, which is 3000 ms. The headroom in round trips:
- Office link: 3000 ms ÷ 32 ms ≈ 93 round trips per attempt.
- Home link: 3000 ms ÷ 230 ms ≈ 13 round trips per attempt.
The default is already more than ten times your worst measured round trip, so the 230 ms link is not a reason to change the value. The mistake to avoid is typing milliseconds into a seconds field. Enter 300 intending 300 ms and the software reads 300 s, which is 5 minutes: 300 s ÷ 0.23 s ≈ 1300 round trips per attempt. A dead route that used to report failure in 3 seconds now ties the software up for 5 minutes and repairs nothing, because the port is still closed.
Fix the path first: add the panel by IP address
- Connect the PC to the plant network through the site's approved VPN.
- Open the panel browse dialog in the programming software.
- Select the Offline Link List tab and type the panel's IP address. The Online Link List relies on local discovery and will not find a panel across a tunnel.
- Select the entry you added. When the connection is made, the OK button becomes selectable.
- If OK stays greyed out, stop and correct the address or the route. No timeout value changes a wrong address.
Check: the panel entry is selectable and the OK button lights up. Only then does the port matter.
TCP 9999 is the only project-transfer port
Project transfer runs on TCP 9999, and the documentation names no other port for it. Every device on the route, including any rule on the VPN or firewall, has to pass TCP 9999 to the panel's address. PLC traffic over the same tunnel rides the PLC's own port, so working PLC links do not establish that 9999 is open.
Other services on the route listen on their own ports. Do not forward one of these and point the software at it:
| Service on the route | Port |
|---|---|
| Project transfer to the panel | TCP 9999, the only port documented for it |
| Panel pass-through | TCP 11110 |
| Modbus TCP devices | TCP 502 |
| EtherNet/IP devices | TCP 44818 for explicit messaging, UDP 2222 for I/O messaging |
| Panel web server | TCP 80 |
| Panel email | TCP 25 |
| FTP | TCP 21 |
If a modem on the route reserves 9999 for its own use, there is no alternate port to switch to, so the fix belongs to the route: a forwarding rule that passes 9999, or equipment that gives the port up. Keep the panel behind the site's approved VPN, and do not forward an industrial panel straight onto the public internet to work around a closed port.
Last: edit the timeout in EA_.ini
Edit the file only after a transfer has timed out on a route you have checked end to end: panel selectable on the offline list, TCP 9999 open from the remote PC to the panel.
- Make a backup copy of
EA_.iniand keep it where you can find it. Before you send a new project remotely, also pull the running project from the panel to your PC so you hold the last known good copy. - Close the programming software, open
EA_.ini, and add the timeout key with a value in whole seconds. The documented default readsPanelTimeout=3. Only one line is documented for this setting; the instruction mentions a second line but names none, so add nothing you cannot point to. - Save the file and start the software again.
- Open the configuration once more and confirm the key and value read back as typed.
Run a full project transfer over the same remote path afterwards. If a transfer still times out with the port confirmed open, record the exact message and the time of failure and take both to whoever owns the firewall. If behavior gets worse, put the backup back.
A transfer that completes but leaves a project that will not open is a different fault; see a missing firmware file in an HMI project transfer, and check the panel's firmware revision before your next transfer.
Keep the log email fault on its own path
If the fault is the panel's nightly log email rather than a project transfer, the timeout key is the wrong knob. A panel that sets its SYS ERR EMAIL ERR bit in the event manager every night, on a log file of almost 1 MB a day that never arrives, has two panel-side levers: cut the log size by archiving or clearing more often, and ease what else the panel does over Ethernet at midnight, because heavy PLC polling on the same link can slow the send until the mail server gives up. Test the two operations apart: a project transfer from your PC to the panel, and a log send from the panel to the mail server.
The decision
Recommendation: leave PanelTimeout=3 in place until the path is checked end to end. Add the panel by IP address on the Offline Link List tab, confirm TCP 9999 passes from the remote PC to the panel through the approved VPN, and edit EA_.ini only if a transfer still times out on that checked route, entering whole seconds. On a 230 ms link the 3-second default already allows about 13 round trips per attempt. A port that cannot be opened stops remote transfer until the route changes, and a failing log email is fixed with log size and midnight traffic, never with the timeout key.
Questions
Where is the full list of port numbers the panel uses?
Search the programming software's help file for the phrase Ethernet Connections Port. It lists every service the panel listens on, project transfer included, with the port each one uses. Hand that list to whoever owns the firewall so they pass only what the panel needs, and note that FTP's port is user-selectable, so confirm the configured value before a rule is written.
If the route cannot pass TCP 9999, is there another port for project transfer?
No. The documentation gives project transfer one port, TCP 9999, and names no alternate. A route where the modem reserves 9999 for itself leaves remote transfer unavailable until the route changes. Changing the timeout will not help, because the failure is a closed port, not a slow link. Fix it with a forwarding rule or different equipment, and keep the panel behind the approved VPN.
What value should I type if a checked route still times out on long projects?
Type whole seconds and step up in small amounts: double the current value, retry the same transfer, and stop at the first value that completes reliably. Never type a milliseconds figure. On a 230 ms link, 3 seconds already covers about 13 round trips, so a value that still fails on a route you have checked end to end is pointing at a port or rule, not at the clock.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.