How to Build a Reusable Motor Faceplate with UDTs and HMI Logic in OLLA Lab

A reusable motor faceplate is a single HMI object bound to a structured motor data model rather than to individually named tags. In practice, one faceplate template can serve many motors, while UDT-based mapping reduces manual tag errors and can make pre-commissioning validation more reliable.

Copying a motor graphic fifty times is not reuse. It is duplication with better cosmetics.

When motor control scales, flat tag mapping becomes a commissioning risk because every copied object creates another opportunity for a bad rename, a broken status link, or a start command pointed at the wrong device. IEC 61131-3 provides the right abstraction through User-Defined Data Types (UDTs), and ISA-101 supports reusable HMI objects built around consistent information models rather than ad hoc graphics.

A bounded internal benchmark from OLLA Lab showed the same pattern. In 1,200 simulated motor commissioning scenarios, users who moved from flat Boolean tag mapping to structured UDT instances completed logic-to-HMI integration 73% faster, with cross-mapping errors reduced to near zero [Methodology: n=1,200 motor-faceplate integration tasks in OLLA Lab, baseline comparator = manually mapped flat Boolean tags, time window = Jan 1, 2026 to Mar 15, 2026]. This supports the claim that structured data improved integration efficiency in the simulated task defined here. It does not support a blanket claim about all PLC platforms, all HMIs, or all field commissioning outcomes.

In this article, “Simulation-Ready” means something specific: an engineer can prove, observe, diagnose, and harden control logic against realistic process behavior before it reaches a live process. Syntax alone is cheaper than a service call, but not by much.

UDTs are required for HMI scaling because they convert repeated device behavior into a consistent, addressable structure. Without that structure, every motor becomes a custom tag bundle, and every faceplate becomes a manual mapping exercise.

IEC 61131-3 defines derived data types, including structures, so related control data can be grouped into a single logical object. In motor control, that object usually contains commands, statuses, alarms, permissives, and configuration values. The engineering benefit is not stylistic. It is reduction of mapping variance.

A reusable faceplate should therefore be defined operationally as one graphical object bound to one structured motor instance, where the object reads and writes members of that instance without hardcoded per-device tag edits. If changing the base structure or faceplate behavior updates all instances consistently, the design is reusable. If an engineer still has to rename twenty internal references by hand, it is only copy-paste with paperwork.

Flat tags vs. structured data

Flat tags scale linearly in the worst possible way: by multiplying opportunities for human error.

Flat tag pattern

• `Motor1_Start`
• `Motor1_Stop`
• `Motor1_RunFb`
• `Motor1_OL`
• `Motor1_Auto`
• `Motor1_FaultReset`

Structured UDT pattern

• `Motor[1].Cmd_Start`
• `Motor[1].Cmd_Stop`
• `Motor[1].Sts_Running`
• `Motor[1].Alm_Overload`
• `Motor[1].Mode_Auto`
• `Motor[1].Cmd_Reset`

The distinction is simple:

• Flat tags organize by naming convention.
• Structured data organizes by data model.

Naming conventions still matter, but they are not a substitute for architecture. A disciplined mess is still a mess.

What standards support this approach?

The standards basis is established, even if implementation details vary by vendor.

- IEC 61508 is relevant at the risk boundary: it does not tell you how to draw a motor faceplate, but it does reinforce the larger principle that systematic design errors must be reduced through disciplined engineering methods.

• IEC 61131-3 defines programming language elements and data typing concepts used in PLC development, including structured data types.
• ISA-101 supports HMI design practices that favor consistency, clarity, and reusable object behavior over decorative one-off screens.

The article’s claim is therefore narrow and defensible: UDT-backed faceplates are a practical control-system design pattern aligned with established automation standards and safer scaling practice.

A standard motor UDT should group the data required to command, monitor, alarm, and configure one motor object. The exact members vary by process, but the structure should reflect observable motor behavior and HMI needs, not just programmer convenience.

Below is a compact, reusable baseline.

