B&R HMI Integration — mapp View & Panel Systems

Audience: Automation engineers maintaining undocumented B&R CP1584 machines with zero OEM documentation.

Scope: mapp View (HTML5), legacy POWER WORX/VNC display paths, OPC UA FX data exchange, Automation Studio project recovery, panel replacement procedures.

Table of Contents

1. Overview
2. Architecture
3. mapp View Deep Dive
   • Project Structure in Automation Studio
   • Widget Framework & Pages
   • Content vs. Layout Separation
4. Data Exchange: OPC UA FX
   • Data Model Mapping
   • Variable Binding
   • Diagnostic Reads Without the Project
5. Legacy Protocols: POWER WORX & VNC
6. Alarm Handling: mapp AlarmX
7. Diagnosing HMI Issues on an Undocumented Machine
8. Recovering the HMI Project Without OEM Files
9. Panel Replacement Procedure (CP1584 Context)
10. Multi-Client / Multi-User Setup
11. Practical Code Examples
12. Key Findings
13. Cross-References

Overview

B&R Automation’s HMI ecosystem has evolved from proprietary serial/ethernet display protocols to a fully web-based architecture built on open standards. On a CP1584 (or any modern B&R controller with mapp View), the HMI is not a separate application — it is an integrated web server running inside the controller’s runtime, rendering HTML5 pages that bind to PLC variables through the OPC UA FX (Field eXchange) data model.

This means:

• There is no separate “HMI program” to worry about — the HMI is part of the controller project.
• The display is served over HTTP/HTTPS on the controller’s Ethernet interface.
• Any device with a web browser can be the HMI panel. Dedicated B&R Panel PCs (Power Panel series, panels with built-in B&R controllers) run a fullscreen Chromium-based runtime that points at the controller’s web server.
• If you have no OEM documentation, the HMI configuration lives inside the .apj (Automation Studio project) or in files deployed to the controller’s flash filesystem.

Architecture

┌──────────────────────────────────────────────────────────────────────┐
│  B&R Controller (e.g. CP1584)                                        │
│                                                                      │
│  ┌─────────────────┐    ┌──────────────────┐    ┌────────────────┐  │
│  │  PLC Logic       │    │  mapp View        │    │  OPC UA FX     │  │
│  │  (IEC 61131-3)   │◄──►│  Web Server       │◄──►│  Data Broker   │  │
│  │  ST/SFC/CFC/LD   │    │  (Port 80/443)    │    │                │  │
│  └─────────────────┘    └────────┬─────────┘    └────────────────┘  │
│                                  │                                  │
│  ┌────────────────────────────────┼──────────────────────────────┐  │
│  │  Runtime Filesystem            │                               │  │
│  │  /opt/mappView/                │                               │  │
│  │    ├── pages/  (*.page)       │                               │  │
│  │    ├── widgets/ (*.widget)    │                               │  │
│  │    ├── css/                   │                               │  │
│  │    ├── js/                    │                               │  │
│  │    └── config/                │                               │  │
│  └────────────────────────────────┼──────────────────────────────┘  │
└───────────────────────────────────┼──────────────────────────────────┘
                                    │
                    ┌───────────────┼───────────────┐
                    │               │               │
              ┌─────▼─────┐  ┌─────▼──────┐  ┌────▼───────┐
              │  Panel PC  │  │  VNC       │  │  Web Browser│
              │  (local)   │  │  (remote)  │  │  (any dev.) │
              │  Chromium  │  │  port 5900 │  │  HTTP/HTTPS │
              └────────────┘  └────────────┘  └─────────────┘

Key architectural principle: HMI logic and control logic are completely decoupled. The PLC program has no knowledge of the HMI screens. The HMI screens have no knowledge of the PLC program structure. They are connected solely through the OPC UA FX variable namespace.

mapp View Deep Dive

Project Structure in Automation Studio

In Automation Studio, mapp View is a mapp component that you add to the project. Once added, it creates a structured directory tree:

