When the same remote HMI app stalls on one phone and runs on the tablet next to it, stop reinstalling. Compare the saved target address, the network path and the OS build against the working device, one variable at a time, then spend exactly one reinstall under matched conditions. Thirty minutes of controlled testing produces a decision either way, and the record decides what support receives.
When the same remote HMI app stalls on one phone and runs on the tablet beside it, the usual response, removing and reinstalling the app again and again, buys nothing. The difference between the working device and the stalled ones sits in three places: the target address saved in the app, the network path to the panel, and the OS build. Compare those one variable at a time against the device that works, then spend exactly one reinstall under matched conditions. Half an hour of controlled testing produces a decision either way; a tenth reinstall produces a result nobody can read.
What each symptom points to
Write down where the failure happens before touching a setting. A stall at launch and a missing video picture look alike from across the shop floor and have different causes.
| Symptom | What it points to | First check |
|---|---|---|
| App freezes before the running screen appears | App state or a device-side stall | One controlled reinstall, after the settings are recorded |
| Running screen appears, values update slowly or freeze | The connection and update path to the panel | Compare the saved target address and the network path against the working device |
| Running screen appears but the video picture is missing | Startup works; the target address or the video feed is at fault | Re-read the saved address against the working device's, then confirm video still shows there |
| Two identical phones fail alike while a tablet works | A condition the failing pair shares: the same saved settings, the same OS build, the same network | Work through the three variables in the next section |
| Every device fails against the same target | A panel-side or network-side cause | Compare the panel's firmware version with the minimum the app's store page states |
A picture that shows on one device and not another is its own fault class. Fix a video that plays over USB but not in the player app works the same split for a signage player.
Change one variable at a time
Three variables separate a working device from a stalled one. Change one, re-test, write the result down, and only then touch the next.
- The saved target address. Open the connection settings on the working device and on the stalled one and compare the address character for character. One wrong digit points the app at a different device or at nothing. Record the working address before you change anything, so a typo during re-entry cannot add a second fault to the first.
- The network path. A phone on cellular and a tablet on the site's Wi-Fi are not running the same test. Join the stalled phone to the same network the working device uses, with the same addressing, and re-test. If the phone has never worked on any network, put that in the record; it shifts the weight toward the device.
- The OS build and app version. Write the OS build down for every device in the test. In the scenario below, the two failing phones both ran iOS 6.0.1 while another device ran the same app on 5.1.1 without trouble. Builds that far apart have both worked, so record the version and hand it to support; the upgrade step comes last, after the address and path match.
Then clear the background-load theory with one short run: notifications off, every other app closed, the HMI app against the same target for five minutes. If the stall survives while a busier device keeps working, background load is off the list. In the scenario, the working tablet carried six apps in the background through the whole test.
Why one reinstall is the whole budget
A reinstall replaces the app's binary and wipes its stored state in one move. If a corrupted install or stale saved state is the cause, the first reinstall fixes it. The second installs the same current version and starts from the same empty state, so it can only repeat the first result. Each repeat also blurs the record, because it changes the installed version, the saved address and the app state together.
That is why the budget is one reinstall, run under matched conditions, with the settings written down first. In the scenario below, the matched reinstall is the eleventh attempt on that phone, and the only one run with the address and path held at the working device's values. Ten identical attempts carry less information than one controlled run.
Scenario: two phones stall, a tablet works
The scenario's inputs: two identical phones on iOS 6.0.1 stall or update extremely slowly in the app, and both have already been through about ten reinstalls with no change; a tablet on the same site runs the app fully, video included, with six apps in the background; the panel's installed firmware is unknown; the app's store page states a minimum panel firmware of 6.31 and the project resolution set to the panel's native value.
- Record, 5 minutes. From the tablet: the saved target address, the network it uses, the app version if the app shows one. From each phone: the saved address and the OS build. Every value the test can change is now on paper.
- Match, 10 minutes. Join one phone to the tablet's network and compare its saved address with the tablet's. Correct what differs, one item, and note which item it was.
- Panel check, 5 minutes. Read the panel's installed firmware. Suppose it shows 6.50: that sits above the stated minimum of 6.31, so the panel side passes and leaves the suspect list. If it reads below 6.31, panel firmware becomes the first fix, applied through the site's own update procedure.
- One reinstall, 10 minutes. Remove the app on that one phone, install it fresh, re-enter the recorded address, and run it against the same target as the tablet, on the same network.
The arithmetic: 5 + 10 + 5 + 10 = 30 minutes, and exactly one reinstall. If the app still stalls, the record reads: fresh install, matched address, matched path, firmware above 6.31, stall at launch. That sentence is the escalation package, and more attempts on the phone add nothing new. If the app runs, the difference lived in the app's storage or the address, and the tablet's recorded settings become the site standard for the second phone.
What each result means
| Result of the matched reinstall | What it means | What to do |
|---|---|---|
| App runs to the running screen and updates | Stale app state or a mis-entered address was the cause | Copy the tablet's recorded settings to the second phone, and check video before the phone goes back in a pocket |
| Stall survives a fresh install under matched conditions | The fault sits outside the app's storage, in the device or its OS build | Stop reinstalling. Send support the model, OS build, app version, target address, network path and failure stage |
| Running screen loads but the video picture stays missing | The address or the video feed | Re-check the saved address, and confirm the working device still shows video against the same target at the same moment |
| The tablet starts failing after your changes | The cause moved with a change you made | Undo the last change and re-test to confirm which one |
| Every device fails against the same target | Panel-side or network-side | Bring the panel firmware to the minimum the app's store page states, set the project resolution to the panel's native value, then re-test every device |
A panel can serve one connection path while another stalls on the same box. The same split shows up when an HMI panel's web server stops responding but FTP still works, and that article walks through isolating which service dropped.
Two boundaries keep the job safe. The panel's project, its comms settings and its firmware belong to the running machine, so they change only under the site's own change procedure and never to fix a pocket device. And a full phone reset waits until support asks for it, with a backup taken first.
Recommendation
Recommendation: Spend exactly one reinstall, and only after the saved target address and the network path match a working device. If the stall survives that reinstall, stop and hand support the device model, OS build, app version, target address, network path and the exact stage where the app freezes. If the reinstall clears it, copy the recorded settings to every other device on site, so the next stall starts from a known state instead of a guess.
If the app keeps costing more time than it returns, weigh the app route against a separate remote client before the next shift. Mobile PLC operator interface: remote view or separate client sets out that choice.
Questions
Where do I find the versions support will ask for?
The phone's app page shows the installed app version and the system screen shows the OS build; write both down before removing anything. The panel's firmware version sits on the panel's system or about screen next to its model information. Quote the four values together with the configured target address and the network each device used, so support can match a known fault without another round of questions.
Can the panel be at fault when only one device stalls?
A panel-side cause reaches every client the same way. If a tablet runs the same app fully against the same target address while a phone stalls, the panel is serving at least one device correctly, so the fault to chase sits on the stalled phone or in its path. Two failing devices and one working one still point at the pair's shared settings, saved address, OS build or network.
Does closing background apps and turning off notifications help?
Test it once. Turn notifications off, close every other app, and run the app against the same target for five minutes. If the stall survives while a busier device keeps working, background load is off the list and the search moves to the saved address, the network path and the OS build. One five-minute test prevents an afternoon of settings churn.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.