Configuring SMConstructor Extra Screens on a Pixel Controller

The visible fault is a display update that occurs in the wrong scan: text assigned to screen 0 remains over the generated main screen, or lines and images disappear after returning from a custom SMArt screen. Treat the custom screen and the generated screen as mutually exclusive display states, then delay re-enabling the generated screen by a couple of task ticks. Keep the generated functions wrapped externally where possible; modify the internal Selector only when the external interface cannot provide the required transition.

Symptom quantities and decision points

The number that matters is the interval between disabling one display state and enabling the next. This is update timing, not application logic: a correct destination command can still leave stale text or incomplete graphics when both screen paths overlap or the generated screen resumes too early.

Display ownership and redraw mechanism

A generated SMConstructor project already owns the standard main screen and its menu hierarchy. A custom SMArt screen adds another source of display content. If static text with several variants is placed on screen 0 while the generated main screen remains active, the renderer has not been given an exclusive screen choice; it draws the custom object over the standard content.

The clean architecture has one active display owner at a time:

1. The custom SMArt state owns the display while the panel name or service information is visible.
2. The exit event disables that state.
3. A transition state holds the standard screen off for a couple of ticks.
4. The generated main-screen state becomes active and redraws its complete graphic set.

The delay is required because display commands are processed over controller scans. Releasing one screen and requesting another in the same scan can change the logical state before all drawing operations have been refreshed. Lines and pictures expose the race more clearly than plain text because they require multiple drawing operations.

Navigation architecture

The preferred implementation wraps the generated main-screen function from outside. A working arrangement used a custom SMArt screen as the initial main display and opened the standard generated main screen with UP plus OK. The key choice can be changed; the architectural requirement is that the external logic selects exactly one screen path and controls the return timing.

This approach preserves the generated macro internals and reduces rework when the project is regenerated. A reported implementation used four blocks, but the evidence does not define their individual types or connections. Select the blocks available in the installed project library to perform four roles: trigger recognition, custom-screen request, transition delay, and standard-screen request.

An internal alternative is to expose a user-screen input and UI output through the main-screen Selector. Put all required reset handling inside that selection layer so a transition cannot leave both states asserted. This provides direct integration but couples the customization to the generated macro structure, so record the change and recheck it after every regeneration.

Panel-name selection procedure

1. Create a dedicated SMArt screen. Place the panel-name text and its permitted variants on that screen. Keep it separate from screen 0 so opening the generated main screen does not preserve the text as an overlay.
2. Create an explicit selection state. Store the currently selected panel name in the project logic and map each valid state to one displayed text variant. Retain the state while navigating away so the same name returns when the custom screen opens again.
3. Choose the entry gesture. The requested F2/F3 controls conflict with standard assignments because F1 through F6 are occupied. Use a two-button combination, a long press, or a double press when the existing functions must remain available.
4. Recognize one event per gesture. Convert the chosen gesture into a single navigation or selection event. A held key must not cycle repeatedly through text variants unless repeated scrolling is intentional.
5. Switch display ownership. Disable the current screen request before asserting the destination request. Where the generated interface supports external wrapping, keep this arbitration outside the constructor functions.
6. Add the return interval. When leaving the custom screen, hold the standard screen request off for a couple of task ticks, then activate it. Count task executions rather than estimating wall-clock time because no task period is specified.
7. Provide a deterministic exit. Map an available gesture to the standard main screen. The demonstrated choice was UP plus OK, but the project may use another gesture after conflict testing.

Return timing and alternate recovery

Start the return sequence by clearing the custom-screen request. Advance a scan counter or equivalent state machine on each execution of the task that controls the UI. After a couple of ticks, assert the standard-screen request. Read the actual task period in the controller project if elapsed time must be documented; the evidence specifies ticks, not milliseconds.

If delayed standard-screen activation cannot be inserted cleanly, another tested recovery sequence pulses button 0 and Esc sequentially, with each action on the next tick. This forces navigation through separate display updates instead of applying both actions in one scan. Treat this as an alternate return sequence, not an additional simultaneous command path.

Do not hold both simulated button signals active together. Simultaneous or persistent button states can produce repeated navigation and obscure whether the redraw fault comes from display timing or input handling.

Functional and redraw verification

1. Start from the generated standard main screen and record every visible line, image, value, and menu indicator.
2. Open the custom SMArt screen with the selected gesture. Confirm that only the custom content is visible and that no generated-screen objects remain underneath or over it.
3. Use the selection controls once. Confirm that one press produces one panel-name change and that standard F1-F6 functions have not also executed.
4. Exit to the generated main screen and inspect the recorded lines and images. Missing geometry indicates that the standard screen still resumes too early.
5. Repeat the transition several times from different menu positions. Verify that the menu state, selected panel name, and active screen remain deterministic.
6. Run the test in the generated target project, including an ITP project where applicable. A transition that works in an isolated example can still expose redraw timing in the generated application.
7. Test held keys, near-simultaneous keys, and release order. Confirm that a combination, long press, or double press produces only its assigned event.

When testing the delay, monitor the custom-screen request, standard-screen request, transition state, and key-event pulse in the same trace or online view. The valid sequence contains no scan with both screen requests active, and the standard request rises only after the transition interval.

Recurring integration pitfalls

Frequently asked questions