Console display mapping logic for factory screens

Keep console identity separate from display identity

A console identifies where a request originates. A display identifier names the application window or view that the existing action should affect. These are different identifiers, even if your current naming convention makes them look similar.

In this article, “display” means a runtime window or view, not the physical screen. Keep navigation logic within the application that owns those views. The distinction between a factory status display and an operator HMI matters when deciding which system should own the behavior.

Define the values before writing the lookup:

Use exact identifier comparison rather than checking whether one name contains another. For example, a prefix shared by two consoles is not enough to distinguish their records.

Prefer a configured console identifier over an editable text field. If the application uses a computer name or session identifier, document how it resolves to the configured console. An unknown identity should produce a diagnostic, not fall back to another console's records.

Make the CSV an explicit relationship

Use one row for each console-to-display association. Multiple rows for the same console naturally represent multiple target views:

console_id,display_id
CELL_A,PRODUCTION_OVERVIEW
CELL_A,SHIFT_TREND
CELL_B,PACKING_OVERVIEW

These column names are an application design choice, not a standard runtime import format. The loader and the file-maintenance process must agree on their meaning.

For CELL_A, the result is the set containing PRODUCTION_OVERVIEW and SHIFT_TREND. It is not every view whose name resembles CELL_A, and it is not every row in the file.

Define validation rules before accepting the file:

• Require the expected headers and field count.
• Choose an encoding supported by the loader and export consistently.
• Specify whether blank lines are ignored.
• Decide whether surrounding spaces are removed.
• Define case sensitivity without merging identifiers that the application treats as different.
• Reject missing console or display identifiers.
• Check console and display identifiers against maintained inventories.
• Collapse repeated console/display pairs with a diagnostic, or reject them under a documented policy.
• Report invalid records with their record position and reason.

Use a CSV parser that supports quoted fields. Splitting each line at every comma does not correctly handle a quoted field containing a comma. Treat parsed identifiers as data, never as script fragments to execute.

Inspect the parsed values during commissioning. A spreadsheet view can conceal spaces, quoting, or an unexpected export format.

Activate only a fully validated mapping

Choose a file-reading method supported by the installed runtime environment. An engineering import can populate configuration data without creating any runtime lookup or event binding.

First decide where the lookup belongs. A local lookup is usually simpler when the action affects only local presentation. Central management can help distribute configuration, but it introduces a routing requirement: the result must return to the runtime that issued the request.

Check file access from the environment that actually executes the loader. A path available during configuration may be unavailable to the runtime account. Confirm both the resolved location and the account's read permissions. Restrict write access to the approved configuration workflow.

Load a candidate file into temporary storage. Parse and validate the complete candidate before replacing the active mapping. This avoids exposing half of a newly loaded table to a request.

Define the reload failure policy explicitly. Retaining the last valid mapping may be appropriate for ordinary presentation rules, but it also means older rules remain active. If that is unacceptable, reject new requests until a valid mapping is available. In either case, expose the active revision, load result, and diagnostic.

Do not replace the active file while the loader is reading it. Use a controlled publication method supported by the environment, and activate the resulting mapping between requests.

Connect matched records to the existing action

Preserve the working display action and change how its arguments are selected. Before connecting the CSV lookup, confirm the existing action's documented arguments, execution context, and completion behavior using a known ordinary view.

A Boolean request bit cannot carry a list of display identifiers by itself. The application must retain the selected targets somewhere else.

Two common designs are:

• Direct iteration: the request handler captures the matching display set and invokes the existing action for each target.
• Queued execution: the lookup places target records in a queue, and the action handler consumes them with their destination context.

Choose a method supported by the application's scripting and event model. Do not repeatedly overwrite one display-name tag while assuming an asynchronous handler will process every intermediate value. It may read only the latest value.

If an existing event must consume a bit and an argument tag, keep the argument stable until that event has consumed it. Define how completion is acknowledged before advancing to another target.

A local presentation request does not inherently need a controller write. Trace any externally bound tag before using it, and avoid involving machine control where the task is only local navigation.

Give each request a defined lifecycle

A bit that remains true may not produce another rising edge. A condition evaluated repeatedly while true may instead call the action many times. The correct behavior depends on the configured trigger, so document it rather than relying on the bit's name.

At acceptance, capture the requesting console, destination runtime, active mapping revision, and selected display set. Keep that snapshot stable until the request finishes. A reload should affect the next request, not change targets halfway through the current one.

Define these outcomes separately:

• No matches: report that no association exists and perform no display action.
• Invalid destination: reject the request rather than redirecting it.
• Busy handler: queue or reject the new request according to a stated policy.
• Partial completion: record which targets completed and which failed.
• Completed request: acknowledge completion and reset the trigger according to the event design.

For queued or remote execution, a request identifier helps distinguish a new request from a duplicate delivery. Keep request identity separate from console identity and display identity.

Do not assume retrying is harmless. Check whether the existing action safely tolerates a repeated call, including a call for a view that is already hidden. After partial completion, retry only according to that documented behavior. If completion is uncertain, report uncertainty instead of claiming success.

Diagnose the boundary that failed

Expose enough state to follow one request from identity selection through execution. A changing bit alone does not demonstrate that the correct view changed in the correct runtime.

Keep configuration errors distinct from action errors. A missing CSV file, an unknown display identifier, and an action failure require different corrections.

Check what changes on the runtime screen

Use ordinary, noncritical views in a controlled application test. Include a console with several mapped views and another with a different set. Confirm that each request affects only its selected targets and destination.

Also check the less convenient cases:

• A console with no matching rows.
• An unknown console or display identifier.
• Duplicate associations and quoted CSV fields.
• An unreadable file and an invalid replacement file.
• A request arriving during a reload.
• A second request arriving while the first is active.
• An action failure after some targets have completed.

The intended change is narrow: the CSV supplies target selection instead of manual entry. It does not expand the existing action's authority, establish a safety function, or turn a presentation display into a control interface. Keep that boundary visible in the implementation and its diagnostics.

Questions