MyProject/
├── Logical/
│   ├── mappView/                    ← mapp View configuration
│   │   ├── Pages/                   ← .page files (screen definitions)
│   │   │   ├── Main.page
│   │   │   ├── Diagnostics.page
│   │   │   └── RecipeEditor.page
│   │   ├── Widgets/                 ← Reusable widget definitions
│   │   │   ├── MotorStatus.widget
│   │   │   └── TemperatureGauge.widget
│   │   ├── Frames/                  ← Frame layouts (.frame)
│   │   ├── Styles/                  ← CSS files
│   │   │   └── Custom.css
│   │   ├── Resources/               ← Images, SVGs
│   │   ├── Data/                    ← Data configuration (.data)
│   │   │   └── mappViewData.data
│   │   ├── Config/                  ← .config files (roles, clients)
│   │   │   ├── Roles.config
│   │   │   └── Clients.config
│   │   └── mappView.config          ← Root configuration
│   │
│   └── Libraries/                   ← Linked widget libraries
│       └── mappViewWidgets/
│
├── Physical/
│   ├── CP1584/                      ← Target hardware configuration
│   └── ...
│
└── MyProject.apj                   ← Project file

File types you will encounter:

Widget Framework & Pages

mapp View provides a library of drag-and-drop widgets organized by function:

• Display widgets: Text, Image, LED, Bar, Trend, Gauge, Table
• Input widgets: Button, Edit, CheckBox, RadioButton, Slider, DatePicker
• Container widgets: Group, Tab, SplitPanel, ScrollBox, Layer
• Chart widgets: CurveTracker, XYChart, BarChart
• Special widgets: AlarmList, RecipeEditor, CameraView, MaintenanceUI

Each widget has properties that fall into categories:

1. Layout — position, size, anchoring
2. Style — colors, fonts, borders
3. Data — variable bindings (the OPC UA FX links)
4. Behavior — click handlers, visibility conditions, animations

Widget data binding syntax in the .data file uses dot-notation referencing the OPC UA FX namespace:

// Data binding example (mappViewData.data)
Content.Main.StatusText.Value = "gMachineStatus.sCurrentState"
Content.Main.StartButton.Enable = "gMachineStatus.bRunning"
Content.Main.TempDisplay.Value = "gAxis[0].fTemperature"

Content vs. Layout Separation

mapp View enforces a strict three-layer separation:

This separation is critical for undocumented machines because:

• You can change variable bindings in the .data file without touching any page layouts.
• You can swap language resource files without rebuilding the project.
• Layout changes don’t affect what data is displayed.

Data Exchange: OPC UA FX

Data Model Mapping

OPC UA FX is B&R’s proprietary extension to the OPC UA information model, optimized for high-performance cyclic data exchange between the PLC and HMI. It runs inside the controller — no external OPC UA server is needed.

The FX model organizes variables into a hierarchical namespace:

Data
├── Global
│   ├── gMachineStatus
│   │   ├── sCurrentState      (STRING)
│   │   ├── bRunning           (BOOL)
│   │   ├── nErrorCode         (UINT)
│   │   └── fCycleTime         (LREAL)
│   ├── gAxes
│   │   └── [0..7]
│   │       ├── fPosition      (LREAL)
│   │       ├── fVelocity      (LREAL)
│   │       ├── bHomed         (BOOL)
│   │       └── bEnabled       (BOOL)
│   └── gRecipe
│       ├── sActiveRecipe      (STRING)
│       └── rParameters
│           ├── fSpeed         (LREAL)
│           ├── fForce         (LREAL)
│           └── nCount         (UDINT)
├── AlarmX
│   ├── nActiveCount           (UDINT)
│   └── aEntries[]
│       ├── sText              (STRING)
│       ├── nCode              (UDINT)
│       ├── eSeverity          (ENUM)
│       └── tTimestamp         (DATE_AND_TIME)
└── mappView
    ├── nClientCount           (USINT)
    └── aClients[]

Variable Binding

Variable bindings in mapp View are not hardcoded in widget definitions. They use a three-part indirection:

