DWIN DGUS HMI Development: What to Specify Before Designing the Screens

You can make an attractive DWIN screen before the firmware team has agreed what a single button means. That is usually how the second version becomes more expensive than the first. A useful DGUS HMI brief starts with the machine states and controller interface, then defines the screens that let a person understand and operate them.

This guide concerns the specification and integration work before detailed screen design. Industrial HMI design covers the broader interaction principles. DGUS products and tool versions differ, so pin the actual hardware and applicable DWIN development documentation in the project record instead of copying settings from an unrelated example.

1. Fix the module and installed conditions

Record exact display model, controller family, resolution, orientation, touch technology, supply, electrical interface, connector, mounting, viewing conditions, and environmental constraints. Identify the intended toolchain and versions. Similar-looking modules can have different integration requirements; a diagonal screen measurement is not a sufficient hardware specification.

Review the installed front panel, viewing distance, lighting, gloves where relevant, touch access, cable route, and replacement procedure. Confirm usable area after bezels and overlays. Enclosure co-design helps coordinate the physical interface. A beautiful button partly hidden by the bezel remains a mechanical problem with excellent typography.

2. Assign state ownership before creating pages

List machine states and the information the person needs in each: unavailable, ready, selection, payment, authorized, operating, completed, fault, and service as applicable. Identify the controller or backend authority for each fact. The display should request actions and present confirmed state rather than invent its own independent transaction lifecycle.

Define whether navigation is local, controller-driven, or a combination with clear rules. A page change must not itself imply payment success, accepted actuation, or completed service. Payment state machines illustrates why screen state and business state should remain related but distinct.

3. Prepare a complete variable map

For every exchanged value record address or identifier, width, encoding, units, scaling, allowed range, default, direction, owner, update trigger, and validity. Include text length, numeric sign, byte or word conventions, and whether a value is a snapshot or persistent configuration. Resolve overlapping allocations before two teams build against the same space.

Keep the map versioned and readable by both teams. Use the selected DGUS documentation for exact address semantics and supported formats. A spreadsheet that only says temperature at one address leaves unanswered whether the value is signed, scaled, current, valid, or even in the same units as the screen label.

4. Define touch requests and controller responses

Specify the meaning of each touch event, eligibility, repeated-touch behavior, debounce or rate handling, acknowledgment, and visible response. A customer can tap twice while a slow screen appears unchanged. The controller must reject or recognize redundant requests without converting them into two purchases or two machine actions.

Carry session or operation context where required and reject obsolete events after navigation or timeout. Distinguish a request received from an action accepted. Disable or explain controls that cannot currently be used, but do not rely on screen disabling as the sole enforcement of machine prerequisites. The controller remains responsible for validating commands.

5. Specify the communication and restart contract

Record electrical levels, serial settings, message framing, permitted payloads, rate limits, parser behavior, and error recovery for the chosen module. Define how partial, malformed, repeated, or unexpected messages are handled. Use the relevant manufacturer protocol rather than a generic UART assumption; sharing a wire does not establish a complete application interface.

Test the display restarting while the controller continues an active operation, and the controller restarting while the display still shows an old page. Establish how the screen is resynchronized from authoritative state. Define communication-loss indication and whether controls remain active. Stale ready text must not invite a new transaction while the actual machine is recovering.

6. Plan text, languages, assets, and dynamic content

Inventory screen copy, fonts, icons, backgrounds, numeric fields, QR resources, and supported languages. Check actual character rendering, truncation, alignment, and asset capacity for the selected module and tools. Test long product names and large values, not only the neat labels in the initial mockup.

For payment screens, bind dynamic content to the active purchase session and clear it when it becomes obsolete. Confirm how images are transferred or selected using capabilities actually supported by the chosen system. Dynamic UPI QR integration defines the transaction contract; the HMI brief must specify how that contract becomes visible.

7. Design faults and service access as real workflows

Give customer faults a plain explanation, current status, and next step. Give authorized service users appropriate diagnostic detail, version information, and bounded actions. Separate these audiences without exposing credentials or unrestricted machine commands. Payment kiosk UX covers customer-facing exception messages.

Define access, timeout, audit requirements, and exit behavior for service mode. Decide how maintenance interacts with an unresolved purchase. A local test should not silently alter inventory or clear the evidence a support operator needs. Include a way to identify the HMI project and compatible controller release on the installed machine.

Exact module, electrical interface, and mounting:
Tool versions and applicable manufacturer documents:
State model, page map, and navigation ownership:
Versioned variables, formats, units, and event definitions:
Touch acceptance, duplicate handling, and responses:
Startup, communication loss, and resynchronization:
Assets, languages, dynamic resources, and limits:
Customer faults and authenticated service functions:
Editable sources, deployed assets, compatibility, and tests:

8. Verify the interface with firmware and real users

Begin with a simulator or bench controller where useful, then test the actual display and machine. Exercise every page, field limit, touch event, repeated request, error, communication interruption, and restart path. Check that the controller and display interpret the same value identically, including unavailable and out-of-range states.

Observe representative users completing normal and interrupted tasks at the installed height and lighting. Record misunderstandings and missed status changes. Include screen and controller versions in the evidence. A serial trace proving bytes arrived cannot establish that a customer understood which compartment to open.

9. Release the source and compatibility information

Deliver editable project files, source assets, fonts and licensing information as appropriate, variable map, protocol contract, deployable files, loading procedure, and compatible controller versions. Record known limitations and the verification baseline. Avoid a handover consisting of one folder that works only on the original designer’s computer.

SolveMpire can discuss HMI, embedded firmware, and mechanical integration together. Bring the selected module, machine state diagram, current firmware interface, language needs, and enclosure. The next step should be a shared interface specification that makes screen design and controller development reinforce each other.

For customer-facing exceptions, payment kiosk UX maps verified states to waiting messages, repeated-touch behavior, support references, abandonment, and user-comprehension tests.