Online Changes and Runtime Patching on B&R Automation

A comprehensive guide to modifying running PLC programs on B&R (ABB) Automation platforms using Automation Studio, covering safe production techniques, limitations, and best practices.

Table of Contents

1. Modifying a Running PLC Program Without Stopping the Machine
2. Online Force/Override Techniques in Automation Studio
3. Changing Setpoints, Timers, and Parameters at Runtime
4. Saving Modified Programs Back to the CF Card for Persistence
5. Online Change Limitations: What Can/Cannot Be Changed Online
6. Hot-Connecting: Adding/Removing Hardware at Runtime
7. Using PVI/OPC-UA to Write Variables on a Running PLC
8. Runtime Parameter Modification from HMI
9. Online Monitoring and Cross-Reference
10. Rollback Procedures if an Online Change Causes Problems
11. Change Management for Safety-Critical Systems
12. Using mapp View for Runtime Parameter Changes

1. Modifying a Running PLC Program Without Stopping the Machine

Online Program Modification Overview

B&R Automation Studio supports downloading modified program code to a running controller without requiring a full machine stop. This is one of B&R’s key production-engineering capabilities, allowing engineers to push bug fixes, logic adjustments, and parameter tuning to machines in active production.

How Online Download Works

Automation Studio communicates with the target controller over Ethernet (or USB). When you trigger a download to a running system, Automation Studio evaluates whether the change requires only an online change (hot swap of code/data in memory) or a warm restart (reinitialization of variables and tasks). The download dialog indicates this with a red exclamation mark when a warm restart is needed.

Key mechanism:

• Automation Runtime (AR) keeps track of the memory layout of all tasks, programs, and libraries.
• When new code is downloaded, AR patches the in-memory binary of affected programs without stopping the cyclic tasks that are not impacted.
• Tasks that are impacted may be briefly suspended, reloaded, and resumed.

When Online Download is Possible

Online download (no restart) is possible when:

• Only program logic within existing function blocks or programs changes.
• Constant values (e.g., timer presets, setpoints declared as VAR CONSTANT) are modified.
• Internal variable initial values change, but the variable’s data type and scope remain the same.
• The AR version is >= G4.33 (transfer configuration options were significantly improved starting from this version).

Prerequisites

1. The project in Automation Studio must match the installed configuration on the PLC (same hardware tree, same task structure).
2. The controller must be in RUN or SERVICE mode.
3. An online connection must be established via the Online Settings dialog (configured under Tools > Options > Online Settings or via the project’s Logical View > Controller > Online Settings).
4. Ensure the correct PVI line (TCP) is configured pointing to the controller’s IP address.

Download Procedure

1. Make the desired code changes in Automation Studio.
2. Compile the project (F7). Resolve any compilation errors.
3. Open the Transfer to Target dialog (Application > Transfer to Target or the toolbar icon).
4. Select the target controller and check the transfer options:
   • Transfer Configuration: Available from AR >= G4.33, this lets you configure whether a change requires a warm restart, an INIT cycle, or if it can be applied fully online.
5. Look for the red exclamation mark (!) in the download window. If present, Automation Studio is warning that a warm restart will occur.
6. Click Transfer to begin the download.

Risks and Caveats

Online download to a running system carries risks, primarily page faults (memory access violations) that can crash the controller. Key risk areas identified by the B&R community:

• Pointer-based code: If code uses pointers to absolute memory addresses, those addresses may shift when new code is loaded, causing invalid memory access.
• Global variables shared across tasks: If a global variable is written by one cyclic task and read by another with different cycle times, an online change that shifts the variable’s memory location can cause corrupted reads.
• Library changes: Downloading after modifying a library without a full rebuild is risky. Always perform a Rebuild All before downloading to a running system.
• String manipulation: String concatenation and buffer operations can overflow if buffers were resized or relocated during the transfer.
• Communication cleanup: Protocols like OPC UA clients must be correctly handled in the task’s EXIT routine to prevent orphaned connections during online code replacement.

Mitigation Strategies

• Use the IECCheck library in your project. It provides runtime checks for pointer access, division by zero, array bounds violations, and other common errors, stopping the PLC gracefully before a page fault can cause uncontrolled behavior.
• Refresh pointers every cycle or protect shared data with semaphores (B&R provides the AsSem library for this purpose).
• Avoid writing to the same global variable from multiple tasks without synchronization.
• Always perform a full Rebuild All (not just Build) before downloading to a running system, especially when library changes are involved.

Remote Online Downloads

Online downloads can be performed remotely over a VPN or plant network. The procedure is identical; the only difference is that the PVI line configuration must reference the controller’s remote IP address. Ensure network latency is acceptable (preferably < 50 ms) to avoid transfer timeouts.

2. Online Force/Override Techniques in Automation Studio

Force/Override Techniques Overview

Forcing (also called overriding) is the technique of overriding the logical value of a variable in the PLC, regardless of what the program logic computes. This is essential for troubleshooting, testing, and temporarily overriding sensor states or outputs without changing the program code.

Forcing in the LAD Monitor

Automation Studio’s Ladder (LAD) Monitor provides a built-in force function:

