A stretched remote view of the operator panel answers what is on the screen; it is a poor way to enter commands. For commands, build a separate client that reads a reviewed set of PLC values, sends request-and-acknowledge commands, and greys its data after three missed polls. Every check lives in the PLC; the phone only asks.
You can put a PLC operator interface on a phone in two ways that hold up: open the panel's own screen through its documented remote view, or skip the panel and build a separate client that talks to the controller directly. The third way people try, writing tag values from a generic app, is where the trouble starts. The remote view answers one question well: what is the panel showing right now. It answers command entry badly, because every button on the panel screen shrinks with it. If operators need to start, select or adjust from a phone, build the separate client: a short reviewed list of read-only values, commands that work as request and acknowledge, and every check in the PLC. This article compares the three paths, works one command through its timings, and ends with the decision for each case.
The three paths
Documented remote view. Panel vendors document a way to open the panel's screen from a browser or an app; the setup is walked end to end in the manual's remote-access section. Read the manual for your exact model before relying on it, because the feature can be view-only, and where it accepts touch it still shows screens drawn for a panel. A button that sits at 12 mm on the panel glass lands at 6 mm on a phone showing that screen at half linear scale, and a fingertip pad is about 10 mm wide. Keep anything an operator must tap at 10 mm or larger on the phone. Scripting taps against the mirrored image is a shortcut with a short life: move a button or change the layout and the tap lands on the wrong control, so machine commands never go through scripted taps.
Separate client. A small app, configured or written for the site, that speaks the controller's documented protocol. It reads the values you reviewed and writes the registers you reviewed, on screens designed for a phone from the start. The cost is development time plus a second consumer of PLC connections; when the ports are gone, there is a worked answer for adding another operator interface when the PLC ports are full.
Direct tag writes from a generic app. A general read/write app aimed at an address. Nothing in that path knows the machine's mode, permissives or request sequence, so every check has to live in the PLC program, and the app hands the PLC a bare value with no context. Many controllers can refuse writes to chosen addresses while reads stay open; how that looks from the operator side is the subject of why a PLC password can block HMI writes but allow reads. Keep a generic app on read-only duty.
The three paths side by side
| Path | What you get | What to check first | Where it wins |
|---|---|---|---|
| Documented remote view | The panel's own screens on a phone, sometimes with touch | Model support in the manual, view-only or interactive, and the remote-access password | Fault-finding, remote support, walking an operator through a screen |
| Separate client | Screens designed for the phone, a reviewed value set, reviewed commands | The controller's protocol document, a free connection, PLC-side validation written for every command | Daily operation: starts, mode selects, adjustments |
| Direct tag writes from a generic app | Any address, no design | Nothing makes it safe for commands, so keep it read-only | One-off diagnostics by someone who knows the program |
Where each path wins
The remote view wins when the question is what the panel is showing. Fault-finding from the office, checking an alarm screen before walking out to the line, talking a new operator through a screen: all viewing work, and the view does them with no development at all.
The separate client wins when phone operation is part of the job. Starts, mode selects, a reject confirmation: commands an operator makes several times a shift belong on a screen designed for a thumb, with the PLC judging every request.
Direct writes win nowhere as an operator interface. As a diagnostic tool in practiced hands, read-only, they are fine.
A fourth job hides inside this question: everyone on shift should see the numbers. No phone serves that, and the next section takes it.
When a fixed board beats a phone
One person at a time reads a phone. If the requirement is that the whole crew sees line status, targets and notices, mount a screen by the line and size it to the distance. Plan 30 ft of viewing distance per inch of capital letter height, the FHWA planning figure; use 20 ft per inch where people read on the move; set line spacing at 1.7 times capital height. The rule puts 0.5 in capitals at 15 ft, and 0.75 in capitals there for fast reading.
A signage display plays content prepared for it, so it does not read PLC tags. It carries the numbers someone posts each shift, plus targets and notices, while live tag values stay on the client or the panel. We build wall displays quoted per project for this job, and the sizing rule above tells you which size to ask for. Mount it away from outlets and feed it from a 24 V DC DIN-rail supply in the control cabinet, so the run to the screen stays low voltage.
The boundary: the PLC decides, the phone asks
The phone never holds permissives, mode logic or command acceptance. The client reads status and sends requests. The PLC program checks operating mode, guards and machine state, then answers accepted or rejected with a reason. The client shows the answer and has no path around the check.
The handshake is plain. Each request carries a request code and a sequence number that increments with every new request. The PLC sees a new sequence number, judges it, writes back a verdict with the number echoed, and acts once per sequence number, so a replayed or repeated request does nothing. Status reads stay read-only, polled every 1 to 2 s, a band that suits status values and counts; a fast control loop belongs in the PLC and the drives.
Whether the panel itself documents a data path changes the plumbing, never the boundary. Some panels document reading PLC tag values from the panel's own web server; the same rule applies: reviewed reads, validated commands, checks in the PLC. And reach the controller from outside the plant only through the site's approved path; the usual pattern is a VPN router set up for remote PLC and HMI access.
Example: a start command on a 1 s poll, then the link drops
Inputs: poll interval 1 s, inside the 1 to 2 s band recommended above for status reads; acknowledge window 2 poll cycles; lost-data threshold 3 consecutive failed polls; one start request carrying sequence number 47. The poll band is a design choice for status-level data, not a published limit, and the two multipliers are the design rules from the boundary section.
The rule in words: the client believes its data only while its reads keep succeeding, and a command exists only between the write and the echoed verdict.
Command arithmetic. The operator taps start at t = 0 s and the client writes request 47. The PLC judges it against mode, guards and state, then echoes accepted with 47. The client's next read lands at t = 1 s and shows the verdict, so the elapsed time is 1 s. If that read misses the verdict, the read at t = 2 s is the last chance, because the window is 2 polls × 1 s = 2 s. With no echoed verdict by 2 s, the client shows the request as failed and the operator re-issues it as sequence number 48. At a 2 s poll the same window works out to 2 × 2 s = 4 s.
Loss arithmetic. The link drops at t = 10 s, right after a good read. Polls at 11 s, 12 s and 13 s fail, and 3 × 1 s = 3 s, so at t = 13 s the client greys every value and locks the command buttons. Everything on screen at that moment is at least 3 s old. At a 2 s poll the same rule gives 3 × 2 s = 6 s. On a reconnect at t = 20 s, a fresh read repopulates the screen and the buttons come back. The client never resends request 47, and the PLC's one-act-per-sequence-number rule covers the case where the write landed but the verdict never came back.
Result: a tap gets its verdict within 2 s or shows failed, and data goes grey with the buttons locked after 3 s of failed polls. The decision that follows: set the acknowledge window at two polls and the lost threshold at three missed polls, and treat everything on the phone past three missed polls, buttons included, as untrusted.
Checks before the phone goes live
- Bench reads: compare three client reads with the controller's online values and make them match.
- Commands both ways with the machine at rest: force the accepted branch, then the rejected branch. It is the same rule a local panel link follows: test writes before motion.
- Loss: break the client's link and watch the threshold arrive on time, values grey, buttons locked, reconnect clean, no resend. Making loss obvious is the same discipline that lets a panel tell which PLC lost communication when several controllers feed one screen.
- If any check fails, lock the command path, keep the reads, and fix it before a shift uses the phone.
Keep the machine's local panel and its stop devices independent of the phone and of the network path it uses. The client is a convenience surface for commands the PLC judges; the documented stopping means stay wired at the machine.
The decision
Choose the documented remote view when the need is seeing the panel's existing screens: fault-finding, remote support, walking someone through a screen. Confirm model support first, and set the protection the manual documents; current panel manuals give remote access its own password, separate from the programming password.
Choose the separate client when operators command the machine from a phone every shift, and build it on the boundary and timings above: reviewed read-only values, request code plus sequence number, PLC-side judgment, verdict inside two polls, data grey after three missed polls.
Refuse direct tag writes for commands, and retire any generic app already on site to read-only diagnostics.
Choose the fixed board when the job is crew-wide visibility, sized to the viewing distance.
Recommendation: Build the separate client for phone commands. Read-only status at the 1 to 2 s poll; every command a request code plus sequence number judged by the PLC; verdict inside two polls or shown failed; values grey and buttons locked after three missed polls; the network path behind the site's approved remote access and the local stop devices untouched. Use the documented remote view for look-only work, and leave generic tag-write apps reading.
Questions
The panel manual documents no remote view. Can I still run a phone interface?
Yes, through the separate client path. The client talks to the controller with the controller's own documented protocol, so the panel's features do not matter. Record the controller model and the protocol document that covers it, confirm a free connection on the controller, and build the client against that. Avoid mirroring the panel screen with generic screen-sharing kit; the result is an undocumented path with no access control and no support.
Can the phone be the only way to stop the machine?
No. Treat the phone as a convenience surface and keep the machine's local stopping means fully independent of it and of its network path. In practice that means the stop devices and the local panel stay wired at the machine through their own cable runs, and nothing in the client's PLC writes touches the stop circuit. If a site wants phone-only operation anyway, that is a machine safety question, and the answer belongs to the machine's safety assessment.
How do I keep unauthorized phones off the PLC?
Put the client behind the site's approved remote-access path, allow only the devices that need it, and use the passwords the documentation provides. Current panel documentation lets you define two passwords for remote access; set them and never reuse the programming password. On the PLC side, keep write access limited to the command registers the client uses, and leave everything else closed to writes.
What stops two operators from issuing the same command at once?
Each request carries its own sequence number, and the PLC acts once per number. Two requests get two verdicts, each echoed with its own number, so the second start arrives as a new request the PLC judges on its own permissives. If the machine must never start twice, the permissive for that lives in the PLC logic, never in the phone.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.