1. PLC declares global variables (in IEC code or mapp component FBK instances).
2. The .data file maps those PLC variables to symbolic names in the FX namespace.
3. Widgets reference the FX symbolic names.

PLC side (IEC 61131-3):
  PROGRAM Main
  VAR_GLOBAL
    gMachineStatus : ST_MachineStatus;
  END_VAR

FX data binding (mappViewData.data):
  Data.Global.gMachineStatus → Main.gMachineStatus

Widget property (in page/widget XML):
  Content.Main.StatusText.Value → Data.Global.gMachineStatus.sCurrentState

This indirection is what makes the content/layout/logic separation work.

Diagnostic Reads Without the Project

If you have no Automation Studio project, you can still read the live variable namespace from the controller:

Method 1: OPC UA Client (e.g., UAExpert, Prosys Simulator)

1. Connect OPC UA client to controller IP
   - Endpoint URL: opc.tcp://<CP1584_IP>:4840
   - Security: None (or sign-only, depending on config)
   - No username/password by default

2. Browse the namespace:
   - Root → Objects → Data → Global
   - All PLC global variables are exposed here
   - Root → Objects → Data → AlarmX
   - Active alarms and history

3. Read/scribe individual variables
4. Monitor cyclic changes (subscription)

Method 2: B&R Automation Studio “Upload from Target”

1. Open Automation Studio → File → New → Project from Target
2. Enter controller IP address
3. Select hardware configuration to upload
4. This recovers:
   - Physical hardware configuration (module types, addresses)
   - Software object list (what programs/components are running)
   - Global variable declarations
   - mapp component instances and their configurations
   - File system contents (including mapp View files)
5. Does NOT recover:
   - Source code of PLC programs (only compiled object code)
   - Comments or original variable names (only runtime names)
   - .page/.widget source files IF the OEM disabled source deployment

Method 3: FTP to controller filesystem

# B&R controllers expose file system access via FTP
ftp <CP1584_IP>
# Default credentials: admin / admin (may differ)

# On Automation Runtime (VxWorks), the CF card is mounted as:
#   C:\ — system partition (firmware, OS files)
#   F:\ — user partition (application, mapp View, logs)

# mapp View deployed files are typically at:
#   F:\mappView\
# Check with:
dir F:\mappView
dir F:\UserProject

# Automation Studio project files (if deployed):
#   F:\UserProject\

WARNING: The CP1584 runs Automation Runtime on VxWorks — it does NOT provide SSH access. All filesystem access is via FTP (see ftp-web-interface.md). Filesystem access depends on firmware version and security settings. Some machines have FTP disabled or credentials changed from defaults.

Legacy Protocols: POWER WORX & VNC

POWER WORX (Proprietary HMI Protocol)

Before mapp View, B&R’s HMI systems (Power Panel T-Series, older Panel PCs) communicated with PLCs using the POWER WORX protocol — a B&R-proprietary binary protocol over Ethernet or serial.

Characteristics:

• Binary protocol, not human-readable
• Runs on Ethernet (TCP, typically port 49152 or configured) or serial (RS-232/TTY)
• Direct memory-mapped variable exchange (the HMI reads/writes PLC memory directly)
• Tightly coupled — HMI knew PLC memory layout and structure
• Replaced by OPC UA FX in modern systems

If you encounter POWER WORX on a CP1584:

• This means the machine has a legacy Power Panel connected alongside the CP1584
• The CP1584 acts as a gateway/bridge between POWER WORX and OPC UA
• Check Automation Studio configuration for POWERWORX or PVI (Process Visualization Interface) components
• PVI is the B&R library that implements POWER WORX communication

// PVI object access in IEC 61131-3 (legacy pattern)
// This is what you might find in older PLC code
PVI_Connect(hConnection, 'CP1584', 'TCP', '<IP>');
PVI_ReadVariable(hConnection, 'Main.gMachineStatus', &rxStatus);
PVI_WriteVariable(hConnection, 'Main.gCmdStart', bStart);

VNC (Remote Display)

VNC is used on B&R systems as a passive remote display mechanism — it mirrors what is shown on a connected Panel PC’s screen.