1. Open the LAD Monitor for the program you want to debug (Online > LAD Monitor).
2. Locate the variable you want to force (e.g., a digital input contact).
3. Right-click the variable and select Force.
4. Set the forced value (TRUE/FALSE for booleans, numeric values for integers/reals).
5. The variable will now hold the forced value regardless of the program logic driving it.

The forced state is visually indicated in the LAD diagram — forced contacts and coils are typically shown in a distinct color or with a force icon overlay.

Forcing in the Watch Window

The Watch Window is the primary tool for forcing variables in B&R:

1. Open the Watch Window (Online > Watch Window).
2. Add variables by dragging them from the program editor or typing variable names.
3. Each variable row shows:
   • PV Value: The current process value (what the PLC logic computed).
   • ForceActivated: A checkbox to enable/disable forcing for this variable.
   • ForceActivated Value: The value to force the variable to.
4. To force a variable:
   • Check the Force On checkbox (or right-click and select “Force On”).
   • Enter the desired value in the ForceActivated Value column.
   • The variable will now be overridden.
5. To release the force, right-click and select Force Off, or use Force All Off to release all forced variables at once.

Important: The “Force On” button is context-sensitive. If a variable is already forced, the button appears greyed out and only “Force Off” and “Force All Off” are active.

Prerequisites for Forcing

• The project in Automation Studio must match the program installed on the target PLC. If there is a mismatch, the PV Value column shows an error indicator (warning triangle), and forcing may not work correctly. Perform a Transfer to Target to synchronize the project before attempting to force.
• An active online connection to the controller must be established.

Programmatic Forcing via AsIO Library

B&R provides the AsIO library for enabling/disabling forcing from within PLC code itself:

This is useful for automated testing scenarios where you need to programmatically override inputs/outputs.

Forcing via PVI (External Applications)

External applications can interact with the force mechanism through PVI’s link nodes (via the ANSL variable object). The Python PVI wrapper (Pvi.py) supports writing to force values using the 'F+' syntax:

var = Variable(task, "AF_AI[6].ModuleOk")
var.value = True  # writes to force value via 'F+' syntax

Limitations of PVI forcing:

• You can write the force value and read the force status via POBJ_ACC_STATUS.
• You cannot enable/disable forcing status itself through PVI writes — forcing must be activated either through Automation Studio or the AsIOEnableForcing function block.

Safety Considerations for Forcing

• Always document forced variables. B&R’s watch window shows forced variables, but if the online connection is lost, there may be no visible indication on the HMI.
• Never leave forces active on a production machine after troubleshooting. Use “Force All Off” before disconnecting.
• Forcing outputs can cause unexpected machine motion. Always follow your plant’s lockout/tagout (LOTO) procedures when working on active machinery.
• Forcing on safety I/O is restricted by the SafeLOGIC safety controller. Standard forcing does not affect safety-rated signals.

3. Changing Setpoints, Timers, and Parameters at Runtime

Runtime Parameter Changes Overview

Runtime parameter modification is the most common and safest form of online change. Unlike code modifications (which carry page-fault risk), changing the values of variables at runtime simply writes new data to the controller’s memory without altering the executable code.

Methods for Runtime Parameter Changes

Method 1: Watch Window (Engineering Tool)

The simplest method, available directly in Automation Studio:

1. Establish an online connection to the PLC.
2. Open the Watch Window.
3. Add the setpoint, timer preset, or parameter variable.
4. Double-click the PV Value column and enter the new value.
5. Press Enter to write the value to the PLC.

This is a temporary change — the value will revert to its initialized value after a warm/cold restart unless persisted (see Section 4).

Method 2: Programmatic (Internal PLC Logic)

Parameters can be changed by PLC logic itself, for example:

(* Change a timer preset based on a recipe selection *)
IF gRecipeSelect = 10 THEN
    tonCycleDelay.PT := T#5s;
ELSIF gRecipeSelect = 20 THEN
    tonCycleDelay.PT := T#8s;
END_IF

(* Change a temperature setpoint *)
rTempSetpoint := rOperatorSetpoint + rCalibrationOffset;

This is the preferred method for production systems, as the logic is deterministic, traceable, and version-controlled.

Method 3: ArConfig (Runtime Configuration Parameters)

For system-level parameters (IP address, hostname, subnet mask), B&R provides the AsARCfg library:

(* Example: Change IP address at runtime *)
IF IPSet THEN
    CfgSetIPAddr_1.enable := 1;
    CfgSetIPAddr_1.pDevice := ADR(pDevice);
    CfgSetIPAddr_1.pIPAddr := ADR(NewIPTemp);
    CfgSetIPAddr_1();

    IF CfgSetIPAddr_1.status = 0 THEN
        (* Read back to confirm *)
        CfgGetIPAddr_1.enable := 1;
        CfgGetIPAddr_1.pDevice := ADR(pDevice);
        CfgGetIPAddr_1.pIPAddr := ADR(NewIP);
        CfgGetIPAddr_1.Len := 20;
        CfgGetIPAddr_1();
    END_IF

    IF CfgGetIPAddr_1.status = 0 AND CfgSetIPAddr_1.status = 0 THEN
        IPSet := FALSE;
        CfgGetIPAddr_1.enable := 0;
        CfgSetIPAddr_1.enable := 0;
    END_IF
END_IF

The AsARCfg library also provides functions for:

