DARTWIC 2.0.0

Overview

DARTWIC 2.0 expands the platform from a single-node acquisition and control workspace into a system for distributed operation, more capable automation, and recorded evidence of what happened.

DARTWIC stands for Data Acquisition for Rocket Testing With Integrated Controls. It started as a way to collect data from rocket tests and operate the equipment around them. The same tools can connect sensors, run control logic, command devices, build operator displays, and review a test afterward. Channels give measurements and commands a shared name across the engine, automation, interface, and external software.

I started work on 2.0 in April 2026. Roughly six months later, this release brings together two major subsystem additions—TEMPEST peer networking and ARGUS—and substantial reworks of RAPID, CAESAR, DCode, and the tools around them. Where 1.0 concentrated on making one node useful and reliable, 2.0 focuses on letting a project grow across devices, procedures, and connected nodes, while being the most optimized with the most carefully designed backend yet.

What shaped 2.0

A lot of this release went into the behavior underneath the interface and engine:

• Control comes first. Prepare repeated work ahead of execution and keep recording, telemetry, and other background services from holding up control for disk or network delivery. All control backends limit global locks and runtime allocation to allow for more deterministic timing and faster more reliable control. Every single action is also designed around when it is executed, synchronous or asynchronous. Need a immediate response? Use a channel calculation or a event DCode block.
• Authority belongs to the engine. Make it clear who controls a channel, how an override takes effect, and when control is released. Those rules are applied across DCode, plugins, operators, and remote requests.
• Operators need evidence. Show source timestamps, command origin, task timing, recording pressure, and failures. An accepted command and a confirmed equipment response are different things. It is easier than ever to find what created or controlled a channel.
• Extensions should reuse the platform. Give device drivers, custom interfaces, and external applications access to the same underlying services through documented SDKs and clients.
• Keep the workflow understandable. Make timing, ownership, and outcomes explicit so authors and operators can follow what their system is doing.

Major additions and reworks

TEMPEST: connected engines and custom nodes

TEMPEST grows beyond the client messaging layer in 1.0 into a peer system for connecting DARTWIC engines and custom applications. Nodes can share RAPID channels, ARGUS events, and supported log streams, and route commands to the engine that owns the resource.

A remote channel keeps its node identity, such as TEST_STAND:tank_pressure, throughout searches, schematics, DCode, and client requests. Remote observations retain their source timestamps and availability; receiving a value does not transfer control authority to the receiving node. Custom peer types and transports let native applications or embedded-system integrations participate alongside engine-to-engine connections.

The Network Map provides a place to configure and inspect those connections. See TEMPEST Peers for setup and examples.

ARGUS: events, logs, and history

The old alarming system has grown into ARGUS, a dedicated subsystem for events, logs, and their recorded history. A condition now has a named identity, source context, related channels, firing intervals, and operator actions that can be followed over time.

Repeated reports can belong to one continuing occurrence, while a later recurrence remains part of that event’s history. Acknowledgement, resolution, silencing, prompts, and holds have distinct meanings. DCode can declare event conditions and reactions alongside its control logic, including explicit overrides when a condition fires and releases when it clears.

The event board, chronological logs, recorded channel graphs, and dataframe views bring that evidence together for investigation. Recording runs independently of client delivery, with diagnostics for backlog and loss. ARGUS Events explains the operator workflow.

CAESAR and DCode: a fuller automation system

Automation expands from periodic and worker tasks into state machines, sequences, timelines, and ordered task groups. A project can describe a procedure, wait for a condition, advance through states, or coordinate a read → control → write cycle without maintaining separate custom scheduling code.

The custom programming language, DCode, was created to allow writing easy automation sequences and scripts inside DARTWIC. It comes with a full code editor built into the interface, providing docstrings, syntax checking, autofill and code suggestions.

DCode also adds a native C++ execution backend for supported code, alongside Lua. Templates and configuration tables let one definition generate calculations, tasks, and events for many device instances. Plugin functions use a shared argument/result schema across both backends. The editor adds runtime visibility and navigation to help connect authored code with the tasks and channels it creates.

Task lifecycle and channel authority are more explicit: starting a task does not automatically take control, holding it retains its authority, and completed stop releases the channels it controls. Timing diagnostics distinguish observed rate, late releases, missed releases, failed cycles, and callbacks that are still active.

See Tasks, Templates and Configuration, and Native C++ Execution.

RAPID: reworked access, authority, and recording

RAPID now supports fixed channel storage and prepared handles for known repeated numeric work, alongside dynamic channels. Channel access and execution paths have been reworked to remove global framework locks from ordinary hot execution and keep necessary synchronization local to the affected resource.

An accepted channel write takes effect when that line executes. Configured synchronous calculations and reactions run in that call chain; outputs are not held until the task ends. Explicit claim, command, override, set, and free operations make authority intent visible, while ordinary writes follow the authority already in place.

Recording has its own asynchronous path, including prepared producer buffers for supported native execution and a configurable all-channel baseline, enabled by default at one second. Saved dataframes select time ranges from recorded history, so operators can review measurements alongside related events and logs.

The channel searcher has also been reworked to show everything about a channel: connected channel calcs, what created it, what is currently controlling it, and what ARGUS events/ overrides it may be tied to.

You can also view channels based on their runtime owner, like which task or module (device) they come from.

Workspaces, integrations, and operator tools