┌──────────┐   VNC (5900)   ┌──────────────┐
│  Panel PC  │───────────────│  Remote PC    │
│  (shows    │               │  (VNC viewer │
│   HMI)     │               │   / noVNC)   │
└─────┬──────┘               └──────────────┘
      │ HTTP/HTTPS
      │
┌─────▼──────┐
│  CP1584    │
│  (mapp View│
│   server)  │
└────────────┘

• Default VNC port on B&R Panel PCs: 5900
• Some B&R systems also expose noVNC (HTML5 VNC client) on the controller’s web server
• VNC is display only — you cannot inject HMI commands through VNC
• For full remote HMI access, connect a browser directly to the controller’s mapp View server instead

Accessing VNC:

# Direct VNC connection to Panel PC (not the CP1584 itself)
vncviewer <Panel_PC_IP>:5900

# noVNC via controller web interface (if available)
http://<CP1584_IP>/vnc.html

VNC Configuration Notes:

• VNC is available on B&R Panel PCs and Automation PCs (APC series) — not on headless CPUs like the CP1584
• On the CP1584 specifically, the VNC server is part of the VNC Component in Automation Studio (Visualisierung > VNC) and requires it to be configured in the project
• Default VNC password: typically blank (no password) on older systems; configured in the VNC component settings
• Security warning: VNC traffic is unencrypted by default. On plant networks, use a VPN or SSH tunnel, or disable VNC and use the web-based mapp View interface instead
• VNC performance depends on resolution, color depth, and network bandwidth. Reduce resolution on slow links (10 Mbps)
• Troubleshooting VNC failures: Check that the Panel PC’s VNC component is enabled in the project (look for VncSrv in the task configuration via Automation Studio online view). If VNC doesn’t connect, check firewall rules and verify port 5900 is not blocked by the plant network

Alarm Handling: mapp AlarmX

mapp AlarmX is the integrated alarm management component for mapp View systems. It provides:

• Centralized alarm definition in the Automation Studio project
• Automatic alarm triggering when bound variables change state
• Historical alarm logging with timestamps and acknowledgment
• HMI integration via the AlarmList widget

Architecture

PLC Logic ──► mapp AlarmX Component ──► OPC UA FX ──► mapp View AlarmList Widget
                  │
                  ├── Alarm Definitions (.alarmx file)
                  ├── Alarm Groups (Machine, Safety, Process...)
                  ├── Severity Levels (Info, Warning, Error, Fatal)
                  └── Alarm Logging (to SD card / internal flash)

Alarm Configuration File Structure

// In the Automation Studio project: Logical/mappAlarmX/
AlarmGroups.config      → Group definitions
AlarmInstances.config   → Which variables trigger which alarms
AlarmParameters.config  → Thresholds, delays, severity mapping

Accessing Alarms Without the Project

# Via OPC UA:
Browse to: Objects → Data → AlarmX → ActiveAlarms