• CfgGetSubnetMask / CfgSetSubnetMask
• CfgGetHostName / CfgSetHostName
• And many more configuration parameters

Method 4: Persistent Variable Initialization

Variables can be initialized from files or recipes loaded at startup:

(* Load parameters from a configuration file *)
fbFileOpen(
    enable := TRUE,
    pDevice := ADR('CF'),
    pFileName := ADR('config/setpoints.csv'),
    mode := fmRead
);

This approach ensures parameters survive power cycles and are managed as data files rather than hardcoded values.

Timer Modification Specifics

B&R timers (TON, TOF, TP from the IEC_Timers library) have:

• PT (Preset Time): Can be changed at runtime simply by writing to timerName.PT.
• IN: The trigger input, also writable at runtime.
• ET (Elapsed Time): Read-only (computed by the timer block).
• Q: The output, also writable at runtime (though forcing is the preferred override method).

When you change PT while the timer is running, the new preset takes effect immediately. If PT is shortened below the current elapsed time, the timer may or may not expire immediately depending on the timer type and implementation.

Best Practices

• Centralize parameters in a dedicated data structure (e.g., ST_MachineConfig) to make runtime tuning systematic and auditable.
• Validate all operator-entered setpoints with range checks before applying them.
• Log parameter changes to a data file or the AR event log for traceability.
• Use the mapp Recipe framework for managing sets of parameters that change together (e.g., product changeovers).

4. Saving Modified Programs Back to the CF Card for Persistence

The Persistence Problem

When you make changes to a running PLC via the watch window, force, or online download, those changes exist only in the controller’s volatile DRAM. After a power cycle or warm restart, all non-persisted values revert to their initialized state. To make changes permanent, you must write them back to the CF card (CompactFlash) or CFast card.

Method 1: Transfer to Target (Full Program Persistence)

The standard way to persist program changes is through the Transfer to Target operation:

1. Compile the project with the desired changes.
2. Transfer to Target (Application > Transfer to Target).
3. Automation Studio writes the new program to the controller’s non-volatile storage (CF/CFast card or internal flash).

After transfer, the program will survive power cycles. The controller boots from the non-volatile storage on each startup.

Method 2: Save/Upload from PLC to CF Card

When you modify variables online (via watch window) and want those values to persist:

1. In the Logical View, right-click the controller and select Save or use the Transfer > Upload from Target option.
2. Automation Studio reads the current state of all process variables and writes them to the project.
3. You then transfer the updated project back to the target.

Caveat: Simply changing a variable via the watch window does NOT automatically save it to the CF card. The B&R community has reported issues where a CF card stops functioning after variable changes via the watch window — this is typically caused by the project getting out of sync with the installed configuration.

Method 3: CF Card Image Backup (Binary Level)

For complete persistence and backup, use the Runtime Utility Center:

1. Open Runtime Utility Center (installed with Automation Studio).
2. Connect to the target controller.
3. Navigate to CF Card Tools.
4. Select Create Image to create a binary image of the entire CF card.
5. Save the image file to your PC (.img format).

To restore:

1. Insert a blank CF card into your PC’s card reader.
2. In Runtime Utility Center, select CF Card Tools > Restore Image.
3. Select the saved image file and write it to the blank card.

This method captures:

• The complete Automation Runtime installation.
• All user programs and configurations.
• All persistent data (recipes, logs, parameter files).
• The AR configuration (IP settings, hostname, etc.).

Method 4: Offline Installation (AS Compile to CF)

Automation Studio can compile and write a project directly to a CF card without a running controller:

1. Connect a CF card reader to the engineering PC.
2. Insert the target CF card.
3. In Automation Studio, use Application > Transfer > Install CF/SD Card (Offline Install).
4. Select the CF card drive letter and the target partition.
5. Automation Studio formats the card, installs AR if needed, and writes the compiled program.

Method 5: Persistent Data Files

For parameter data that changes frequently, store it in files on the CF card:

(* Save current parameters to file *)
fbFileWrite(
    enable := bSaveTrigger,
    pDevice := ADR('CF'),
    pFileName := ADR('config/params.dat'),
    data := ADR(stCurrentParams),
    datalen := SIZEOF(stCurrentParams)
);

This approach separates program code from operational data, allowing frequent parameter updates without recompiling.

Recommended Backup Strategy

1. Before any online change: Create a CF card image backup using Runtime Utility Center.
2. After confirming the change works: Transfer the updated project to the target to persist the code changes.
3. Periodically: Upload PVs (process variables) using Runtime Utility Center to capture the current state of all runtime values.
4. For critical machines: Keep a spare CF card with a known-good image at the machine site for rapid recovery.

5. Online Change Limitations: What Can/Cannot Be Changed Online

Changes That CAN Be Made Online (No Restart)

Changes That REQUIRE a Warm Restart

Changes That REQUIRE a Cold Restart (Power Cycle)

Detecting What Requires a Restart

Automation Studio provides visual indicators:

1. Transfer Configuration Dialog (AR >= G4.33): Before downloading, Automation Studio analyzes the differences between the installed and compiled code and indicates which changes will require a restart.
2. Red Exclamation Mark: In the download dialog, a red ! icon warns that a warm restart is required. The controller will briefly leave RUN mode and execute INIT cycles for affected tasks before resuming.
3. No Warning: If no warning is displayed, the change can be applied purely online without any task interruption.

