Skip to content
GraphLabProduct studiesCheck project fit
Product studyGraphLab Pro

Immediate urgent machine-state display

Some machine states should be visible without waiting for the Linux application event loop. This study explores routing a qualified urgent-state indication to the real-time display path so an approved screen can be presented independently of the normal UI.

Depressed emergency-stop control beside a machine HMI showing an immediate urgent stop indication in a guarded production cell.

Intended outcome

Make an urgent state visible through a separate presentation path

A qualified input such as an emergency-stop state could reach the real-time domain through a project-defined path. GraphLab Core could then select a dedicated visual state without depending on Linux rendering.

The screen would communicate the state and the operator action defined by the product team. Detection, machine control, and safety execution would remain the responsibility of the relevant product hardware and safety system.

Proposed behavior

A project-defined operating sequence

  1. State qualification

    The responsible machine or safety subsystem determines the authoritative urgent state.

  2. Independent indication

    A defined signal or message makes that state available to the real-time display domain.

  3. Urgent presentation

    GraphLab Core selects the approved screen, priority, text, and indicators for that state.

  4. Reset and recovery

    The view remains latched or clears only according to the product-specific acknowledgement and reset policy.

Architecture

Responsibilities stay explicit

Authoritative state

The machine or safety subsystem remains the source of truth for the event and its clearance.

Indication channel

A bounded interface carries the qualified state, validity, sequence, and acknowledgement data to the real-time side.

Display behavior

GraphLab Pro implements the agreed visual priority, latching, language, and fallback behavior on the target display.

Project inputs

Integration points to define and validate

  • Authoritative event source and electrical or message interface.
  • Signal validity, diagnostics, priority, latching, acknowledgement, and reset rules.
  • Conflicts between urgent states and other maintenance or fallback screens.
  • Approved graphics, text, localization, accessibility, and operator instructions.
  • Behavior during boot, Linux restart, real-time restart, and power transitions.
  • Target-specific validation with the responsible machine and safety engineering teams.

Assess the concept

Could this fit your platform?

Share the target SoC, display path, BSP, Linux UI stack, and the state or failure you need to make visible.

Check project fit