Overview

DARTWIC brings hardware data, automation, and operator tools into one system. Use it to connect a device or simulator, watch its signals, run control logic, and review what happened afterward.

The engine represents signals as channels: named values with timestamps, units, recording settings, and control authority. A driver can publish a pressure measurement, DCode can calculate a derived value or react to a limit, and an operator can see both on a schematic. Each works with the same engine state.

An explicit abort reaction

DCode can make an interlock action visible and reviewable. In this abbreviated example, an ARGUS abort condition takes automatic control of a fuel valve only while the temperature condition is active; the free statements explicitly return authority afterward:

event engine_temperature_abort:
    title: "Engine temperature limit exceeded"
    type: abort

    trigger:
        return |engine_temperature_voted| > |engine_temp_abort_limit|

    on_firing:
        if value == 1:
            override |engine_fuel_valve| = 0
        if value == 0:
            free |engine_fuel_valve|

    on_event:
        if value == 0:
            free |engine_fuel_valve|

Automatic overrides supersede ordinary automation but not an operator manual override. See DCode events and commanding and control for the full behavior and validation responsibilities.

What is included

Start your first session to connect and inspect a channel. For the architecture and where your own code belongs, see DARTWIC Ecosystem.

To version your project and run it on another engine, follow Tracking a Project in GitHub.

A note on responsible use

Built for real work, maintained by one person

DARTWIC has supported many rocket-engine tests and static fires, and it is a capable tool. It is also a solo hobby project, not a company product with a support team or a guarantee that every use case has been anticipated. AI tools are part of its development, and mistakes are possible. Independently test every driver, automation, interlock, command path, and procedure before relying on DARTWIC for your system. You are responsible for the hardware and operation you put it in charge of. Read the full note on Downloads.

From signal to operation

A typical setup starts with an engine plugin that reads a device. Its module publishes channels such as tank_pressure. A schematic puts those values beside controls and diagrams. DCode supplies automation, while ARGUS events explain conditions that need attention. Recorded channels can be reviewed in the Telemetry Exporter.

DARTWIC Share extends that workspace across nodes. Node-qualified references keep a remote signal distinguishable from a local signal with the same name.

When does logic run?

Channel calculations and dependency-driven DCode event conditions run synchronously in the engine’s channel-update path. Periodic tasks and state machines run on scheduled loops. Interface telemetry, recording, and network sharing are asynchronous.

That distinction matters when designing a response to a signal: an inline calculation does not wait for the next task tick, but a physical response still depends on acquisition timing, driver behavior, transport, and hardware. Execution and Timing explains these boundaries and the diagnostics to check.