Structural vs. Non-Structural Changes

The distinction between structural and non-structural changes is critical:

• Non-structural changes (logic within existing functions, constant values, initial values) can typically be applied online.
• Structural changes (new data types, new tasks, hardware tree changes, library upgrades) require a warm or cold restart because they alter the memory layout that AR uses to manage running tasks.

Guidelines by Scenario

6. Hot-Connecting: Adding/Removing Hardware at Runtime

Hot-Connecting Overview

B&R’s Automation Runtime supports hot-connecting — the ability to add or remove I/O modules from the X20 bus while the controller is running. This is primarily facilitated through the mappIO service and the AsIO library.

Enabling/Disabling Hardware Modules at Runtime with mappIO

The mappIO mapp service provides a high-level interface for modifying the hardware configuration at runtime:

1. Configure all possible hardware modules in the Automation Studio hardware tree (include optional modules even if they are not physically installed).
2. Instantiate the mappIO component in your project.
3. Use the mappIO API to enable or disable specific modules based on runtime conditions:

(* Enable a specific I/O module based on a machine configuration *)
MappIO.EnableModule(
    moduleIdent := 'X20DO9321',
    slot := 3,
    enable := bModuleRequired
);

Use Cases:

• Machines with optional equipment where modules are installed for some configurations but not others.
• Module replacement during operation (e.g., swapping a failed analog input module).
• Configuration-driven machines where the hardware setup depends on a recipe or model selection.

AsIO Library for Hardware Configuration

For lower-level control, the AsIO library allows creating and removing hardware configurations programmatically:

The AsIO approach was the traditional method before mappIO became available. It is more flexible but less user-friendly than mappIO.

X20 Bus Module Hot-Swap Behavior

The X20 bus system has specific hot-swap characteristics:

• Bus modules (X20BM01, X20BM11, etc.) are the backbone of the X20 I/O system. They provide the X2X backplane connection between modules.
• I/O modules can typically be inserted or removed while the bus is powered, provided the bus module supports hot-swap and the software configuration accounts for the change.
• When a module is physically removed, the AR runtime detects the absence and sets the module’s ModuleOk flag to FALSE. The mappIO service can then handle the diagnostic and optionally reconfigure the system.
• When a module is inserted, AR detects the new hardware and initializes it. If the module matches the configured hardware tree, it becomes operational automatically. If it does not match, a diagnostic alarm is generated.

Practical Example: Optional Machine Configurations

(* Configuration 1: Standard machine *)
IF iConfig = 1 THEN
    (* Enable standard I/O, disable optional modules *)
    MappIO.SetModuleState('AI_Option', MODULE_DISABLED);
    MappIO.SetModuleState('AO_Option', MODULE_DISABLED);
END_IF

(* Configuration 2: Machine with optional sensor package *)
IF iConfig = 2 THEN
    (* Enable optional modules *)
    MappIO.SetModuleState('AI_Option', MODULE_ENABLED);
    MappIO.SetModuleState('AO_Option', MODULE_ENABLED);
END_IF

Limitations

• CPU modules cannot be hot-swapped — they are the core of the system.
• Bus modules that are in the middle of the rack chain (between two other modules) cannot be removed without breaking the X2X connection for downstream modules.
• Power supply modules obviously cannot be removed while the system is running.
• Hot-swap behavior depends on the specific module type — check the module’s datasheet for hot-swap support.
• For safety-rated modules (SafeLOGIC, SafeI/O), hot-swap is handled differently and must comply with safety standards (see Section 11).

7. Using PVI/OPC-UA to Write Variables on a Running PLC

PVI — Process Visualization Interface

PVI is B&R’s native communication middleware for accessing process variables. It abstracts the physical connection (Ethernet, USB, serial) behind a uniform API.

PVI Architecture

Configuring a PVI Line

PVI is configured via the PVI Lines tree in Automation Studio or standalone PVI Manager:

[TCP]
Driver    = TCPIP
StationA  = PC_Main
StationB  = PLC_01
IP_StationB = 192.168.10.50
Port_StationB = 11160

Default PVI TCP port: 11160. Modern controllers (AR >= B4.0) also expose OPC UA on port 4840.

Writing Variables via PVI (Python Example)

Using the Pvi.py wrapper (available at github.com/hilch/Pvi.py):

from pvi import *

# Connect to the PLC
line = Line()
line.connect("TCP", "PLC_01")

# Access a task
task = Task(line, "Task1")

# Write a setpoint variable
temp_setpoint = Variable(task, "gRecipe.rTemperatureSetpoint")
temp_setpoint.value = 85.5

# Write a boolean
pump_enable = Variable(task, "gMachine.bPumpEnable")
pump_enable.value = True

PVI Forcing

PVI supports writing to the force value of a variable using the 'F+' syntax:

var = Variable(task, "AF_AI[6].ModuleOk")
var.value = True  # Writes to force value

## Read the force status
status = var.read_status(POBJ_ACC_STATUS)

Limitation: PVI cannot change the force activation status itself — only Automation Studio or the AsIOEnableForcing function block can enable/disable forcing.

OPC UA — Standardized Access

OPC UA is the recommended communication method for new projects. It is supported natively on B&R controllers running AR >= 4.0.

