C-More Micro Troubleshooting for Unreliable Screen Changes

A C-More Micro screen-change request can be missed when a momentary screen button remains asserted as the panel leaves the screen that owns the button. Replace that button action with a latched request and clear the PLC bit after the PLC writes the requested screen number to V-memory.

Stop repeating the momentary-button test

Changing firmware or re-entering the screen number may look like the fastest fix, but neither corrects a request bit that does not return to its inactive state. In one reported installation, the PC programming software and panel firmware were both version 1.11.6.51; updating them did not stop intermittent failures. Treat that as a tested configuration, not as a universal version diagnosis.

• Do not keep using a momentary screen button to trigger the PLC write. The panel may change screens while the button is still pressed. If release handling is associated with the initiating screen, the PLC-facing bit can stay on.
• Do not add arbitrary delays as the first repair. A user reported improvement after slowing the PLC program with timers and rungs, but delays do not correct a stuck request or establish a reliable handshake.
• Do not assume that a successful F-key test proves screen buttons work. F-key requests succeeded in the affected installation while screen-button requests did not. Test the actual screen button and the PLC bit it controls.

Keep the firmware update question separate from the button-trigger failure. If the latched request and reset sequence still fail after confirming the data format and screen-number handling below, collect the project and PLC diagnostics and escalate rather than adding more timing workarounds.

Trace the button bit through the screen transition

A momentary HMI button is active while pressed and must later be released. When that same press requests a screen change, the panel can leave the screen containing the button before the release is processed. The PLC then sees the request bit remain on, or it does not see a fresh off-to-on transition for a later press. The request is therefore not dependable even though the V-memory write logic itself appears straightforward.

Replace the momentary request with a resettable latch

Use a Set On or Toggle screen button instead of Momentary, then clear its PLC coil after the PLC loads the requested screen number. The reported working example uses a Set On button mapped to C215, loads decimal constant K10 into V1500, and resets C215 immediately after the load:

-- C215
LD K10
OUT V1500
RST C215

Apply the same sequence to each screen request, using the correct request bit and destination value for that screen. The important sequence is: latch the request, perform the load, then reset the request bit. Do not reset the bit before the PLC evaluates the load condition.

1. In the panel project, change the affected screen button from Momentary to Set On or Toggle.
2. In the PLC, use that button's mapped bit to execute the screen-number load.
3. Reset the mapped bit after the load instruction, as in the example.
4. Repeat with more than one target screen and confirm every request can be made again after the bit resets.

Reports of this Set On/reset approach described repeatable screen changes, including a separate installation monitoring the panel's current screen through Panel-to-PLC data. The momentary button plus reset approach was also tried but remained inconsistent in one report; use the latched Set On or Toggle sequence as the first production workaround.

Match the screen-number representation end to end

One report states that a C-More Micro project screen number must be decimal, unsigned 16-bit. Another installation reported that changing its screen-number tag to decimal caused failures, while BCD appeared to work most of the time. These observations conflict, so do not convert the project wholesale based on the word “screen number” alone.

Inspect the panel tag configuration, the PLC instruction loading the V-memory word, and the displayed current-screen value. Confirm that the value encoding the PLC writes is the format the panel tag interprets. Test one known screen number with both the requested and current values visible; record the actual word value and format before changing other screens. If changing format makes behavior worse, restore the known project setting and resolve the trigger/reset behavior independently.

Clear a completed request before issuing the same number again

A request value can fail to retrigger if the PLC writes the same number that is already present. For example, after writing screen number 5, writing 5 again does not change the word. A suggested PLC strategy compares Current Screen with Screen To Switch To, then writes an invalid sentinel such as 9999 into the request word after the panel reaches the target. That clears the request value so a later write of the same valid screen number creates a new value transition.

Use that strategy only after confirming that the sentinel is invalid for the configured project and is ignored safely by the panel. Do not let a sentinel value become a valid destination in a project with a different screen range. The Set On/Toggle request bit still needs its own reset; clearing the screen-number word does not repair a latched button bit.

Use current-screen feedback to separate the failure points

Expose the panel's Current Screen value to the PLC with the Panel-to-PLC setting, then compare it with the requested screen number. This separates a button/input problem from a failed screen transition and gives the PLC a completion condition for clearing a request word.

• If the screen-button bit never turns on, inspect the panel button mapping and the PLC address it targets.
• If the bit turns on but stays on after the screen changes, correct the button action and reset sequence.
• If the bit resets and the requested value changes but Current Screen does not, inspect the value format, configured screen target, and panel diagnostics.
• If Current Screen reaches the target but a repeated request to that same target is ignored, clear the request value or generate a fresh request transition.

The reported color-change function working correctly is useful evidence that some panel-to-PLC V-memory exchange is operating, but it does not verify the screen-number tag, request edge, or screen navigation logic.

Prove repeatability before returning the panel to service

Test the repaired path using the same screen buttons operators will use. Include repeated requests to one target, transitions among multiple targets, and a return to a screen that was requested earlier. A single successful transition does not prove that the request bit resets or that writing the same number again will be detected.

1. Monitor the request bit, the V-memory screen request, and Current Screen while pressing each screen button once.
2. Verify that the PLC loads the intended screen number and resets the latched request bit.
3. Confirm Current Screen reaches the intended destination and that the request word clears if using the sentinel method.
4. Repeat the same screen request after completion and verify the panel responds each time.
5. Compare the screen-button path with an F-key request only as a diagnostic; do not accept F-key success as proof of the screen-button repair.

Leave arbitrary timer delays out of the permanent repair unless measured behavior identifies a specific timing requirement. Record the panel software/firmware version and the configured number format with the tested PLC logic so later edits do not reintroduce the intermittent path.

Frequently asked questions