# Key variables exposed via OPC UA FX:
AlarmX.nActiveAlarmCount     → Number of currently active alarms
AlarmX.aActiveAlarms[0..N]  → Array of active alarm structures
  .sText                     → Alarm description
  .nCode                     → Alarm code number
  .eSeverity                 → Severity level
  .tOccurrence               → First occurrence timestamp
  .tAcknowledged             → Acknowledgment timestamp (0 if unack'd)

# Via Automation Runtime console (if SSH access):
# Alarm log files are typically stored at:
/flash/alarmlog/
/flash/UserProject/Log/

See also: alarm-logging.md for detailed alarm logging analysis and recovery procedures.

Diagnosing HMI Issues on an Undocumented Machine

Symptom: HMI Screen Blank or Not Loading

CHECKLIST:
□ Ping the controller IP from a PC on the same network
  → If unreachable: network/cable/switch issue — not HMI

□ Open browser → http://<CP1584_IP>
  → If browser shows connection refused: mapp View service not running
  → If browser shows login page: HMI is working, check credentials

□ If nothing loads on port 80, check port 443 (HTTPS):
  → Some systems force HTTPS only

□ Check if controller is in RUN mode:
  → Via Automation Studio "Online" → "Show Status"
  → Or via the physical controller status LED

□ SSH/FTP into controller and check mapp View process:
  ps aux | grep -i mapp
  # Or check the web server status
  ps aux | grep -i httpd

Symptom: HMI Shows Values But They’re Wrong/Stale

DIAGNOSIS:
1. Connect OPC UA client (UAExpert) to opc.tcp://<CP1584_IP>:4840
2. Browse to the same variables shown on the HMI
3. Compare OPC UA values with HMI displayed values
4. If OPC UA values are correct but HMI is wrong:
   → .data binding file has wrong variable mapping
   → Rebuild .data file with correct PLC variable references
5. If OPC UA values are also wrong:
   → PLC program issue, not HMI
   → See [execution-model.md](./execution-model.md) for PLC diagnostics

Symptom: Alarms Not Appearing on HMI

DIAGNOSIS:
1. Check OPC UA FX → AlarmX node → are alarms present in the namespace?
   → If yes but not showing on HMI: AlarmList widget misconfigured or page not visible
   → If no: mapp AlarmX component not running or not configured

2. Check if mapp AlarmX is in the software object list:
   → Automation Studio → Online → Software Objects
   → Look for "mpAlarmX" or "mappAlarmX" in the running components

3. Force an alarm condition:
   → Write to the alarm trigger variable via OPC UA client
   → Does it appear in the AlarmX OPC UA node?
   → Does it appear on the HMI?

Symptom: Can’t Log In / “Access Denied”

DIAGNOSIS:
1. Default credentials on many B&R systems:
   Username: administrator (or admin)
   Password: (blank or "admin" — varies by firmware)

2. If credentials are unknown and there's no documentation:
   → You will need Automation Studio to "Upload from Target" and read the
     Roles.config and Clients.config files
   → Or access the controller filesystem and read the config files directly

3. Factory reset (LAST RESORT):
   → Automation Studio → Online → Initialize Target
   → WARNING: This erases ALL configuration including PLC program

Recovering the HMI Project Without OEM Files

Step 1: Upload from Target

This is the primary recovery method for any undocumented B&R system.

Automation Studio:
1. File → New → Project from Target
2. Enter controller IP: <CP1584_IP>
3. Project name: Recovery_CP1584_<serial>
4. Select target hardware (Automation Studio will auto-detect)
5. Configure upload scope:
   ☑ Hardware configuration
   ☑ Software configuration (mapp components)
   ☑ Global variable declarations
   ☑ File system contents (this captures mapp View files)
   ☐ Source code (only compiled objects will be available)
6. Wait for upload (can take 10-30 minutes for large projects)
7. Save the recovered project as .apj

Step 2: Analyze Recovered mapp View Files

After upload, inspect the recovered project structure:

Logical/
└── mappView/
    ├── Pages/          ← .page files (XML format, human-readable)
    ├── Widgets/        ← .widget files (XML format)
    ├── Data/           ← .data files (variable bindings — CRITICAL)
    ├── Config/         ← Roles, clients, display settings
    └── Styles/         ← CSS overrides

Critical files to examine:

Step 3: Reverse-Engineer Variable Mapping

1. Open mappViewData.data
2. Map each HMI binding to the PLC variable namespace:
   "Content.Main.Motor1Speed.Value" → "Data.Global.gMotor[1].fSpeed"
   → This tells you PLC variable: Main.gMotor[1].fSpeed

3. Cross-reference with the global variable declarations:
   → Find Main.gMotor data type
   → Find ST_Motor structure definition
   → Now you know every motor parameter available

Step 4: Export for Documentation

# Convert recovered .page files to documentation:
# .page files are XML — parse them to extract:
#   - Page names (screen list)
#   - Widget types per page
#   - Variable bindings per widget
#   - Text strings (process descriptions, labels)

# Example: parse a .page file
xmllint --format Main.page | grep -E '(widget|binding|text)'

What You CANNOT Recover

Panel Replacement Procedure (CP1584 Context)

Scenario: Panel PC Failed, Need to Replace

On B&R systems, the “HMI panel” is typically one of:

1. A dedicated B&R Power Panel with built-in controller (your machine has a CP1584, which IS the controller — so the panel is likely a separate display)
2. A B&R Panel PC connected to the CP1584 via Ethernet, running mapp View in a fullscreen browser
3. A third-party display accessing mapp View via web browser

Replacing a B&R Panel PC

PREREQUISITES:
□ New panel PC with B&R Automation Runtime installed (or standard Windows/Linux)
□ IP address of the CP1584 controller
□ Network configuration (subnet, gateway)
□ Any role/client configuration needed for this panel

PROCEDURE:
1. Physically install the new panel:
   → Mount in existing cutout / VESA mount
   → Connect power
   → Connect Ethernet to the same switch as CP1584

2. Configure network on new panel:
   → Static IP on same subnet as CP1584
   → Verify ping to CP1584

3. Launch the HMI runtime:
   ┌─ If B&R Panel PC with Automation Runtime:
   │  → Automation Studio → Deployment → Deploy HMI Client
   │  → Or: the panel auto-discovers the mapp View server via mDNS
   │
   └─ If standard PC / thin client:
      → Open browser: http://<CP1584_IP>
      → Set to fullscreen (F11)
      → Bookmark for automatic startup

4. Verify all screens load correctly
5. Test alarm acknowledgment from the new panel
6. Test user login/role assignment

Reconfiguring the HMI Client on the Controller

If the new panel has a different resolution or needs a different role assignment:

# Access the Clients.config via Automation Studio or FTP:
# Edit the client entry for the new panel:

<Client>
  <Name>Panel_Line2</Name>
  <IpAddress>192.168.1.50</IpAddress>
  <DisplayResolution>1920x1080</DisplayResolution>
  <Role>Operator</Role>
  <AutoStartPage>Main</AutoStartPage>
</Client>

If There Is No Dedicated Panel (Headless Operation)

Some CP1584 machines run without any physical display — the HMI is accessed only via browser from a PC or tablet.

To verify the HMI is running on a headless machine:
1. Connect PC to same network
2. Open browser → http://<CP1584_IP>
3. If mapp View loads: HMI is running, no panel needed
4. If not: check if mapp View is enabled in the controller configuration
   → Automation Studio: mappView.config → Enabled = true
   → Also check: Configuration → mapp View → "Enable web server"

Multi-Client / Multi-User Setup

mapp View supports multiple simultaneous connections, each with independent state:

                    ┌──────────┐
                    │ CP1584   │
                    │ mapp View│
                    │ Server   │
                    └────┬─────┘
           ┌─────────────┼─────────────┐
           │             │             │
     ┌─────▼─────┐ ┌────▼──────┐ ┌────▼──────┐
     │ Operator  │ │ Engineer  │ │ Tablet    │
     │ Panel     │ │ Laptop    │ │ (remote)  │
     │ Role: Op  │ │ Role: Eng │ │ Role: View│
     └───────────┘ └───────────┘ └───────────┘

Role-Based Views

mapp View implements roles through the Roles.config file. Each role can have:

• Different available pages (Operator doesn’t see Engineering pages)
• Different widget visibility (some widgets hidden for certain roles)
• Different variable write permissions (View role = read-only)
• Different language settings

// Roles.config structure (simplified XML)
<Roles>
  <Role name="Administrator">
    <Pages>All</Pages>
    <Permission>ReadWrite</Permission>
  </Role>
  <Role name="Operator">
    <Pages>Main, Alarms, Recipe</Pages>
    <Permission>ReadWrite</Permission>
    <HiddenPages>Diagnostics, Network, System</HiddenPages>
  </Role>
  <Role name="Viewer">
    <Pages>Main, Alarms</Pages>
    <Permission>ReadOnly</Permission>
  </Role>
</Roles>

Multi-Client Data Consistency

When multiple clients are connected:

• Read operations: Each client reads independently from the OPC UA FX namespace — no conflicts
• Write operations (e.g., button press to start machine): The first write wins. Multiple clients pressing “Start” simultaneously do not cause errors — the PLC logic handles the edge detection
• Alarm acknowledgment: Acknowledgment is tracked per-alarm, not per-client. If Client A acknowledges an alarm, Client B sees it as acknowledged
• Recipe changes: mapp View handles recipe editing with a “checkout” mechanism — only one client can edit a recipe at a time

Practical Code Examples

Reading HMI Variables via OPC UA (Python)

"""
Read live HMI variables from B&R CP1584 via OPC UA.
Requires: pip install opcua-asyncio
"""
import asyncio
from asyncua import Client

CONTROLLER_IP = "192.168.1.10"
PORT = 4840
ENDPOINT = f"opc.tcp://{CONTROLLER_IP}:{PORT}"

async def read_machine_status():
    async with Client(url=ENDPOINT) as client:
        await client.connect()

        root = client.nodes.root
        objects = await root.get_child(["0:Objects"])
        data = await objects.get_child(["2:Data"])
        global_vars = await data.get_child(["2:Global"])

        machine_status = await global_vars.get_child(["2:gMachineStatus"])

        state = await machine_status.get_child(["2:sCurrentState"]).get_value()
        running = await machine_status.get_child(["2:bRunning"]).get_value()
        error = await machine_status.get_child(["2:nErrorCode"]).get_value()

        print(f"State: {state}")
        print(f"Running: {running}")
        print(f"Error Code: {error}")

        await client.disconnect()

asyncio.run(read_machine_status())

Browsing the HMI Variable Namespace (Python)

"""
Recursively browse the OPC UA FX namespace on a B&R controller
to discover all HMI-accessible variables — useful for undocumented machines.
"""
import asyncio
from asyncua import Client

async def browse_namespace(node, indent=0):
    children = await node.get_children()
    for child in children:
        name = (await child.get_browse_name()).Name
        node_id = str(child.nodeid)
        dtype = await child.get_data_type()
        try:
            value = await child.get_value()
            value_str = f" = {value}"
        except Exception:
            value_str = ""

        print("  " * indent + f"{name} [{dtype}]{value_str}  ({node_id})")
        await browse_namespace(child, indent + 1)

async def main():
    async with Client(url="opc.tcp://192.168.1.10:4840") as client:
        await client.connect()
        print("=== B&R OPC UA FX Namespace ===\n")
        objects = await client.nodes.objects.get_child(["2:Data"])
        await browse_namespace(objects)
        await client.disconnect()

asyncio.run(main())

Writing a Variable via OPC UA (Start/Stop Machine)

"""
Write a command to the PLC via OPC UA.
WARNING: Only use on a test machine or when you fully understand the system.
"""
import asyncio
from asyncua import Client

async def send_command():
    async with Client(url="opc.tcp://192.168.1.10:4840") as client:
        await client.connect()

        cmd_node = await client.nodes.objects.get_child([
            "2:Data", "2:Global", "2:gCommands", "2:bStart"
        ])

        # Edge-triggered: write TRUE, then FALSE
        await cmd_node.write_value(True)
        print("Command START sent")
        await asyncio.sleep(0.5)
        await cmd_node.write_value(False)
        print("Command START released")

        await client.disconnect()

asyncio.run(send_command())

Reading Active Alarms via OPC UA (Python)

"""
Read active alarms from mapp AlarmX via OPC UA FX namespace.
"""
import asyncio
from asyncua import Client

async def read_alarms():
    async with Client(url="opc.tcp://192.168.1.10:4840") as client:
        await client.connect()

        alarmx = await client.nodes.objects.get_child([
            "2:Data", "2:AlarmX"
        ])

        count = await (await alarmx.get_child(["2:nActiveAlarmCount"])).get_value()
        print(f"Active alarms: {count}\n")

        if count > 0:
            alarms_node = await alarmx.get_child(["2:aActiveAlarms"])
            alarms = await alarms_node.get_value()
            for i, alarm in enumerate(alarms):
                print(f"  [{i}] Code: {alarm.nCode}  "
                      f"Severity: {alarm.eSeverity}  "
                      f"Text: {alarm.sText}")

        await client.disconnect()

asyncio.run(read_alarms())

Checking mapp View Service Status

IMPORTANT: The CP1584 runs Automation Runtime (AR) on VxWorks — it does NOT provide SSH access or Linux-style process management. You cannot SSH into the controller, run ps, systemctl, or netstat commands. The correct approaches for checking mapp View status on a CP1584:

Via SDM (System Diagnostics Manager):

1. Open a web browser to http://<CP1584_IP>/SDM
2. Navigate to the Overview tab — check web server status
3. Navigate to the Task Monitor tab — look for the HTTP/WebServer task
4. Navigate to the Logger tab — check for web server errors

Via Automation Studio:

1. Connect to the controller via Online > Login
2. Open Diagnostics > Task Monitor — check HTTP server task status and cycle times
3. Open Diagnostics > System Diagnostics Manager (SDM) > Diagnostics > Software Modules

Via OPC UA:

1. Connect an OPC UA client to opc.tcp://<CP1584_IP>:4840
2. Browse to the SDM namespace for web server health indicators

Via SNMP:

snmpwalk -v1 -c public <CP1584_IP> 1.3.6.1.4.1.2706.1

See diagnostics-sdm.md for full SDM usage details.

Extracting HMI Pages from Controller via FTP

# FTP into controller (NOT SSH — CP1584 has no SSH)
ftp <CP1584_IP>

# Navigate to mapp View files on the user partition
cd F:\mappView
# or
cd F:\UserProject\mappView

# Download all HMI definition files
lcd /local/backup/
cd Pages
mget *.page
cd ../Widgets
mget *.widget
cd ../Data
mget *.data
cd ../Config
mget *.config

# .page and .widget files are XML — parseable:
# xmllint --format Main.page | head -50

NOTE: The B&R AR filesystem uses C:\ (system) and F:\ (user/application) partition notation. These are NOT Windows paths — they are VxWorks device mounts that appear as drive letters. The FTP server exposes them in this format.

Key Findings

1. mapp View is a web server inside the controller — the HMI is not a separate program. It serves HTML5/CSS3/JavaScript pages over HTTP/HTTPS from the controller itself.

2. All data flows through OPC UA FX — there is no direct PLC memory access from the HMI. Every value displayed or entered on the HMI passes through the OPC UA FX information model on port 4840.

3. HMI and control logic are fully decoupled — the PLC program has zero knowledge of the HMI. The HMI has zero knowledge of PLC program structure. This separation is enforced through the three-layer model (content, layout, logic) and the .data binding file indirection.

4. On undocumented machines, upload from target is your primary recovery tool — Automation Studio can upload the hardware config, software object list, global variables, mapp component configurations, and deployed filesystem contents. Source code cannot be recovered.

5. The .data file is the most important file — it maps every HMI element to every PLC variable. Losing it means you must reverse-engineer every variable binding by comparing what the HMI shows against what OPC UA exposes.

6. Panel replacement does not require PLC changes — because the HMI is web-based, replacing a panel is purely a network/browser configuration task. No PLC reprogramming is needed.

7. Legacy POWER WORX systems used direct memory mapping — unlike OPC UA FX, POWER WORX read/wrote PLC memory directly. If you encounter this on a CP1584, it indicates a bridged legacy display connection via the PVI library.

8. VNC is display-only — VNC mirrors what a connected Panel PC shows. It cannot be used to interact with the mapp View server directly. For full remote access, use a web browser.

9. Alarm handling is fully integrated — mapp AlarmX exposes active alarms, history, and acknowledgment status through the OPC UA FX namespace. The AlarmList widget on the HMI subscribes to this data automatically.

10. Role-based access is configured in Roles.config — without the OEM project, you may need to upload from target to discover role definitions. Default credentials vary by firmware version.

Cross-References

Document generated from reverse-engineering research on undocumented B&R CP1584 systems. All procedures should be validated on a test system before applying to production equipment.