Enabling OPC UA on the Controller

1. In Automation Studio, open the Logical View > Controller > Configuration.
2. Navigate to OPC UA settings.
3. Enable the OPC UA Server.
4. Configure:
   • Endpoint URL: opc.tcp://<controller-ip>:4840
   • Security Policy: None, Basic128Rsa15, Basic256, Basic256Sha256
   • Max Sessions: Default 50, adjustable for SCADA fan-out
   • Publishing Interval: Default 100 ms (minimum practical: 50 ms)
5. Mark variables as OPC UA accessible: In the variable properties dialog, enable the OPC UA accessibility flag.
6. Recompile and download.

Writing Variables via OPC UA (Python Example)

import asyncio
from asyncua import Client

async def write_setpoint():
    url = "opc.tcp://192.168.10.50:4840"
    async with Client(url=url) as client:
        setpoint_node = client.get_node("ns=2;s=Task1.gRecipe.rTemperatureSetpoint")
        await setpoint_node.write_value(85.5)
        print("Setpoint written successfully")

asyncio.run(write_setpoint())

OPC UA Parameters

PVI vs OPC UA Decision Guide

Rule of thumb: Use OPC UA for new projects. Use PVI when integrating with B&R HMI panels or legacy systems.

Performance Considerations

Server CPU load scales approximately as:

ServerLoad ≈ N_variables × (1000 / Sampling_ms) × Payload_bytes

For 500 variables at 100 ms sampling with 8-byte payloads on an X20CP3584:

• CPU consumption: ~0.3-0.8 ms per 100 variables per cycle
• Bandwidth: ~40 KB/s (negligible on 100 Mbit Ethernet)

8. Runtime Parameter Modification from HMI

HMI Parameter Modification Overview

HMI-based parameter modification is the most operator-friendly method for runtime changes. B&R provides several HMI technologies, with mapp View being the current standard.

Architecture

The typical parameter modification chain is:

Operator → HMI Screen (mapp View) → OPC UA → PLC Variable → Machine Logic

mapp View communicates with the PLC via OPC UA internally. When an operator enters a new value in an HMI widget, the value is written through OPC UA to the corresponding PLC variable.

Designing HMI Screens for Parameter Changes

Input Widgets

mapp View provides several widgets for parameter input:

Binding Variables to Widgets

In mapp View, widgets are bound to PLC variables through the Content property:

1. In the mapp View page editor, select the widget.
2. In the Properties panel, set the Content to reference the PLC variable (e.g., MainTask.gMachine.rSpeedSetpoint).
3. Configure input constraints:
   • Minimum/Maximum: Numeric range limits.
   • Format: Decimal places, unit display.
   • Access Level: Restrict modification to authorized operators.

Implementing Access Levels

B&R provides the mapp User service for managing operator access:

(* In PLC code: define access levels *)
VAR_GLOBAL CONSTANT
    ACCESS_LEVEL_OPERATOR   : UINT := 10;
    ACCESS_LEVEL_SUPERVISOR : UINT := 20;
    ACCESS_LEVEL_ENGINEER  : UINT := 50;
END_VAR

In mapp View, bind the widget’s Access Level property to the user’s current access level. When the user’s access level is insufficient, the widget is displayed as read-only.

Validation and Confirmation

For critical parameter changes, implement validation in the PLC:

FUNCTION fbSetSpeedSetpoint : BOOL
VAR_INPUT
    rNewSpeed : REAL;
    rMinSpeed : REAL;
    rMaxSpeed : REAL;
    bConfirm  : BOOL;
END_VAR

IF bConfirm THEN
    IF rNewSpeed >= rMinSpeed AND rNewSpeed <= rMaxSpeed THEN
        gMachine.rSpeedSetpoint := rNewSpeed;
        fbSetSpeedSetpoint := TRUE;
    ELSE
        (* Log error, reject change *)
        fbSetSpeedSetpoint := FALSE;
    END_IF
END_IF

Feedback to the Operator

Always provide visual feedback when a parameter is changed:

• Status indicators (green checkmark for success, red X for error).
• Current value display alongside the input field.
• Audit log visible to operators showing who changed what and when.

9. Online Monitoring and Cross-Reference

Online Monitoring Tools

Watch Window

The Watch Window (Online > Watch Window) is the primary monitoring tool:

• Displays real-time values of selected variables.
• Shows variable type, scope (global/local), and current value.
• Supports forcing (see Section 2).
• Can display values in different formats (decimal, hex, binary, float).

LAD Monitor

The LAD Monitor (Online > LAD Monitor) provides graphical monitoring of ladder logic:

• Shows real-time power flow through contacts and coils.
• Displays the current value of each variable in the rung.
• Supports forcing directly in the ladder diagram.
• Color-coded indicators show TRUE/FALSE states.

Trace (Oscilloscope)

The Trace tool (Online > Trace) is a digital oscilloscope for PLC variables:

• Record up to 4 channels of data simultaneously.
• Configure trigger conditions (rising edge, falling edge, value threshold).
• Variable time base from microseconds to hours.
• Export data to CSV for analysis.
• Essential for debugging timing-sensitive issues.

Scope View

The Scope provides real-time graphical display of variables over time, similar to an analog oscilloscope, but in a live view without recording.

