A browser that shows the panel but ignores the buttons is failing at one of five layers: destination address, active interface, physical link, firewall port or session permission. Test them in that order with the panel's own IP, the wireless card off, a sound cable and a fresh session. In the field case behind this article, control returned after a restart.
You granted full remote access in the panel software, the browser finally draws the screen, and every button press does nothing. That combination sits in the path between the browser and the panel far more often than in the panel or the PLC. Work five layers in order: the address you type, the network interface the request leaves on, the cable the request travels through, the firewall port, and the session the settings apply to. Every step below carries numbers you can act on: a 255.255.255.0 subnet mask, a 60-second cable nudge test, three documented permission levels, and the worked example at the end runs a whole fix with example addresses such as 192.168.10.31.
Why does the browser show the panel but the buttons do nothing?
You are looking at a view-only session: control is a separate permission level in the remote HMI software, and a session opened before you granted it keeps the old limits until you start a new one. Your remote HMI documentation gives each user account one of three levels: View mode, View and Screen Control, and Full Control. A screen that draws and ignores input says the network path works and the account is below Full Control, or the session predates the change. Both are settings, so move through the layers below before you suspect hardware.
- The browser cannot find the address at all. Wrong destination, or the request left through the wrong interface. Check the panel's configured address and which interface is active.
- The screen draws, buttons ignored. Permission level, or a session opened before the change. Check the account is at Full Control, then open a fresh session.
- The connection drops when the laptop moves. A broken plug latch. Replace the cable and watch the link LED.
- Project transfer works, browser fails. A different endpoint and protocol. Check the remote access endpoint, not the transfer path.
- A PLC fault code appears on the panel. The panel-to-PLC link. Take it to the error-code reference and fix it separately.
Which IP address do you type in the browser?
The panel's own configured address, every time; the desktop's address and the laptop's address both identify computers, and typing either one sends the browser looking at a machine that is not the panel.
Read the address from the panel's network setup screen and write down the subnet mask with it. A laptop with a wire and a wireless card carries two addresses on two networks, and the desktop on the house router carries a third. In the case this article comes from, both computer addresses were tried and both were wrong for the same reason: an address names one network connection on one machine, and the connection you want is the panel's. For the deeper endpoint and configuration checks, including what to verify in the panel's remote access settings, see missing remote access on an HMI web page.
How do you test with one network interface?
Disable the wireless card and run the whole first test on the wire to the switch, because a PC with two active interfaces sends each request out the interface its routing table picks, which can be the wireless link to the house router while the panel sits on the switch.
Turn the wireless card off in the network settings, confirm the wired address is the only one left, and try the panel's address again. One interface, one address, one result. Leave the wireless card off while you change settings and reconnect, so every fresh session follows the same wire as the test that worked.
Does a successful project transfer show the browser path works?
No: a transfer moves the project between the programming software and the panel, while remote access serves a browser session from a separate endpoint, so each has to be checked on its own.
The transfer working while the browser fails is a normal combination. In the arrangement described here, the laptop fed projects to the panel through the switch, and the panel ran the PLC over a serial cable into the controller's port 1. Two links, two protocols. A working transfer does not prove anything about the browser session, the endpoint or the permission, so stop using it as evidence. A PLC fault code belongs to the panel-to-PLC link: in the case, a PLC 704 message was cleared from the error-code reference for that controller, and the browser control still failed afterwards. Two faults, two fixes, and neither explains the other.
Why does the connection drop when the laptop moves?
A plug whose retaining tab has snapped can slide partway out of the jack, and the link goes down the moment the cable is flexed, so a moving laptop with a broken latch produces exactly this on-and-off behavior.
Replace the cable. A plug that only holds when something presses on it will cost you hours of software diagnosis for a mechanical fault. Press every plug home at the laptop, the switch and the panel, then watch the link LED for the laptop's switch port for 60 seconds while you nudge the plug. A link that blinks out on a nudge is the cable or the jack. A link that stays up but moves no traffic is a different fault, the kind that shows up as an offline link indicator with a passing port test.
What port does the firewall need, and can you test over the internet?
The port named in your remote access documentation, entered as an allow rule in the PC's firewall; the same documentation says that with a firewall or router between the PC and the panel, the public address has to be typed into the "Remote Connection" field.
Check the firewall's state before you edit any rule. In the case this comes from, the firewall was already off, so every rule change made there was wasted motion. If it is on, allow the port the documentation names for the remote access service, not a guessed number; your remote access setup documentation covers the router-in-the-path case. Check the local path first, then attempt the internet path as a separate test with its own checks. For off-site access, do not forward that port from the public internet to a machine control interface; put a VPN in the path instead, the approach in viewing a plant HMI page from home over a VPN. If the port refuses to pass, work through port forwarding failure testing step by step.
When do you restart, and what exactly?
Close the browser session and open a fresh one before you restart anything; in the field case behind this article, full access was granted in setup, the open session stayed view-only, and control appeared only after a shutdown and restart.
The report does not say which device was restarted, so spend restarts from the cheapest end. A new browser session costs seconds. A restart of the panel software applies settings the way its documentation describes. A PLC restart interrupts the machine it controls, so keep it off the list until a setting change plus a fresh session have both failed. The timeline in the case says the session that stayed view-only was already open when the permission was granted, so order matters: settings first, new session second.
Worked example: the whole fix in numbers
Take a panel at 192.168.10.31 with a 255.255.255.0 mask, a laptop wired to the switch at 192.168.10.45, and the same laptop wireless on the house router at 192.168.1.14: only the wired interface is on the panel's network.
These are example addresses; read the real ones from the panel's setup screen and the laptop's network status. A 255.255.255.0 mask keeps the first three numbers of an address and zeroes the fourth, which sorts each device onto a network:
- Wired laptop 192.168.10.45 → network 192.168.10.0
- Panel 192.168.10.31 → network 192.168.10.0
- Wireless laptop 192.168.1.14 → network 192.168.1.0
The wired card and the panel share 192.168.10.0, so a browser on the wire reaches the panel through the switch. The wireless card sits on 192.168.1.0, a different network with no route to the switch, so a browser there finds nothing. One comparison explains both symptoms in the case: the address not found on one interface, the page loading on the other.
Then run the fix in order, timing each step so you can repeat it. Wireless card off, about 10 seconds in the network settings. Cable with an intact latch seated at both ends, link LED steady through a 60-second nudge test. Browser pointed at http://192.168.10.31, and the page draws in about 5 seconds. The connecting account set to the top of the three documented levels, Full Control. Session closed, new session opened. Press a pushbutton on the page and watch the matching output on the machine change state within 1 second. When the output follows the page, control works end to end, and an internet path or a second screen can be added on top of a known-good link.
Recommendation: check control locally before you touch a router: wireless card off, the panel's own address in the browser, a cable with an intact latch, and the firewall port from your remote access documentation open on the PC. If the screen draws but the buttons do nothing, set the connecting account to Full Control, close the session and open a new one, and restart the panel software only if its documentation directs it. Keep the panel behind a VPN for off-site access.
Questions
Should the desktop's IP address be used for the test?
No. Each address identifies one network connection on one machine: the desktop's wired address, the laptop's wired address and the laptop's wireless address are three different endpoints. The browser destination is the panel's configured address, which you read from the panel's own network setup screen. Typing a computer's address asks that computer for a page, so the browser never reaches the panel.
Does a view-only screen mean the panel or the PLC is faulty?
No. View-only is a permission level, not a failure. The remote HMI documentation defines three levels per user account: View mode, View and Screen Control, and Full Control. If you can see the screen, the network path works; check that the account you connect with is at full control, then open a new session. Save hardware diagnosis for faults that survive that.
Which device should be restarted when control stays missing?
Start with the cheapest step: close the browser session and open a new one. Then restart the panel software if its documentation tells you to apply settings that way. In the reported case, a shutdown and restart restored control, and the report does not say which device was restarted, so do not cycle the PLC first; restarting a running machine's controller interrupts production for a setting that a new session may fix.
What should be written down before asking for help?
The panel's IP address and subnet mask, the address of the one interface you tested on, whether the wireless card was off, the port your remote access documentation names, what the switch link LEDs did when you nudged the plug, and the exact permission level of the account. Those six facts answer most of the questions support will ask first.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.