Runtime blocks are blocks in DCode that register something with the engine when run. Activation installs the Engine-managed work declared by a .dcode file: tasks, loops, calculations, task groups, events, and callback registrations.

Runtime blocks are marked by icons in the gutter, and their activation state is displayed in the menu bar, showing if they are loaded into memory or not. The icons will change color based on their state. Green indicates running, Grey indicates loaded but not running, and Yellow indicates stale/ not loaded.

Run activates the whole file. Saving an edit alone does not replace the loaded definitions. Running it again replaces its runtime definitions, including ones whose text did not change.

Activation and Replacement

Activation registers the runtime blocks declared in a file. Reactivating it applies your edits by replacing that file’s previous definitions.

Activate this file and watch its output:

loop docs_demo_copy 2:
    |docs_demo_copy_value| = |docs_demo_source|

The loop runs at a requested 2 Hz. Rename the loop and Run again: the old runtime is removed and the new one starts. Its output channel can remain because channels have a separate lifecycle.

Runtime declarations are tracked by the source file’s path. Rerunning one file does not sweep the runtime declarations owned by every other script.

Removing or renaming a declaration therefore removes its old runtime when the file is successfully activated again. Tasks use their normal task or group lifecycle controls. Loops start on activation, and calculations respond to their configured signal updates.

Editing or saving source alone does not replace the active runtime. As described in Overview, When edits are made, the script will have to be re executed to rewrite what the engine has loaded in memory.

In the photo above, the YAML that drives the templated loops has been changed, which requires the script to be ran again.

Runtime State

Replacement creates fresh task, loop, calculation, and file-global state. An unchanged loop is rebuilt too, so its once initialization can run again. A restarted task runs its start lifecycle rather than continuing its old sequence position. Channel values have a separate lifetime and can remain available to the replacement; Values and Scope explains the owners.

Starting the replacement does not grant authority: reacquire available claims with command or set in start: or beside writes. Configured channel startup values apply only at Engine startup, not script reactivation.

Accepted callback calls finish on their captured version; new calls use the replacement registration. Callbacks covers per-call scope and caller authority.

Template Activation

Templates expand into runtime declarations before activation. Each generated block belongs to the .dcode file containing the template, even when its entries come from YAML.

For example, this file creates one loop per valve:

params = yaml "./valves.yaml#valves"

template(params) loop {params.valve}_sm 10 disable_warnings:
    |valves_{params.valve}_state| = |valves_{params.valve}|

If valves.yaml contains valve_1 through valve_5, activation creates five loops. Deleting valve_5 from YAML leaves the old loop active until the consuming script is rerun. Successful activation then stops the previous five loops and creates four. valve_5_sm is no longer registered, and the other four loops have fresh runtime state.

The YAML editor’s Run button saves the YAML and reruns the scripts that use it. Each consuming script activates separately, replacing all of its runtime definitions.

Cleanup and Retained Data

Tasks, loops, calculations, events, callbacks, and task groups follow the shared removal and cleanup rules. Runtime removal retains channels and their stored data.

Runtime replacement is not a general cleanup of obsolete RAPID channels. Application channels such as valves_valve_5, valves_valve_5_open, and valves_valve_5_state can remain after the valve’s loop is removed. Loop diagnostic channels can remain too. After a while, this can leave behind a lot of orphaned channels. See how to preform a Channel Cleanup in Node, Context, and Project Board.

ARGUS event history also remains. Removing an event declaration disables its DCode handler; it does not erase the event’s recorded history or existing board record.

Activation Errors and Limits

Parsing and compilation happen before the old runtime is replaced. A failure in those stages leaves the previous runtime installed. With the Lua backend, the old version also remains active while the new file prelude initializes; a prelude failure leaves it installed, although initialization may already have performed channel writes or other actions.

Once replacement begins, a later activation failure is not guaranteed to restore the previous runtime. Check the activation result before assuming the edited version is running.

A running timeline must be held before hot reload. Native C++ currently requires at least one runtime block, so removing its last declaration and pressing Run does not clear the previous runtime through an empty activation. See Native C++ Execution for backend limits.

Reference

• Runtime blocks — Declarations and their lifecycle.
• Callbacks — Registration and calls during replacement.
• Timelines — Clock holds and recovery when reactivating a timeline.