I/O Monitoring

The I/O Monitor (Online > I/O Status) shows the state of all physical I/O points:

• Digital inputs and outputs with status LEDs.
• Analog input/output values with engineering units.
• Module status (ModuleOk, diagnostics).
• Bus module communication status.

Cross-Reference Tools

Go to Definition / Go to Reference

In the Automation Studio code editor:

• F12 (or right-click > Go to Definition): Jumps to where a variable is declared.
• Shift+F12 (or right-click > Show References): Shows all locations where the variable is used (read or written).

Cross-Reference View

The Cross-Reference window (View > Cross-Reference) provides a comprehensive list:

• All variables in the project with their usage locations.
• Filterable by read/write reference type.
• Shows which task/program accesses each variable.
• Essential for understanding the impact of a variable change before making an online modification.

Online Cross-Reference

When connected online, the cross-reference information is enriched with runtime data:

• Actual memory addresses of variables.
• Current values (via Watch Window integration).
• Task cycle time impact assessment.

Using Cross-Reference for Safe Online Changes

Before making an online change:

1. Identify the variable you want to change using Cross-Reference.
2. Check all read locations: Will any code behavior change unexpectedly if the value changes?
3. Check all write locations: Will another task overwrite your change? Are there race conditions?
4. Check for forcing: Is the variable currently forced? If so, your change will be overridden.
5. Check task assignments: Which tasks access this variable? Different task cycle times can cause race conditions when modifying shared data.

10. Rollback Procedures if an Online Change Causes Problems

Immediate Response: Force All Off

If an online change causes unexpected behavior:

1. Immediately click Force All Off in the Watch Window to release all forced values.
2. If the problem was caused by a forced value, releasing it should restore normal operation.

Recovery via Online Download (Rollback Code)

If the problem is in the code itself:

1. Revert the code changes in Automation Studio (use version control — Git, SVN, etc.).
2. Recompile the project.
3. Download to the running controller using Transfer to Target.
4. If the download requires a warm restart, the controller will briefly execute INIT cycles before resuming RUN mode.

Recovery via Warm Restart

If the controller is in an inconsistent state:

1. In Automation Studio, switch the controller to SERVICE mode:
   • Online > Set Mode > SERVICE
2. This stops all cyclic tasks and initializes variables.
3. Fix the code, recompile, and download.
4. Switch back to RUN mode: Online > Set Mode > RUN

Recovery via CF Card Swap (Cold Restart)

If the controller is unresponsive or in a fault state:

1. Power off the controller.
2. Replace the CF card with a known-good backup (created with Runtime Utility Center).
3. Power on the controller.
4. The controller boots from the known-good CF card with the previous working program.

Recovery via AR System Reset

If the controller is in SERVICE mode and will not start:

1. Place the PLC into BOOT mode (via the hardware mode switch or by deleting the system partition).
2. Connect via Automation Studio.
3. Delete partitions using the HDD/CF Utility.
4. Cycle power.
5. Reinstall AR and the program from scratch (Offline Install to CF card).

Preventive Measures

CF Card Backup Procedure (Detailed)

1. Connect to the PLC via Runtime Utility Center.
2. Navigate to Tools > Back up files from Compact Flash / Image file.
3. Select Create Image to create a complete binary backup.
4. Save to a PC with a meaningful filename (e.g., MachineA_backup_2026-07-10.img).
5. Store the backup in a versioned directory alongside the source code.

Restore Procedure (Detailed)

1. Insert a blank CF card into the PC card reader.
2. Open Runtime Utility Center.
3. Navigate to CF Card Tools > Restore Image.
4. Select the backup image file.
5. Write the image to the CF card.
6. Install the CF card in the PLC and power on.

11. Change Management for Safety-Critical Systems

Safety-Critical Change Management Overview

Modifying safety-related PLC programs requires strict adherence to IEC 61508, ISO 13849, and other applicable functional safety standards. B&R’s safety platform (SafeLOGIC, SafeI/O, openSAFETY) has specific rules for runtime modifications.

B&R Safety Architecture

B&R safety technology is built on:

• SafeLOGIC controllers: Dedicated safety PLCs (e.g., X20SL81xx, X20(c)SL81xx).
• SafeI/O modules: Safety-rated input/output modules.
• openSAFETY: B&R’s open safety protocol over POWERLINK or other fieldbuses.
• Safety+: B&R’s next-generation safety software framework with an open, digitally fingerprint-protected code base.

Rules for Online Changes to Safety Programs

1. Standard forcing does NOT affect safety I/O. The forcing mechanism in Automation Studio applies only to standard (non-safety) process variables. Safety-rated inputs and outputs are protected by the SafeLOGIC hardware and cannot be overridden through standard force functions.

2. Safety program changes require re-certification. Any modification to safety-related logic (programs running in the SafeLOGIC task) invalidates the current safety certification. The machine must undergo:

   • Risk re-assessment
   • Re-verification of safety functions
   • Updated safety documentation
   • Sign-off by a competent safety engineer

3. Safety tasks are isolated. Safety programs run in a dedicated task with higher priority and are protected from interference by standard tasks. Online changes to standard tasks do not affect safety task execution.

4. OPC UA must not expose safety variables. When configuring OPC UA on a controller that also runs safety programs, the OPC UA address space must be filtered to exclude variables in the safety task. Exposing safety variables to external systems violates IEC 62443 security requirements.

