Remote HMI wireless access: choose the client first

8 min read · Published November 8, 2026

Choose the carried remote HMI by its documented controller support before buying hardware: if the client's supported-models list names your controller, buy hardware that runs it. Then walk every work point and measure the wireless cell; a documented plant that wanted 150 m of reach measured a good connection at 15 m, so outer buildings get their own access point.

A carried remote HMI is two purchases in one: a client that can speak to your controller, and a wireless path that survives your walls. Buy the first wrong and no amount of radio fixes it; buy the second wrong and a supported client sits idle. So the order is fixed. Find your controller on the client maker's documented supported list before you price any handheld. Then measure the wireless signal at every spot the operator will stand. One documented plant that wanted 150 m of reach measured a good connection at no more than 15 m indoors, walls in the path. The usual case behind this question: the panel lives in a third-floor control room, operators work outer buildings, and those buildings need their own access point, not a louder router in the control room.

Start from the client's controller list

The handheld, rugged tablet or panel PC you carry is hardware until client software runs on it, and the client speaks one driver per controller family. So the maker's supported-models or drivers page is the first document you open. One HMI maker publishes, for its Windows remote client, a supported-models page naming the exact panel series the client can run. Another maker documents more than 40 controller drivers, including EtherNet/IP, EtherCAT, PROFINET and Modbus. If your controller appears on neither style of list, the project is not a handheld purchase; it is a new operator interface build.

Check the model and the protocol, because both decide the driver. The habit is the same one that saves time on serial links: check the panel driver list before tuning serial settings applies it step by step.

Then decide, in writing, what the carried screen may do: watch values only, acknowledge alarms, or change setpoints. The answer sets your access rules and your commissioning tests.

Three ways to carry the screen

Most plants land on one of three:

  • The panel maker's remote client on a rugged handheld. Works when your panel series is named on the supported-models page. The client runs the existing panel project, so nothing new gets drawn.
  • A browser against the panel's documented web page. Some panels expose one, and the manual says which functions it offers, usually status and alarm view.
  • A second HMI programmed against the same controller, on a mobile cart. The full-function route when no client supports your controller, at the cost of building and maintaining a second project.

Skipping the list is the failure mode: a SCADA package cannot add a driver the maker never wrote.

Options for a carried operator station

Option Choose it when What the operator gets Confirm before buying
Panel maker's remote client on a rugged handheld Your panel series is on the supported-models page The existing panel project: values, alarms, permitted writes Supported series, client operating system, license per device
Tablet browser on the panel's documented web page The panel manual documents a web interface for your model Status and alarm view in a browser Which functions the web page exposes, and whether it can write
Second HMI on a mobile cart No client lists your controller A full operator station you design A documented driver for your controller in the new HMI's driver list
Fixed status board on the wall The job is read-only awareness for the whole floor One screen everyone sees, no radio needed That it is not an HMI and takes no controller writes

Survey the wireless path at every work point

A datasheet range is an open-field number. Indoors, walls, racking and running machines set the real range, and building materials absorb the radio bands handhelds use, so the handheld's own radio, not the access point, sets the uplink. So measure instead of estimating. Walk the route with the actual handheld, doors shut, machines running, and record the signal at every point where the operator will issue a command. If you want a number you can defend instead of bars on a screen, a survey instrument gives you one; selecting SDR hardware for an RF coverage survey covers what that hardware must do across a span wide enough for the bands handhelds use.

Then apply one rule: a work point outside the measured cell of the nearest access point gets an access point of its own. Coverage is bought per cell, not per building. Scale check: an 86,000 sq ft warehouse, about 8,000 m² (86,000 ÷ 10.76), wood construction, 14 ft and 20 ft ceilings, split into two halves, is a multi-access-point job at any realistic indoor cell size. And where a building is out of radio reach altogether, wire it; connecting a remote HMI screen 1,500 feet from the PLC covers the long-run options.

Worked example: reaching a building 150 m from the control room

Inputs. Required reach: 150 m, the stated want in a documented industrial installation. Measured reliable indoor cell: 15 m (50 ft), the good-connection radius measured in that same installation, walls in the path. Layout: the fixed panel and the router sit in a third-floor control room, operators work outer buildings.

Rule in words. One access point serves a cell about as deep as its measured range. Every work point must sit inside one cell of its own access point, and every cell chained into a path is one more link that can drop.