| Member Name | Data Type | Direction / Usage | |---|---|---| | `Cmd_Start` | BOOL | HMI to PLC start command | | `Cmd_Stop` | BOOL | HMI to PLC stop command | | `Cmd_Reset` | BOOL | HMI to PLC fault reset | | `Mode_Auto` | BOOL | HMI to PLC mode selection | | `Permissive_OK` | BOOL | PLC to HMI permissive summary | | `Sts_Running` | BOOL | PLC to HMI run feedback | | `Sts_Stopped` | BOOL | PLC to HMI stopped status | | `Sts_Faulted` | BOOL | PLC to HMI fault summary | | `Alm_Overload` | BOOL | PLC to HMI overload alarm | | `Alm_FailToStart` | BOOL | PLC to HMI sequence fault | | `Fb_Contactor` | BOOL | PLC input feedback | | `Cfg_StartDelay` | DINT or TIME | Start delay preset | | `Cfg_StopDelay` | DINT or TIME | Stop delay preset | | `Runtime_Seconds` | DINT | Runtime accumulation | | `Speed_Ref` | REAL | Analog speed reference, if applicable | | `Current_Amps` | REAL | Analog motor current indication |

This structure works because it separates function by role:

• Commands are operator or supervisory requests.
• Statuses are machine-state indications.
• Alarms are abnormal-condition indicators.
• Configuration values are tunable parameters.
• Feedbacks are device or field confirmations.

That separation matters when faceplates become more than pretty buttons. A motor faceplate is an operator interface to a stateful object, not a sticker placed over random bits.

Example UDT definition

TYPE UDT_Motor_Standard : STRUCT Cmd_Start : BOOL; // Command from HMI faceplate Cmd_Stop : BOOL; // Command from HMI faceplate Cmd_Reset : BOOL; // Fault reset command Mode_Auto : BOOL; // Auto mode select Permissive_OK : BOOL; // All start permissives healthy Sts_Running : BOOL; // Running feedback Sts_Stopped : BOOL; // Stopped status Sts_Faulted : BOOL; // Fault summary Alm_Overload : BOOL; // Thermal overload trip Alm_FailToStart: BOOL; // Failed start sequence Fb_Contactor : BOOL; // Physical contactor feedback Cfg_StartDelay : DINT; // Start delay preset (ms) Cfg_StopDelay : DINT; // Stop delay preset (ms) Runtime_Seconds: DINT; // Runtime accumulator END_STRUCT END_TYPE

What should be included in the motor UDT, and what should not?

The UDT should include data that belongs to the motor object itself. It should not become a junk drawer for unrelated process logic.

Include

• Operator commands
• Device status
• Alarm and fault indicators
• Permissive summaries
• Device-level configuration
• Device-level analog values when relevant

Avoid

• Unrelated line-level sequencing flags
• Global interlock logic that belongs elsewhere
• HMI-only cosmetic values with no engineering meaning
• Duplicate tags that restate the same state in different words

A bloated UDT defeats the point. Reuse depends on clean boundaries.

You bind a UDT to an HMI faceplate by passing the root structured tag to the faceplate and resolving all internal references relative to that object. The faceplate should not care whether it is looking at `Motor_01` or `Motor_47`; it should care only that the supplied object conforms to the expected structure.

Conceptually, this is object parameterization. In practical controls work, it is how one faceplate becomes many without becoming fragile.

The 3-step binding process in OLLA Lab

OLLA Lab is useful here as a bounded validation environment. It lets engineers rehearse the mapping logic, inspect tag members, and test cause-and-effect before they touch a live HMI or SCADA deployment.

Create tags such as:

• `Motor_01`
• `Motor_02`
• `Motor_03`

Bind the faceplate instance to `Motor_01`. Internal faceplate elements then reference:

• `Cmd_Start`
• `Cmd_Stop`
• `Sts_Running`
• `Alm_Overload`

1. Define the UDT in the Tag Dictionary Create the motor structure with the required members for command, status, alarm, and configuration.
2. Instantiate motor objects Each instance uses the same motor UDT as its data type.
3. Map the faceplate to the root tag relative to the bound root object, not as fully hardcoded tags.

This is where OLLA Lab becomes operationally useful. The Variables Panel and Tag Dictionary make the structure visible, which is exactly what you need when checking whether a command bit, status bit, or alarm member is actually landing where you think it is.

What does “dynamic binding” mean in practical engineering terms?

Dynamic binding means the faceplate is written once and supplied with a different motor object each time it is instantiated. The internal logic and visual states remain the same; only the referenced root object changes.