The desktop workflow now supports discovering local workspaces, preparing their engine instances, installing missing declared plugins, and starting or stopping their engines. Multiple workspace instances can share an engine installation while keeping their configuration separate.

Huge overhauls were added everywhere around the interface. Including bug fixes, style changes, and schematic node improvements, among some of them.

The interface brings peer connections, ARGUS history, task progress, and engine diagnostics into the operator workspace. Diagnostics focus on measured timing, stalled work, recording/storage pressure, and missing expected peer data, with context for investigating the cause.

The interface also exposes ways to view your connected engines and TEMPEST peers network activity, as well as specific events and logs. The telemetry resource now allows you to view logs and events along with channel data. You can also name ranges of time and connect metadata such as channel names to organize certain events and tests. These are called DataFrames, and its channels, events, and logs can be exported in one package for analysis.

Engine and Interface SDKs have been expanded for device tasks, DCode bindings, and reusable interface components. Python, Node.js, React, and C++ clients support tools outside the supplied interface. The release also includes updated Modbus TCP, LabJack T7, and EtherCAT integrations, example projects, coordinated compatibility metadata, and Windows/Linux packaging support.

Performance and the real-time path

The prepared path combines native C++ DCode → CAESAR execution → fixed RAPID channels. Code, channel bindings, identities, and buffers are prepared before execution. Supported repeated framework dispatch and direct prepared numeric operations reuse storage without routine framework heap allocation or global framework locks. Recording and telemetry are handed off separately.

This is a specific execution boundary. Necessary channel-local synchronization still applies. Inline calculations and reactions contribute to the caller’s duration; plugin code, device I/O, general host functions, and intentional waits have their own costs. Hard deadline compliance still needs qualification on the actual operating system, drivers, hardware, and workload. The Deterministic Automation guide explains how to build and measure that path.

The latest combined workload

The October stress-test report describes a workload with simulated devices, read/control/write tasks, input calculations, synchronous warning reactions, command overrides, and recording enabled together.

The larger run used 150 simulated devices, 1,500 I/O channels within a 1,800-fixed-channel engine layout, 450 tasks across 32 task groups, 750 native input calculations, and 150 synchronous warning events. Device write callbacks checked that normal control could not overwrite an active event override.

For the 150-device run, the history check examined 1,776,547 points, finding no invalid inputs or outputs, timestamp reversals, waveform gaps, or output mismatches. RAPID recording and ARGUS event/log persistence reported zero measured loss or write errors. The bracketing task-counter window also recorded 93,336 missed task releases, with zero failed cycles. The smaller run recorded missed releases too; neither result establishes a guaranteed 10 ms deadline.

These runs used an Intel Core i7-9700K at 3.60 GHz, eight logical processors, 32 GB RAM, standard Windows build 26100, and a Clang Release engine. They ran headless with client queries. Physical device/bus timing, interface rendering, and long-duration behavior were outside these measurements.

Isolated throughput

Separate RAPID tests across 10,000 channels and eight threads, with recording disabled, measured 30.31 million reads/s and 16.74 million writes/s using dynamic names, and 165.75 million reads/s and 25.70 million writes/s using fixed handles. Reads and writes were tested separately. So you can totally use more channels and modules if you don’t rip 100 Hz tasks, and use something lighter like 50-10 Hz instead.

A separately configured prepared-recorder test accepted about 5 million rows/s for one minute, with all rows committed and indexed after drain and zero loss, using 131,072-row producer buffers. Other high-rate or longer trials encountered backlog or loss. These results describe individual configurations; a complete control workload pays for calculations, authority, events, scheduling, recording, and device work together.

Upgrade notes

Since this is the first public release, this applies to closed versions, such as those that have had access to 1.0. Treat this release as a major-version upgrade. Back up your workspace and use the matching 2.0 Engine, Interface, SDKs, clients, and compatible plugins listed below. Rebuild native plugins against the current SDK rather than assuming a 1.0 binary remains compatible.

DCode did not exist in 1.0, so you will have to rewrite your Python automation scripts in DCode. Schematics also changed quite a bit, so those will have to be rebuilt. Channel fields were also added/ removed, so you will pretty much have to just restart your project.

In Progress Features

2.0 Introduced some a lot of new features and backend architecture. I have spent a lot of time going through the engine and interface smashing bugs, as much as I want to say everything is 100% bulletproof, I imagine some bugs will show up.

Particularly, some of the newer features might give some issues. Interface viewers, project actions, and timelines might have some nuances, but I believe I have tested them quite well. If you find something that is unintuitive, or something is just straight up broken, please use the bug report button in the interface version selector at the top right of the interface, and report it!

Try it with your own system

2.0 gives DARTWIC more room to grow from one test stand into a connected control system, while keeping channels, automation, operator displays, and recorded evidence in one workflow. Much of the work went into making that behavior clear enough to inspect and build on.

Start with the example workspace, try a procedure with simulated devices, and then connect your own hardware or tools.

Also take a look at the plugins that I try to keep maintained with DARTWIC, the Modbus, Labjack, and Ethercat plugins. The Ethercat plugin have been tested with simulators, and the Modbus and Labjack plugins have been tested with actual hardware. If you find any bugs with these please reach out!

DARTWIC plugins are open source so you can fork the repository and make any changes u need as well.

Good luck, and as always, be sure to test your setup on your own hardware before running any critical operations!