Arithmetic. The control-room access point falls 150 m - 15 m = 135 m short of the far building. Covering the gap by chaining cells would take 150 m ÷ 15 m = 10 radio hops between the third floor and the far work point, any one of which can interrupt the screen.

Result and decision. Do not buy a louder router for the control room. Put an access point in each outer building and wire the access points back to the plant network; the control-room access point keeps serving its own floor. The threshold: a work point more than 15 m from the nearest access point, in this measured case, needs another access point. Your walk-test sets your own cell size, and the per-building decision stands either way.

Keep the plant network in its own lane

Put the handheld traffic on the plant network with authentication, and keep guest access off it. Hand the addressing and the access point plan to whoever owns the network, in writing, before any hardware is bought. If operators will change setpoints from the carried screen, decide who is allowed: HMI screen access control for a protected operator view covers splitting view rights from change rights. Keep the two jobs apart, too. Access from inside the plant over Wi-Fi is one project; access from outside over the internet is another with its own test order, and HMI remote access port forwarding fails: test each step walks that one.

Commissioning checks before the first shift

Commissioning is a walk, not a bench test. At each work point:

  1. Confirm live values on the handheld match the fixed panel.
  2. Force an alarm and watch it arrive.
  3. Issue one approved write under a safe condition and watch the machine respond.
  4. Drop the link, access point off for ten seconds, and watch the client announce the dropout, reconnect, and issue nothing stale.

A connected icon tells you the network path is up. Screen values come from the client's protocol conversation, a separate layer; the same split trips people who see an HMI ping its controller and still fail to read tags, which HMI pings the PLC but reads fail: check the protocol driver works through.

One safety rule belongs here: while the handheld is in use, the fixed panel and the local stops stay authoritative. A carried client is a second station, never the machine's only off switch.

When a carried screen is the wrong purchase

Skip the handheld when the controller is on no supported list and there is no budget for a second operator station; a SCADA package cannot add a driver the maker never wrote. Skip it when the carry-around job is programming rather than operating; that tool is a laptop, and what laptop specs do you need for PLC programming sizes one.

And when the floor's real request is to see line status from anywhere in the building, the honest answer is a fixed status board, not a radio project. That is a screen we build: our shop-floor signage is an Android all-in-one that plays images and video from microSD or USB with no subscription, with an operating range of -10 to 60 °C and a 12 to 36 V DC supply, so a notice or status board mounts beside the line with no server and no internet connection. It is not an HMI and takes no video input; it shows what your own app or media files put on it. Our shop-floor signage category lists the range.

What to ask for

Put these on the quote request:

  • The client's supported-models page or the documented driver name for your exact controller.
  • The client's operating system and minimum hardware, and the license terms per device.
  • The panel manual's web-interface section, if the browser route is live.
  • An access point plan per building, with the measured signal at each named work point.
  • The network owner's written approval of addressing and access rules.
  • The list of operator functions moving to the handheld: view, alarms, writes.

The decision

Recommendation: Before any handheld is priced, open the client maker's supported-models list and find your controller on it. If your panel series is named, buy the handheld that runs that client, and plan one access point per building, wired back to the plant network; the worked example above shows why the cell math never closes a multi-building gap from one router. If the controller is on no list, buy a second small HMI with a documented driver instead of a handheld and a SCADA package. If the floor only needs read-only awareness, put a fixed status board on the wall and skip the wireless project.

Questions

Does the fixed panel in the control room go away?

No. The carried client is a second station looking at the same project, and the fixed panel stays authoritative. If the wireless link drops mid-shift, the operator walks to the panel and keeps the line running. Run both side by side for a few shifts and record which functions moved to the handheld before anyone relies on the radio path alone.

Can a stronger router in the control room reach the outer building?

More transmitter power improves the downlink only. The handheld's own radio is the weaker half of the link, so a louder access point lets the handheld hear the network while the network still cannot hear the handheld at 150 m. Coverage is bought with access point placement: one per building, wired back to the plant network.

My controller is on no supported-models list. What now?

Treat the handheld purchase as on hold until a client documents it. Ask the controller maker which clients they have tested, and check whether the panel itself documents a web page for status. Otherwise commission a second operator station on a platform whose driver list names your controller, and keep the fixed panel running the line while it is built.

Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.

Keep reading

Build your signAsk for a quote