Management of Change (MoC) Procedure

For safety-critical systems, follow a formal Management of Change process:

1. Request: Document the proposed change, including justification and scope.
2. Risk Assessment: Evaluate the impact on safety functions. Identify any new hazards introduced by the change.
3. Review: Have the change reviewed by a safety engineer and the machine builder’s quality team.
4. Approval: Obtain sign-off from all relevant stakeholders (safety, engineering, production management).
5. Implementation: Apply the change using a controlled procedure:
   • Create a CF card backup before the change.
   • Test in simulation first (ARsim).
   • Apply the change during a planned downtime window.
   • Verify all safety functions after the change.
6. Verification: Test all affected safety functions (E-stop, light curtains, guard interlocks, etc.) to confirm they operate correctly.
7. Documentation: Update all safety documentation, including:
   • Safety requirements specification
   • Safety validation report
   • Operating manual
   • Maintenance procedures
8. Release: Only after successful verification, return the machine to production.

Best Practices for Safety-Related Online Work

• Never make online changes to safety programs while the machine is running. Always stop the machine, apply lockout/tagout, and work in a controlled environment.
• Use Safety+ for safety development where possible. It provides an open code base with digital fingerprinting that protects safety-critical code while enabling collaborative development.
• Separate safety and standard logic. Keep safety functions in dedicated SafeLOGIC programs, not mixed with standard machine control logic.
• Maintain a safety change log. Every modification to safety-related code must be recorded with date, description, who performed it, and verification results.
• Keep safety backups separate. Store CF card images of safety-related configurations with restricted access and formal version control.

Safety+ Considerations

B&R’s Safety+ framework introduces modern safety development practices:

• Open code base: Safety functions can be developed with third-party tools, enabling better collaboration and flexibility.
• Digital fingerprint: Protects the integrity of safety-critical code, ensuring unauthorized modifications are detected.
• Headless architecture: Supports CLI interaction for automated safety validation.
• Automatic safety configuration updates: Reduces maintenance effort and ensures consistency across machine variants.

12. Using mapp View for Runtime Parameter Changes

mapp View Runtime Changes Overview

mapp View is B&R’s HMI framework built on web technology (HTML5, CSS, JavaScript). It communicates with the PLC through OPC UA and provides a powerful, modern interface for operators to modify runtime parameters.

Setting Up mapp View for Parameter Changes

Step 1: Add mapp View to the Project

1. In Automation Studio’s Logical View, right-click the controller.
2. Select Add > mapp Component > mapp View.
3. Configure the mapp View settings (web server port, default page, etc.).

Step 2: Create an OPC UA Variable Mapping

1. In the Logical View, expand the OpcUa node under the controller.
2. An OPC UA default view file is automatically added.
3. Mark variables as OPC UA tags by checking the OPC UA accessible property in the variable’s properties dialog.

Step 3: Design the HMI Page

1. Open the mapp View page editor.
2. Create a new page or open an existing one.
3. Add widgets from the widget palette for each parameter you want to expose:

+------------------------------------------+
|  Temperature Control                      |
|                                           |
|  Setpoint: [  85.5  ] °C                 |
|            ^^^^^^^^                       |
|       NumericInput widget                 |
|       bound to gTemp.rSetpoint           |
|                                           |
|  Actual:    82.3 °C                        |
|  Status:    HEATING                       |
|                                           |
|  [Apply]  [Reset to Default]              |
+------------------------------------------+

Step 4: Bind Widgets to PLC Variables

For each widget:

1. Select the widget.
2. In the Properties panel, set the Content property to the PLC variable path (e.g., MainTask.gMachine.rSpeedSetpoint).
3. Configure constraints:
   • Minimum/Maximum: Prevent out-of-range entries.
   • Step size: Define increment granularity for the widget.
   • Unit: Display engineering units.
   • Decimal places: Set display precision.

mapp Recipe for Parameter Groups

For managing groups of parameters that change together (e.g., product changeovers), use the mapp Recipe framework:

1. Add the mapp Recipe component to your project.
2. Define recipe structures in your PLC code:

TYPE ST_Recipe :
STRUCT
    rTemperature    : REAL;
    rSpeed          : REAL;
    rPressure       : REAL;
    iDwellTime      : TIME;
    bEnableOption   : BOOL;
END_STRUCT
END_TYPE

3. Link recipe variables to mapp Recipe component.
4. In mapp View, add recipe management widgets:
   • RecipeSelector: Choose a recipe by name.
   • RecipeEditor: Edit individual parameters within a recipe.
   • RecipeSave/Load: Store or recall recipe data.

Changing Setpoints Through mapp View (Complete Example)

PLC Side:

PROGRAM Main
VAR
    rTemperatureSetpoint : REAL := 25.0;
    rTemperatureActual   : REAL;
    bHeaterEnabled       : BOOL;

    (* mapp View widget status *)
    bSetpointChanged     : BOOL;
    bApplySetpoint       : BOOL;
END_VAR

