Two EA7-T12C panels on the same three-device Ethernet network sometimes take nearly a second to react, while at other times they respond immediately. Because the delay is intermittent, troubleshoot the conditions that change during manual operation before changing network settings or rebuilding screens; the reported 7–8 ms average PLC scan time (11.5 ms maximum) does not by itself explain a near-second pause.
Record the lag before changing the installation
First establish when the delay occurs. The known case has two EA7-T12C touchscreens communicating with a 1769-L32E CompactLogix processor. Each of 16 station screens supports manual functions, with no more than 32 tags on any one manual screen. Most alarms must be cleared before manual operation, although a few may remain. Trends are not running, a small number of alarms or Event Manager actions may occur, and remote access is unavailable. The PLC scan time averages 7–8 ms and reaches 11.5 ms maximum.
Capture observations during both a normal response and a delayed response. Record the active panel and screen, the operator action, whether a momentary button failed to register, alarms or events present, and PLC scan time at that moment. Note whether the lag affects one screen, one panel, or both. This comparison is more useful than a single average because a screen-specific rendering load, a background task, or a PLC workload change can be intermittent.
Check before proceeding: You can identify at least one delayed event and one normal event with their screen, panel, and operating conditions recorded.
Rule out a network fault without assuming Ethernet is the cause
The processor Ethernet port is configured for 100 Mbps, and the reported network contains only the two panels and the processor. The port shows occasional FCS errors, but no major communications problems were observed. Those facts do not prove that Ethernet causes the lag, nor do they justify ignoring the errors: correlate them with delays and check whether the error count continues to rise during the test.
An FCS error indicates a frame integrity problem. If errors accumulate, inspect the relevant cabling, connectors, and port configuration using the equipment documentation and site procedures; correct the physical or configuration issue and retest. Do not treat a static, occasional count as a diagnosis of the nearly one-second response, and do not change link settings as a guess. If communication diagnostics show errors or interruptions at the same time as a lag, resolve that path before evaluating HMI rendering.
Check before proceeding: The connection remains stable during a repeat test, and you have established whether FCS errors increase with delayed responses. If they do, address the network fault first and repeat the test.
Compare PLC scan time during a delayed action
A touch action that changes a PLC tag depends on the panel communicating the value and the controller processing it. The reported scan times are short in absolute terms, but the useful comparison is the scan time while the delay is happening—not just the average. A controller handling additional background work can have a different scan time from its idle or typical value.
- Monitor the processor scan time while an operator performs the manual function.
- Capture the value during an immediate response and during a delayed response.
- Compare the readings and note any controller workload or program activity that coincides with the lag.
If scan time rises with the delay, investigate the controller workload and the logic associated with that operation. If scan time stays near the reported 7–8 ms average, with a maximum of 11.5 ms, shift attention to panel tasks, screen composition, and communication behavior instead of assuming the PLC scan is responsible. Do not add an arbitrary scan-time threshold; use the controller’s observed behavior and the required machine response.
Check before proceeding: You know whether delayed operator actions coincide with a scan-time change.
Test alarms, events, and other background work one at a time
Background activity can compete with operator interaction for panel processing. The likely items to examine in this installation are the few alarms that may remain during manual operation and the small number of Event Manager actions that could run. Trends are already reported as stopped, and remote access is unavailable, so do not spend time troubleshooting those inactive features unless their status changes.
- Repeat the same manual action with the normal alarm and event conditions recorded.
- Where operating procedures permit, compare a test condition with the remaining alarms or eligible events inactive against one with the normal conditions present.
- Change only one background activity at a time, then record whether response changes.
Do not suppress required alarms, events, or machine protections in production to run this test. Arrange a controlled test state through the site’s operating procedure. A repeatable improvement when a particular task is absent identifies a useful lead; it does not prove every task of that type is a cause.
Check before proceeding: You have either correlated the lag with a specific active task or ruled out the tested alarm/event conditions as a repeatable trigger.
Reduce screen work only when the lag follows a screen
Screen composition can affect response as well as communication. The identified performance factors include the number of tags on a screen and whether those tags are contiguous, animations, overlapping graphical objects, rotating objects, and transparency on overlapping objects. The manual screens in this case use at most 32 tags each, but a tag count alone does not reveal whether the screen is expensive to update or whether the lag is tied to one layout.
| Observed pattern | Areas to inspect | Useful comparison |
|---|---|---|
| Lag repeats on one station screen | Tag count and organization; animations; overlapping or rotating objects; transparency | Compare with another manual screen under similar operating conditions |
| Lag appears across different screens at the same time | PLC scan time; active alarms/events; network diagnostics | Compare panel, controller, and task observations at the same timestamp |
| Lag occurs only while a background feature is active | Alarms, Event Manager actions, trends, logging, or remote access if enabled | Repeat a controlled comparison with one activity changed |
For a screen-specific delay, make a controlled change to one suspected visual or tag-layout factor and repeat the exact action. If the screen has overlapping transparent objects, animations, or rotating objects, test a simplified version in a safe test copy before making production changes. Do not redesign all 16 screens based only on their tag counts; first find a repeatable correlation.
Check before proceeding: A controlled screen comparison shows whether the lag follows a specific screen or a tested screen feature.
Separate a missed momentary touch from a slow machine response
A momentary button that appears to miss a touch can represent different failure points: the panel may not register the touch promptly, its screen may be busy processing updates, or the requested PLC-side action may be delayed after the input is registered. Distinguish these by comparing what the operator sees with the corresponding controller-side state during a controlled test.
- Repeat the action on a lagging screen and note whether the button’s visual response occurs immediately.
- Compare that visual indication with the related PLC state or action using the project’s existing diagnostics and safe operating procedure.
- Repeat on a screen that responds normally, keeping the action and operating conditions as similar as practical.
If the panel’s visual response itself is delayed, focus on screen work and background processing. If the visual response is immediate but the PLC-side state changes late, focus on communication and controller processing. If neither observation is available in the project, do not infer which stage failed from the operator’s hold time alone; add an appropriate diagnostic or ask the project’s support resource to help instrument the test.
Check before proceeding: You can identify whether the delay appears before or after the panel gives its visual button response.
Verify the correction across all manual stations
Once a repeatable contributor has been identified, change one factor at a time and retain a baseline. A temporary production restore—such as avoiding a screen or task that reliably triggers a lag—can help operations continue only if the site’s process and safety requirements allow it. It does not replace correcting the underlying screen, task, controller, or network condition.
- Repeat the original action under the conditions that previously produced the delay.
- Test the manual function on each station screen, not just the screen used to diagnose the issue.
- Confirm momentary buttons register without an unusually long hold, and check that the PLC-side action follows as intended.
- Compare scan-time observations, alarm/event activity, and network diagnostics with the recorded baseline.
Keep the correction only if the lag no longer reproduces and normal alarms, events, communications, and machine behavior remain intact. If the delay returns, preserve the before-and-after observations rather than layering on unrelated changes.
Check before proceeding: All 16 manual station screens pass the same response test, and the original delayed condition no longer reproduces.
FAQ
Can a 7–8 ms PLC scan time still be related to a nearly one-second HMI delay?
Yes, if the scan time increases during the delayed action or the controller workload changes. Compare scan time during immediate and delayed responses; an average alone does not isolate the cause.
Does a screen with 32 tags explain intermittent C-more lag?
Not by itself. Compare the affected screen with other manual screens and inspect tag organization, animations, overlapping objects, rotating objects, and transparency.
Can occasional FCS errors cause a missed momentary button?
They are a reason to check network diagnostics, but the reported occasional errors do not by themselves establish the cause. Determine whether the error count rises during delayed actions and address any correlated communication fault.
Does AutomationDirect support need the HMI project to investigate?
Stop making broad changes if controlled tests do not isolate the lag or the project lacks diagnostics to distinguish panel response from PLC action. Contact official AutomationDirect technical support with the project and the recorded screen, scan-time, alarm/event, and network observations.