C-more Panel Freeze: Why Does Screen Change Lock Up?

On the EA7-T15C, one reproducible C-more failure left a white screen and continuous beeping after an operator closed a trend-point value popup and used an event-driven screen change; a separate Alarm History/Alarm Count failure also locked the interface.

Stop repeating button presses once the panel beeps without acting

When the Alarm History window stops responding, repeated taps on Alarm Count or the other window buttons do not restore navigation. In the reported failure, the Alarm Count button left the display on Alarm History, other buttons sometimes worked and sometimes did not, and button presses produced beeps without changing the screen. In some cases the display became blank white and the beeping continued.

Stop the test as soon as the panel no longer responds consistently. Record which button was pressed, whether the Alarm Count window appeared, whether other buttons still worked, and whether the white screen or continuous beep occurred. A beep alone does not confirm that the requested screen action completed. Repeating the same sequence can obscure the first failing transition without providing a useful diagnostic distinction.

Do not treat the intermittent alarm-screen behavior as the same fault as the trend-graph sequence. The alarm problem was not reproducible in a new project, while the trend-graph problem was repeatable in a small test project. Keep separate notes and test cases for the two symptoms.

Keep PLC communications out of the first reproduction test

The repeatable screen-change failure occurred in a test project with no PLC protocol binding. Its three tags were internal: two discrete tags, Switch1 and Switch2, and a numeric tag, SYS_TIME_SS. That result makes PLC communications an unnecessary dependency for reproducing this particular failure. Reworking PLC addresses, protocol settings, or network wiring is not the first diagnostic step for this trigger.

Also avoid trying to command a screen by writing to SYS Current Screen Number. It was identified as a read-only system tag, not a writable screen-selection command. Use the screen-change action provided by the C-more project instead of treating a read-only status value as a control.

This does not rule PLC communication out as a cause of a different, installation-specific fault. It does establish that the event-navigation failure can be tested separately from PLC communications, which makes a smaller and more useful reproduction project.

Restore navigation with the direct Screen Change Push Button

For the trend-graph failure, the temporary workaround was to replace the affected event-driven navigation with a Screen Change Push Button. In the reported test, the panel simulation did not show the lockup when this direct screen-change button was used.

Apply that workaround only to the transition that fails: the return from the trend-graph screen after opening and closing the point-value window. This avoids rewriting unrelated Event Manager logic that may serve other functions. Confirm the change on the simulator and the EA7-T15C before relying on it in operation; the workaround was reported for the screen-change failure, not as a repair for the separate Alarm History/Alarm Count lockup.

Keep the workaround distinct from the permanent correction. The release identified for resolving both reported issues was C-more version 2.0.7.35E. Until the corrected version is verified in the project and on the panel, the direct screen-change button is a limited navigation workaround, not proof that the underlying software issue has been corrected.

Reproduce the trend-graph lockup with the two-screen test

Build or preserve a small project that follows the failing interaction. The reproduced configuration used two screens, internal tags, a one-pen Line Trend Graph, and tag events that changed screens directly. Both pushbuttons used the Momentary ON action.

1. On Screen1, place a pushbutton labeled “To Screen2” and assign it to the internal discrete tag Switch1.
2. On Screen2, place a pushbutton labeled “To Screen1” and assign it to the internal discrete tag Switch2.
3. On Screen2, place a Line Trend Graph with one pen assigned to the numeric tag SYS_TIME_SS. In the graph options, enable “Date & Time is Displayed on X-Axis.”
4. In Event Manager, create a tag event that changes directly to Screen2 when Switch1 is ON, and a second tag event that changes directly to Screen1 when Switch2 is ON.
5. Run the project, navigate to Screen2, touch the trend graph to open its point-value window, close that window, and then press “To Screen1.” Record whether the display returns normally or becomes white with continuous beeping.

Without opening the graph’s point-value window, the test project changed between screens normally. Opening and closing the point-value window before pressing the event-driven return button produced the failure. The behavior was reported in the C-more simulator as well as on the real panel, so the test does not depend on a particular PLC connection or on the physical touch panel alone.

Treat the popup-close transition as the failing boundary

The repeatable condition is the order of operations: the graph is touched, a small window displays the value at the selected point, that window is closed, and then an event triggered by Switch2 requests a direct screen change. Ordinary screen changes worked before that popup interaction. That boundary is more useful than labeling the whole project “hung” or assuming that every graph display causes the fault.

The failure is in the HMI interaction path exposed by the popup-close and event-transition sequence. The exact internal software mechanism was not described, so do not infer a tag limit, trend-pen limit, alarm load threshold, or PLC communication fault from this result. The practical engineering response is to reproduce the sequence, use the direct-button workaround if needed, and verify the stated correction version.