(* Apply new setpoint when operator confirms *)
IF bApplySetpoint THEN
    IF rTemperatureSetpoint >= 0.0 AND rTemperatureSetpoint <= 200.0 THEN
        (* Valid range — accept the change *)
        bSetpointChanged := TRUE;
        bApplySetpoint := FALSE;
    ELSE
        (* Invalid — reject and notify *)
        bSetpointChanged := FALSE;
        bApplySetpoint := FALSE;
    END_IF
END_IF

(* Temperature control logic *)
IF rTemperatureActual < rTemperatureSetpoint THEN
    bHeaterEnabled := TRUE;
ELSE
    bHeaterEnabled := FALSE;
END_IF

mapp View Side (Widget Configuration):

Dynamic Page Content

mapp View supports dynamic page changes at runtime:

• Use NavigationButton widgets to switch between pages.
• Pages can be selected programmatically through a PLC variable bound to the navigation widget’s content.
• This enables context-sensitive displays (e.g., showing different parameter pages based on the selected machine mode or recipe).

Advanced: Runtime Image Positioning

While mapp View is designed for static widget layouts, dynamic visual changes can be achieved through:

• Visibility toggling: Show/hide widgets based on PLC variables.
• Color changes: Bind fill/stroke colors to status variables.
• Value formatting: Display different text based on ranges.
• Page switching: Load completely different pages for different operating modes.

For truly dynamic positioning (e.g., moving an image based on a variable), additional JavaScript can be used in the page’s client-side scripts, though this is an advanced technique that goes beyond standard mapp View practice.

Performance Tips

• Limit widget count per page: Each widget adds OPC UA subscription overhead. Keep pages under ~100 active widgets for optimal performance.
• Use polling vs. subscription: For slowly changing parameters, use a longer sampling interval to reduce controller CPU load.
• Optimize update rates: Set the refresh rate of each widget appropriately. Status indicators need 100-500 ms, while trend displays can use 1-5 seconds.
• Test with real data: Use ARsim to test the HMI with realistic data volumes before deploying to the target hardware.

Appendix A: Quick Reference Card

Online Change Decision Matrix

Key B&R Libraries for Runtime Operations

Key Automation Studio Shortcuts

Appendix B: References and Sources

• B&R Community Forum: https://community.br-automation.com
• B&R Coding Guidelines (TM231TRE.001): B&R Download Portal
• B&R Automation Studio Online Help (built into AS)
• B&R Safety Technology: https://www.br-automation.com/en-us/technologies/safety-technology/
• B&R mapp View Documentation: https://www.br-automation.com/en-us/products/software/mapp-technology/mapp-view/
• PVI.py Python Wrapper: https://github.com/hilch/Pvi.py
• Awesome B&R Frameworks: https://github.com/hilch/awesome-B-R
• mapp Recipe Tutorial: Available on B&R GitHub training repository
• DMC B&R Communication Reference: DMC Blog

Key Findings

1. Online download to a running B&R controller requires AR >= G4.33 for transfer configuration options. Automation Studio indicates whether a change needs a warm restart (red exclamation mark) or can be applied fully online. Always perform Rebuild All (Ctrl+F7, not just Build/F7) before downloading to a running system, especially when library changes are involved.

2. The primary risk of online code changes is page faults from shifted memory addresses. Pointer-based code, global variables shared across tasks with different cycle times, and string buffer operations are the highest-risk areas. Use the IECCheck library for runtime bounds checking and AsSem for semaphore-protected access to shared variables.

3. Variable forcing is available through three mechanisms: Automation Studio Watch Window (right-click variable, set Force On/Off), the AsIO library (AsIOEnableForcing/AsIODisableForcing function blocks for programmatic control), and PVI external writes using the F+ syntax. PVI can write force values but cannot enable/disable forcing itself.

4. Runtime parameter changes (setpoints, timers, configuration) are safest when done via PLC logic (deterministic, traceable, version-controlled), AsARCfg library (for IP/hostname/subnet changes), mapp Recipe (for parameter groups), or mapp View HMI with access level controls (mapp User service). Watch Window changes are temporary and revert after restart unless persisted.

5. Hot-connecting IO hardware at runtime is supported by B&R via the mappIO library and the AsIO library’s hot-connect function blocks. The IO processor automatically detects newly inserted/removed modules. This requires AR >= G4.0 and proper module initialization in the hardware tree configuration.

6. Safety program logic cannot be changed online – any safety modification requires a full machine stop, safety program re-download, and recertification. The SafeLOGIC safety controller’s forcing mechanisms are separate from standard IO forcing and require SafeDESIGNER software plus password.

7. OPC UA (port 4840) is the recommended communication method for new projects for external variable access, with certificate-based security and up to 50 sessions at 100 ms publishing interval. PVI (port 11160, ANSL protocol) remains necessary for B&R HMI panels and legacy systems. PVI does not auto-reconnect – implement retry logic for error code 11020.

8. Rollback procedure: (a) stop all forced variables with Force All Off, (b) download the last known-good version via Transfer to Target, (c) if a warm restart occurs, verify all tasks have re-entered RUN state, (d) if problems persist, perform a cold restart (power cycle) to restore from the CF card image. The CF card image is updated only when explicitly transferred with Application > Generate CF/SD Card (F9).

Cross-References

Document compiled from B&R official documentation, B&R Community Forum discussions, Automation Studio online help, and field engineering best practices. Always consult the official B&R documentation for your specific Automation Runtime version and controller model.