Configuring C-more HMI Buttons for PLC Heater Alarms

In the heating-system project, an EA7-T10C C-more panel controls a D0-06AR PLC application with an F0-04RTD module, and the HMI pushbutton became reliable after popups were removed in favor of static text objects. Treat the screen button as a request written to a PLC tag, not as a physical input; keep heater proof, fault latching, and reset decisions in the PLC logic.

Stop relying on the fixes that miss the control path

When a button appears not to work or a fault message disappears too soon, several quick changes can make the project harder to debug without correcting the underlying signal path.

Do not spend time renaming a tag or repeatedly changing the button graphic until you know whether the object is writing the intended PLC bit. A screen animation can look correct while its tag is unassigned, mapped to the wrong device, or configured with the wrong data type.

Separate the HMI request from the heater fault decision

For each heater, distinguish the PLC output command from the feedback signals. The project description includes a contactor auxiliary contact and a current sensor switch for each heater. Those signals provide evidence about contactor state and heater current; they are not interchangeable with the HMI command.

Define the sequence in plain terms before building the display:

• When the temperature reaches the applicable minimum setpoint, the PLC controls the contactor according to the machine’s operating logic.
• While the PLC expects the heater to be on, the PLC evaluates the relevant feedback signals.
• If expected operation is not proven, the PLC sets a fault state that remains visible after the immediate mismatch ends.
• An operator touches the HMI reset button to request acknowledgment. PLC logic decides whether that request is allowed to clear the stored fault.

A momentary loss of feedback can end when the contactor turns off or the process changes state. If the HMI displays only the live mismatch, the red message can disappear with that condition and leave no indication that a problem occurred. A retained PLC fault bit solves the memory problem. For sound operation, clear it only when the reset request is received and the fault condition has cleared; do not make the screen button force the heater output or suppress active fault detection.

Map each C-more object to the intended PLC data

Every button, indicator, and numeric display needs a tag that identifies the device, PLC address, and data type. A tag name such as KILL.BTN is a label in the HMI project; the example PLC address C5 is what identifies the PLC element being accessed. The labels may differ, although consistent names make cross-checking easier.

1. Open the object’s tag configuration and create or select a tag.
2. Select the PLC device in the tag information settings. The historical project used DEV001 for the PLC device; confirm that the device selected in your project is the one configured for the connected PLC.
3. Enter the PLC address used by the ladder logic. Use a discrete tag for a pushbutton or on/off indicator, and the appropriate numeric format for a setpoint display or entry.
4. Configure the button as a request to the chosen PLC memory bit. Configure the indicator to read the PLC status bit rather than merely echoing the button’s pressed state.
5. For a numeric setpoint object, map the display or entry to the intended PLC variable-memory location. The project guidance identifies Vmem locations for numeric setpoints.

Keep a tag list showing the HMI object, tag label, PLC device, PLC address, data type, and whether the object reads or writes. That list exposes common mismatches: a button writing one bit while the ladder watches another, a display reading a command instead of feedback, or a numeric entry configured as a discrete value.

Build the retained heater fault in PLC ladder logic

The PLC should own the conditions for normal operation and fault retention. Use the auxiliary contact and current sensor as the available feedback inputs in the design, and decide from the actual wiring and equipment behavior which signal or combination constitutes proof that a heater is on. Do not assume that a current sensor proves contactor position or that an auxiliary contact proves heater current.

Use the following as a logic plan, not as copy-and-paste PLC syntax. Replace the descriptive labels with the project’s actual addresses and apply the intended per-heater feedback rule.

IF heater is expected ON AND required feedback is absent THEN set fault latch
IF HMI reset request AND fault condition has cleared THEN clear fault latch
HMI green indication reads heater-running/proven status
HMI red indication reads fault latch

Use separate request, status, and fault signals where practical. The reset button should write only a reset request; it should not directly write the fault latch if that would bypass the PLC’s permissive condition. A momentary request that the PLC consumes and clears is easier to diagnose than a command bit that stays asserted indefinitely. Confirm the chosen momentary or maintained button behavior in the object settings and verify the actual bit transitions online.

Replace unreliable popups with visible status objects

The project’s working correction was to remove popup windows and use static text boxes with their option enabled. For the fault message, bind visibility to the PLC fault latch so the message remains on-screen after the live heater condition changes. For the green “Heater ON” indication, bind visibility or status to the appropriate PLC-running/proof tag, and configure the red fault indication from the latched fault tag.

Do not let color alone carry meaning. Include text such as “Heater ON” and “Heater Fault,” and verify that the red indication remains visible after the contactor turns off when the PLC fault latch is set. Configure any visibility condition against the correct PLC status tag, not against a button state that changes when an operator releases the screen.

If popups are still required by the machine design, isolate the behavior with a minimal test project or one popup at a time before restoring them. The observed static-text workaround restores reliable button operation in this setup; it does not identify a universal popup limit or explain why the previous combination interfered. Do not invent a popup-count threshold.

Prove the tag path before reconnecting the full sequence

Use a single-object test to avoid debugging the whole heating sequence at once. The project guidance proposes a test indicator tied to SP4, described there as a one-second on/off PLC bit. Confirm that description against the actual PLC program before using it; do not treat a test bit as a heater command.

1. With the PLC and HMI device configured, place one indicator on a test screen and map it to the intended discrete PLC bit.
2. Observe the PLC bit and the HMI indicator together. Confirm that the indicator follows the PLC state.
3. Test the screen button against a non-hazardous PLC memory bit intended for testing. Confirm that pressing and releasing the button causes the expected write behavior and that ladder logic reads the same address.
4. Only after the test path works, connect the operator reset request and heater status objects to their production tags.
5. Operate the fault logic under a controlled test condition. Confirm the green status, fault latch, reset request, and red message independently.

When a control does not track, compare the configured device, address, and data type at both ends. Then inspect the live PLC bit and the HMI object state to determine whether the failure is communication, tag mapping, ladder logic, or display visibility. Restore one object at a time; changing several tags and screen objects together hides the cause.

Keep the HMI/PLC project pair maintainable

Save the HMI and PLC projects together with the tag/address list and a short note for each alarm’s set and reset conditions. Reuse the supplied sample projects as learning references where available, but verify every sample address and device configuration against the installed PLC program before adapting it. Sample projects teach object setup; they do not prove that an address is safe or correct for a particular machine.

For the older C-more Micro terminology described in this project, labels such as “Name,” “Label,” and “Data Display Tag” can be confusing when their roles are unclear. Read each field as either an object identifier, displayed text, or data connection, and verify by checking the configured tag and observed PLC value. If the editor version or panel family presents different field names, use the installed software’s help and manual rather than assuming that settings transfer unchanged between C-more and C-more Micro.

FAQ

Stop testing on the heater circuit if the reset behavior can energize an output unexpectedly, the feedback wiring does not match the logic, or the fault cannot be safely simulated. Preserve the project and tag/address list, then contact AutomationDirect official support for product-specific help; do not bypass the PLC fault logic to restore operation.