Separate the alarm-window lockup from trend navigation

The Alarm History/Alarm Count behavior appeared in a nearly completed project containing many tags, events, alarms, objects, and screens. The alarm-processing system had been added last, but timing alone does not show that it caused the problem. A new project’s Alarm History window worked normally, and the alarm failure could not be reproduced there. That makes the alarm defect a separate, intermittent case requiring the project that exhibits it.

Use the following distinctions when recording the alarm failure:

• Alarm Count action: did the window remain on Alarm History, or did Alarm Count appear?
• Other Alarm History buttons: did each press perform its normal function, fail intermittently, or only beep?
• Display state: did the panel remain on the alarm screen, show a blank white screen, or recover?
• Occurrence context: record the screen and action sequence immediately before the first unresponsive button press.

Do not use successful alarm operation in a new project to clear the production project. It only shows that the simple test did not reproduce the same failure. Conversely, do not treat the reproducible trend-graph test as an explanation for the alarm-screen behavior. Both issues were later reported resolved in the identified C-more version, but the alarm fault still needs its own reproduction record when diagnosing a project that remains affected.

Test the return transition in a controlled sequence

Use a saved test copy and change one factor at a time. First establish a baseline, then test the exact popup-close sequence, then compare it with the direct screen-change workaround. This separates a general navigation error from the reported interaction-specific lockup.

1. Run the two-screen project and verify that each momentary pushbutton changes to its assigned screen through the corresponding tag event.
2. Repeat the screen changes without touching the trend graph. Record that baseline before changing the project.
3. Navigate to Screen2, open the trend-point value window, close it, and press the event-driven “To Screen1” button once. Record the display and audible response.
4. In a separate saved copy, replace only that return transition with a Screen Change Push Button. Repeat the same sequence and compare the results.
5. Run the successful path on the target panel as well as in the simulator. Keep the version, project copy, and exact sequence with the test result.

If the event method fails only after the point-value window is closed while the direct-button method works, retain the direct button as the temporary restore and report the minimal project. If both methods fail, or the baseline screen changes also fail, broaden the diagnosis beyond this specific reproduced condition instead of assuming the reported software defect is the only cause.

Isolate Alarm History without damaging the completed project

For the intermittent alarm failure, preserve an untouched copy of the completed project before testing. The reported project was difficult to reduce because it contained many application elements, and the first failure was not repeatable in the simple project. A controlled copy-and-test process protects the working application while narrowing down what has to remain for the fault to recur.

1. Record the project identity and the installed C-more software/firmware version before editing. Keep the original project unchanged.
2. In a duplicate, test the Alarm History and Alarm Count controls as separate actions. Capture whether the Alarm Count view opens and whether the other controls respond.
3. When the failure appears, stop and record the first nonresponsive action and the resulting display. Do not continue tapping through the window.
4. If testing a reduced project, remove or simplify one group of project elements at a time in separate copies. Retest the same alarm-button sequence after each change.
5. Keep the smallest project that still reproduces the failure, along with the steps and observed results. If reduction removes the failure, retain the full affected project for support review.

The alarm subsystem was added late in the project, making it a reasonable area to inspect, not a proven cause. Avoid deleting alarm objects from the only project copy or making several unrelated edits between tests; either action makes it harder to identify a reproducible condition.

Verify C-more version 2.0.7.35E on the simulator and panel

The C-more issue was reported resolved with version 2.0.7.35E of the software/firmware. This is the specific correction version named for the two failures. Record the version actually used for project development and the version running on the panel; do not rely on a project filename or memory of a prior update as proof that the correction is present.

After applying an approved correction, repeat both tests independently:

• For the trend-graph case, navigate to Screen2, open and close the point-value window, then trigger the event-driven return transition.
• For the alarm case, test Alarm History and Alarm Count repeatedly in the project that previously showed the fault, using the recorded action sequence.

Confirm that the alarm-count view appears when requested, that the other alarm controls remain responsive, and that neither test leaves a blank screen with continuous beeping. Repeat the trend sequence in the simulator and on the EA7-T15C. If either fault persists, preserve the tested version and project copy so support can distinguish an uncorrected installation from a different failure.

Send the alarm project to AutomationDirect when it stays intermittent

Stop making speculative edits when the alarm failure still occurs only in the completed project, or when the exact popup-close sequence still locks the panel after the reported correction version is verified. Prepare the project file, C-more version, panel model, and concise reproduction steps for AutomationDirect technical support. The alarm report should include the behavior of Alarm Count and the other buttons; the trend report should preserve the two-screen sequence and whether the simulator reproduces it.

Frequently asked questions