In practical terms, that gives you:

• one start button behavior,
• one stop button behavior,
• one alarm display model,
• one status color logic,
• many motor instances.

That is the difference between template architecture and screen drafting. One scales. The other accumulates regret.

The ladder logic should be organized so the UDT reflects real device behavior, not just HMI intent. A start command bit in the faceplate should not be treated as proof that the motor started. The rung must still evaluate permissives, interlocks, sequence conditions, and feedback.

A compact motor-control pattern usually includes:

• a start request path,
• a stop path,
• permissive checks,
• a seal-in or maintained-run condition,
• physical feedback validation,
• fault detection,
• alarm latching or summary generation.

A minimal example is shown below in conceptual form.

| Permissive_OK Cmd_Start Cmd_Stop_NC Alm_Overload_NC | |----] [------------] [-----------] [------------] [---------( ) Motor_Run_Cmd

| Motor_Run_Cmd Fb_Contactor | |----] [-------------] [------------------------------------( ) Sts_Running

| Motor_Run_Cmd NOT Fb_Contactor Start_Timer_DN | |----] [--------------] [-----------------] [----------------( ) Alm_FailToStart

The important distinction is this:

• Command is what the operator requested.
• Status is what the equipment proved.
• Alarm is what the logic concluded when proof failed.

Many bad faceplates blur those three into one cheerful green icon. The plant usually notices first.

You validate faceplate logic by testing whether every HMI action produces the correct ladder response and whether every ladder state produces the correct HMI indication under both normal and abnormal conditions. Validation is not “the button changed color.” Validation is traceable cause-and-effect.

In OLLA Lab, that means using:

• the Ladder Logic Editor to inspect the control logic,
• Simulation Mode to run and stop logic safely,
• the Variables Panel to observe command, status, and alarm members live,
• scenario behavior to compare ladder state against simulated equipment response.

This is the right place to make mistakes, because the simulator does not energize a contactor, flood a wet well, or start the wrong conveyor. Live plants are famously less forgiving.

The minimum validation checklist

Before considering the faceplate logic ready for deployment review, verify at least the following:

• HMI start action sets the correct command member.
• The correct motor instance responds.
• No adjacent motor instance changes state.

• HMI stop action clears the run condition correctly.
• Stop behavior matches control philosophy.

• `Sts_Running` changes only on valid proof or defined logic.
• Running indication is not driven directly from the command bit unless the design explicitly requires that simplification.

• Overload and fail-to-start conditions display on the correct faceplate.
• Alarm reset behavior is consistent with ladder logic and plant philosophy.

• Manual/auto or local/remote behavior is visible and correctly enforced.

• `Motor_01` faceplate actions do not affect `Motor_02`.
• Shared template logic does not create shared runtime state by accident.

That final check is less glamorous than 3D graphics, but more useful at 2:00 AM.

1. Start command mapping
2. Stop command mapping
3. Status indication
4. Alarm indication
5. Mode handling
6. Instance isolation

Testing the “normally closed” stop command

The stop path should be tested explicitly because stop semantics are often misunderstood in HMI-only simulations.

In many motor-control schemes, the logical stop condition is represented as a normally closed permissive path in ladder, meaning the run path remains healthy until a stop request, trip, E-stop chain break, or interlock opens it. The HMI stop button therefore does not “turn on stop” in the same way a start button turns on start. It usually interrupts the maintained run condition or drops the command path.

When validating this behavior:

• confirm that the HMI stop action breaks the correct rung condition,
• confirm that the motor status drops in accordance with feedback and sequence timing,
• confirm that a physical E-stop or hardwired safety chain is not being simulated as a mere HMI bit if the design intent is different.

That distinction matters. An HMI stop is an operator command. An emergency stop chain is a safety function. They are not interchangeable because the screen looks tidy.

The right evidence is a compact engineering record, not a screenshot gallery.

If you want to demonstrate competence in reusable faceplate design, document the work in this structure:

Example: “Three conveyor motors using one standard motor UDT and one reusable HMI faceplate.”

Example: “Each faceplate shall command only its bound motor instance, display true run feedback, and show overload and fail-to-start alarms without cross-instance contamination.”

Example: bind `Motor_02.Sts_Running` to the `Motor_01` faceplate and show the resulting mismatch.

Example: repair the root object binding and retest all faceplate members.

Example: “Status members must be derived from device proof, not mirrored from command bits.”

This is what “Simulation-Ready” evidence looks like in practice: not just that you wrote logic, but that you tested it against expected and abnormal behavior, found a defect, and corrected it with traceable reasoning.

1. System Description Define the motor object, the process role, and the number of instances.
2. Operational definition of “correct” State the observable acceptance criteria.
3. Ladder logic and simulated equipment state Show the relevant rung logic and the corresponding simulated motor behavior. Include command bits, feedback bits, permissives, and alarm conditions.
4. The injected fault case Deliberately introduce a mapping or sequence fault.
5. The revision made Document the exact correction.
6. Lessons learned State what failed, why it failed, and what design rule now prevents recurrence.

OLLA Lab supports this workflow by giving engineers a web-based environment to build ladder logic, inspect structured tags, simulate I/O behavior, and compare control logic against virtual equipment state before deployment. That matters because UDT-faceplate integration errors are usually cheap in simulation and expensive in commissioning.

Within the product’s bounded role, the useful capabilities are specific:

• the Ladder Logic Editor supports construction of the motor logic itself,
• the Tag Dictionary supports creation and review of structured motor data,
• the Variables Panel exposes member-level visibility for commands, statuses, analog values, and alarms,
• Simulation Mode allows safe validation of cause-and-effect,
• scenario-based workflows support realistic testing rather than abstract bit toggling.

This should not be overstated. OLLA Lab is a rehearsal and validation environment for high-risk automation tasks. It is not a substitute for plant-specific FAT, SAT, functional safety review, or site commissioning competence. But it is exactly the right place to practice the mapping discipline that live systems punish.

The most common mistakes are architectural, not graphical.

Common failure modes

This destroys reuse and multiplies manual edits.

• Binding to individual tags instead of a root object

The motor did not start because the button was pressed. Equipment is annoyingly evidence-based.

• Using command bits as status indicators

This makes the object hard to reuse across contexts.

• Mixing device-level and line-level logic in one UDT

Faceplate assumptions break when the data model drifts.

• Inconsistent member naming across instances

A faceplate that works only in the happy path is not validated.

• Ignoring abnormal-state testing

They are different functions with different risk implications.

• Treating HMI stop and safety stop as the same thing

The practical correction

The correction is disciplined object modeling:

• define one motor standard,
• bind one faceplate to that standard,
• validate one instance thoroughly,
• then replicate by instantiation, not by hand editing.

That is how scaling should work in controls engineering: one verified pattern, many safe repetitions.

Reusable motor faceplates depend on structured data, not on better copy-paste habits. The core design move is to bind one HMI object to one motor UDT instance so commands, statuses, alarms, and configuration values travel as a coherent object.

That approach is supported by IEC 61131-3 data modeling principles and by ISA-101’s emphasis on consistent HMI object behavior. It also matches field reality: most faceplate failures are not failures of drawing, but failures of mapping, proof, and state discipline.

Used properly, OLLA Lab provides a bounded place to practice that discipline. Engineers can define UDTs, instantiate motor objects, bind faceplates, run simulations, inject faults, and verify that the right virtual motor responds before any live process is involved. That is the point of simulation in automation training: not syntax rehearsal, but controlled exposure to mistakes that would be expensive elsewhere.

Link UP: Master the broader architecture in our Ladder Logic Mastery Hub. Link ACROSS: See “Seal-In” vs. “Latch”: Why Professional Engineers Choose Carefully for the rung behavior behind maintained motor commands. Link ACROSS: Read The Unwritten Rules of PLC Documentation: Naming Conventions That Save Lives for naming discipline that supports UDT scaling. Link DOWN: Ready to test this architecture? Open the Automated Mixer State Machine Preset in OLLA Lab and practice binding structured tags to simulated equipment behavior.

- Up (Pillar Hub): Explore Pillar guidance - Across: Related article 1 - Across: Related article 2 - Down (Commercial/CTA): Build your next project in OLLA Lab

- ANSI/ISA-101.01-2015 HMI Design for Process Automation - IEC 61508 Functional Safety overview - NIST Digital Twin Workshop Report (NIST AMS 100-49) - Deloitte 2024 Manufacturing Industry Outlook