The panel's web page and its button control are two different services. Any browser shows the screen; button control runs through the vendor's Windows client, the maker's iPhone and iPad app, or Remote Desktop into a Windows PC that already has the client. Test viewing and control separately, and count the control routes each device can actually run.
You open the panel's address in a browser and the machine's screen appears on your desk. Then nothing presses. That is the expected result, not a fault: the page and the buttons are two different services living behind one address. The panel's web server shows its screen to any browser. Button control travels a separate path, through the vendor's remote access client, a Windows executable, or the maker's app on an iPhone or iPad, or a Remote Desktop session into a Windows PC that already runs the client. Split the two paths, test each on its own, and you can say exactly which devices in the building can look and which can touch.
The web page and the control session are two services
Behind the panel's address sit two programs. The web server answers a browser: it serves a page showing what the panel screen shows, a screen shot you can read. The remote access feature carries the interaction: a client connects, mirrors the panel screen, and passes your clicks and entries to the panel. The web server renders in any browser, so the browser make is irrelevant to it. The remote access client is a Windows executable, so it runs where Windows runs. The maker also documented an app for iPhone and iPad, and a third route: Remote Desktop into a Windows PC that is already controlling the panel through remote access.
A page that loads answers one question: this device reached the panel and can read its screen. Pressing buttons belongs to the client, and the browser never launches the client. So the browser test measures the network path and the device running it. If the page loads and the control part is missing, that exact symptom has a walkthrough of its own: when an HMI web page loads but remote access is missing.
What the browser view gives you
The view earns its place. From any device with a browser you can read the current screen, check a value from the office, or show a colleague exactly what the operator sees. Test it from the device you plan to use, because each device earns its own pass.
Type the panel address into the browser. With no port in the address, the browser asks on TCP port 80, HTTP's registered default. If the panel's web server listens on another port, the address carries it, the way http://192.168.1.50:8080 does; the panel's own configuration names the port it uses. A page that renders the panel screen clears the network path, the web server and its project setting in one stroke.
A blank or refused page has a short check order: the address, then the port, then the web server setting on the panel project. One documented trap sits in the middle: a page published on HTTP, opened in a browser or policy that insists on HTTPS, which leaves the page blank; there is a documented fix for an HTTP HMI page that stays blank in an HTTPS browser. From outside the plant, the viewing path crosses firewalls first, and viewing a plant HMI web page from home over VPN walks that route.
What actually runs the buttons
Control arrives through one of three documented routes, and each route needs a specific kind of device:
| Route | What the device needs | What you get |
|---|---|---|
| Vendor client for Windows | A Windows PC that runs the executable; one vendor lists 50 MB of free disk, 1 GB of RAM with 2 GB recommended, and a LAN port or WLAN unit | Clicks and entries reach the panel |
| Maker's mobile app | An iPhone or iPad; the documented setup for this kind of panel lists no Android app | The same interactive session from the phone |
| Remote Desktop hop | Any device with an RDP client, a Windows PC that already controls the panel, and TCP port 3389 open on that PC, Windows' documented default listening port | Control borrowed from that PC's session |
The executable is the gate. An Android tablet runs a browser but no Windows program, so the tablet holds the view and never the client. Swapping browsers is the common wrong fix: it can tidy a rendering problem, and no browser turns a non-Windows device into one that runs the client. The Remote Desktop route inherits the PC's access, so a PC without control lends the same absence. The client decides what works, so choose the remote access client first and fit the network around it.
Test the two paths in order
- View, from the device you plan to use. Open the panel address in its browser and confirm the screen image renders. Record which devices passed.
- Control, from a Windows PC. Start the vendor's remote access client, point it at the panel, and wait for the interactive session: the panel screen appears in the client window and follows the mouse.
- Try the buttons on something safe. Pick a control that cannot start or stop anything: acknowledge a message, open an empty screen, toggle an indicator lamp. Watch the physical panel react. Anything that moves a machine waits for normal site authorization and a person standing at the equipment.
- Add the mobile route. An iPhone or iPad through the maker's app. An Android tablet through the Remote Desktop hop: first the PC alone controls the panel, then the tablet's RDP session drives that PC.
- Write the matrix down. Which devices view and which control, handed to the next shift, so nobody re-derives it at 2 a.m.
The order matters because each test uses the one before it: a browser with no page points at the address, the port or the web server setting, and the control checks begin only after a page renders. If the route crosses the plant firewall, port forwarding has its own test order.
Example: an Android tablet that has to view and press buttons
Inputs. Panel in this example at 192.168.1.50, web server answering on TCP port 80; the address is an illustrative one, and 80 is HTTP's registered default. Documented control routes for the panel: 3, the Windows executable client, the maker's iPhone and iPad app, and the Remote Desktop hop. Device under test: an Android tablet with a browser and an RDP client; it runs no Windows programs, and the documented setup lists no Android app. Bench PC: a Windows machine with the vendor client installed and TCP port 3389 open, Windows' documented Remote Desktop default; the vendor lists the client's needs as 50 MB of disk and 1 GB of RAM, which the bench PC clears.
Rule in words. A device views when a browser reaches the panel. A device controls only through a route it can run. Count the routes the device can run; a count of 0 leaves it a viewer, and no browser choice moves that count.
Arithmetic. Viewing: 1 test. The tablet's browser opens http://192.168.1.50, asks on TCP port 80, and the panel screen renders, so the view passes, 1 of 1.
Control: 3 routes, removed one at a time for this tablet. The executable needs Windows; the tablet is Android, so 3 - 1 = 2 routes left and the tablet still has 0. The app needs an iPhone or iPad; the tablet is neither, so 2 - 1 = 1 route left. The hop needs an RDP client and a controlling PC; the tablet has the client and the bench PC holds the client session, so 1 route remains. Runnable routes on the tablet: 0 + 0 + 1 = 1. Hops in that route: 2.
Test the chain from the far end. The PC alone controls the panel, which clears hop 2; then the tablet's RDP session drives the PC, which clears hop 1. If the PC alone fails, both hops fail with it, so one fix covers the chain.
Result. The tablet views directly and presses buttons through 1 of the 3 documented routes, over 2 hops, while the bench PC stays up.
Decision. The threshold is 1 runnable route. At 1, button control exists but depends on the bench PC, so treat the PC as infrastructure: vendor client installed, TCP port 3389 open, powered and on the network. At 0, the device stays a viewer, and the real options are a Windows PC on the network or the maker's app on a phone it supports.
The decision, case by case
- You only need to look: any browser on any device that rendered the page. The view test is the whole job.
- Buttons from a desk: a Windows PC running the vendor's client. The hardware bar is low; the operating system is the requirement.
- Buttons from an iPhone or iPad: the maker's app, matched to your panel and software version.
- Buttons from Android or anything else: the Remote Desktop hop into the Windows PC that already controls the panel.
- Buttons inside the browser page: nothing to build. The page never carries the control path; it is a separate program.
Recommendation: run the view test and the control test as two separate checks, and record which devices passed each. Budget one Windows PC with the vendor's client for each set of panels someone must control remotely; give every phone and tablet the browser for viewing and the Remote Desktop hop into that PC for buttons. Promise button control only where the device can run the client, the maker's app, or an RDP session into that PC; every other device gets the view.
Questions
Can a phone or tablet press HMI buttons through the web page?
No. The control path is a program, and no browser on a phone runs it. In the documented setup for this kind of panel, the control client was a Windows executable, the maker's app covered iPhone and iPad, and no Android app existed. An Android device presses buttons only through a Remote Desktop session into a Windows PC that already controls the panel. Ask the maker what ships for your panel and software version today; the app list moves with their software.
Which network ports does the two-path test need?
The browser view uses HTTP's default, TCP port 80, unless the panel's configuration moved it; when the port moves, the panel address is written with a colon and the port number after it, as with port 8080. The Remote Desktop route opens TCP port 3389 on the Windows PC, the documented Windows default. The vendor client's own connection to the panel uses whatever its documentation names. If either path crosses a firewall, open and test each port on its own.
Does the control PC need to be powerful?
No. One vendor's documented operating environment for its Windows remote HMI client asks for at least 50 MB of free hard disk, 1 GB of RAM with 2 GB recommended, and a LAN port or WLAN unit. The gate is the operating system, because the client is a Windows executable; the hardware list is small. An ordinary office PC that runs Windows clears it many times over.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.