When an HMI panel goes unresponsive during its own FTP transfer, suspend the scheduled sends first so operators can rely on the panel again. Then test FTP and remote access one at a time and move log delivery to one batched send per day outside production hours.
An HMI panel that goes almost dead each time its FTP client sends log files is a load and scheduling problem before it is a hardware fault. The setup this article fixes: a small panel pushes its logs to an office FTP server every 10 minutes, remote web access is switched on, the panel reaches the network over Ethernet and the PLC over a serial link on port 2. During each send, the touch screen and the web access stop responding together, and a firmware update changes nothing. Work in this order: suspend the transfers so operators can rely on the panel again, test FTP and remote access one at a time, then move log delivery off shift or trim what the panel logs.
Why does an HMI panel go unresponsive during an FTP transfer?
The FTP send, the touch screen, the PLC polling and the web access all run on the panel's one processor. A small panel lets the transfer take enough of that processor to starve the operator interface for the whole length of the file send.
The four activities compete for the same panel-side resource. Vendor guidance published for slow HMI runtime performance blames application workload, with logged data sets as the named contributor, and that is the same workload an FTP send adds. The send and the web access run over the panel's Ethernet side, while the PLC link runs on serial port 2, so the serial settings and the PLC cable keep doing their job while the send runs. The recovery pattern gives the cause away: the panel comes back the moment the file finishes, and a failed component stays failed.
Can operators rely on the panel while a transfer is running?
Treat each transfer as a window in which the panel is unavailable: the touch screen and remote access stopped together for the length of the send in this setup, so a start or stop command pressed during a transfer may never register.
Suspend the scheduled sends before the next shift leans on the panel. If operators use this panel to turn equipment on or off, make the change through the site's approved procedure, keep the machine in its defined safe operating state, and tell them that log delivery is paused. Suspending the FTP job stops log delivery for now; it is the first step, not the repair. Remote web access is no fallback during a send either: it stopped together with the touch screen. Treat web access as available only after the FTP-alone test shows it answering while a send runs.
Which symptom points to which cause?
Read the combination of what still works while the panel slows: touch response, remote web access and fresh PLC values separate an FTP load problem from a PLC link problem or a panel fault in a single observation.
| What you see | What it points to | Check next |
|---|---|---|
| Touch and web access dead during a send, both recover when it ends | FTP load on the panel processor | Suspend FTP and check that response returns |
| Panel still slow with FTP suspended | Application workload or the PLC link | Trim logged data sets toward 10 or fewer and watch a PLC value change |
| Touch works, PLC values frozen | The PLC path on serial port 2 | Run the panel's communication diagnostics; telling which PLC lost communication on a multi-PLC HMI panel walks that fault |
| Local touch fine, remote access slow | The remote access path under load | Test web access with FTP suspended, then active |
| Panel stays unresponsive after the send ends | A different fault, power or network | Start with power; an HMI screen that goes blank and freezes gives that order |
The mirror fault, a web server that stops answering while FTP keeps working, has its own diagnosis in an HMI panel web server that stops responding but FTP still works.
How do you pause the FTP transfers before relying on the panel?
Suspend the scheduled FTP job in the panel's own configuration and check that the panel answers for a full 10-minute gap, the interval it used to send in. If touch response returns with the FTP job suspended, the send was the load and everything after this is scheduling.
- Write the current setup down before touching anything: panel model, application revision, firmware revision, FTP server address, log volume per send, the send interval, and whether web access was open during past slowdowns.
- Suspend the scheduled FTP job in the panel's FTP client settings. Leave the PLC serial settings on port 2 and the network addressing exactly as they are.
- Have an operator press the controls that matter and watch a PLC value change on screen.
- Open remote web access and check that it answers.
- Leave FTP suspended for one full old interval, 10 minutes in this setup, and check that no slowdown appears.
If touch, PLC values and web access all answer across that gap, the send was the load and the remaining work is scheduling. If the panel still slows with FTP suspended, work the second row of the table above before changing anything else.
How do you test one communication load at a time?
Change one thing per test: FTP alone with web access closed, web access alone with FTP suspended, then the combination. Write down the start time and dead window of every send, and repeat any condition that failed before you trust the result.
- Baseline: FTP suspended, web access closed. Note touch response, PLC value freshness and web access response.
- Start one FTP send with web access closed. Write down the start time, the moment the panel stops answering, the moment it comes back, and whether the file completes.
- Suspend FTP again and open web access alone. Note its response.
- Run the combined condition, FTP plus web access on the current 10-minute schedule, only after both single loads passed.
- Repeat any condition that failed at least once before you act on the result.
Freeze the serial settings, the network addressing and the schedule across all five steps; a test that changes three things at once hides the one that mattered.
What does an FTP send every 10 minutes take from the panel in an example day?
Multiply the interval into the day and the measured dead window into the sends: a send every 10 minutes is 144 sends per day, so a 20-second dead window per send takes 48 minutes of daily availability from the panel, scattered in windows an operator can hit at any press.
Worked example. The interval gives the send count: 1,440 minutes in a day divided by a 10-minute interval is 144 sends per day. The dead window is yours to measure, and this example uses 20 seconds as the stopwatch reading to replace, because the real window grows with log volume and with network distance. Daily unavailable time: 144 sends x 20 s = 2,880 s, and 2,880 s / 60 = 48 minutes. Trustworthy panel time: 1,440 - 48 = 1,392 minutes per day, split into 144 separate blackouts an operator can meet at any press.
Move the send to 03:00 by setting the interval to 1,440 minutes. One send per day uses 20 s, outside the shift. If a full day of logs is 24 times a 10-minute batch and the window scales with volume, that single send lasts 24 x 20 s = 480 s, which is 8 minutes, still at 03:00. That is the trade: one long window when nobody needs the panel, in place of 144 windows scattered through production.
Log volume moves the window length, the interval moves the window count, and network speed moves both, so re-measure after any change to the three.
Which schedule and log changes fix it without new hardware?
Move the send off shift and make each send smaller: set the FTP interval to one batched send per day outside production hours and cut the logged data sets toward the 10-or-fewer figure the panel vendor's own slow-performance guidance gives.
Off-shift batching. The interval and the start time live in the panel's FTP client settings. Setting the interval from 10 minutes to 1,440 minutes puts one send at a chosen hour such as 03:00, and the server receives one large file per day instead of 144 small ones.
Smaller sends. Vendor guidance published for slow HMI runtime performance puts logged data sets at 10 or fewer; fewer logged points and shorter on-panel retention both cut the bytes in each send, and the send window shrinks with them.
Collector pull. If the panel also runs an FTP server, point an office collector at the panel and let the collector pull the files on its own schedule. The panel then runs no scheduled send of its own; the pull still loads the panel's network side, so the one-load test and the stopwatch apply here too.
The rule from the example holds at any interval: dead window x sends per day is the panel's unavailable time, and a schedule that multiplies out inside production hours moves off shift.
Recommendation: suspend the FTP client before the next shift relies on the panel, then move log delivery to one batched send per day at 03:00 with the interval set to 1,440 minutes and the logged data sets trimmed toward the vendor's figure; re-test FTP alone and web access alone before either runs during production again.
Does a firmware update fix it, or is the panel too small?
The panel in this setup already ran current firmware and the slowdown survived the update, so re-flash only when the release notes for the model name FTP, memory or response behavior. If trimmed, off-shift logging still slows the panel, the choice is a panel with more processing headroom.
An update with no relevant line in its release history is a change with no direction. Before specifying a replacement, run the candidate's runtime under the same load; choosing an HMI panel by testing startup and runtime first sets that test out.
The decision in each case: the panel recovers when each send ends, the trim and the off-shift schedule remove the slowdowns, keep the current panel. The panel still slows with trimmed logs and one off-shift send, the load is beyond this hardware, and a separate collector device that owns the FTP job is the next spend.
Questions
How often can a small HMI panel send log files over FTP?
No published limit exists for this class of panel; the tolerable interval is whatever your stopwatch test measures. The setup this article describes went unresponsive at a send every 10 minutes, with the touch screen and web access both dead during each send. Start a new schedule at one send per day off shift and shorten it only while the measured dead window stays clear of the moments operators press the panel.
What do FTP reply codes tell you when a log send fails?
FTP servers answer with three-digit reply codes, and a failed send shows one in the client's error output. Codes beginning with 4 report a temporary condition, so the same send can succeed on a retry, while codes beginning with 5 report a permanent fault such as a wrong account or a missing folder on the server. The panel's own FTP documentation lists the codes that model prints.
Does this kind of slowdown damage the panel?
The behavior described is a resource shortage while the send runs, and the panel comes back when the send ends. Damage shows up differently: a panel that stays unresponsive after the send ends, one that loses its configuration, or one that runs hot. Those faults get their own checks, starting with power and then the firmware revision, before any FTP change.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.