DARTWIC brings data acquisition, controls, and an operator interface together. You can connect sensors and equipment, write the logic that operates them, and build diagrams that show what is happening while you run a test.

It began with rocket testing, where changing a sensor or valve often meant changing several different tools and hardware, which takes a lot of time. The aim is to keep the useful parts of a control system together so the next person can understand and extend it without starting over, and providing the tools to iterate very quickly.

Engine and Interface

To use DARTWIC, you work with two main processes: an Engine and an Interface. The Engine gathers data, runs your control logic, and records what happens. The Interface is where you configure and operate the system, view data, and send commands.

Keeping them separate allows multiple operators and other applications to connect to the same Engine. Closing an Interface does not by itself stop the Engine or its tasks. You can use a desktop Interface, or open a webserver Interface in your browser.

Imagine a small test stand with a pressure sensor and a valve. A driver connects the equipment to the Engine and publishes the pressure as a channel: a named value that the rest of the system can read.

You can put that pressure on a graph, show it beside the valve on a schematic, or use it in a DCode script. DCode is DARTWIC’s automation language. A script might convert the sensor reading into engineering units, fill a tank to a target pressure, or run a sequence of steps. These use the same channels that the operator sees.

A workspace is the folder that keeps your projects and shared resources together. Each project holds a setup’s scripts, tasks, device configuration, and schematics. For example, you could keep separate projects for test stand A and test stand B in the same workspace. An instance holds the local configuration that tells an Engine installation which workspace and project to open, along with its local settings and runtime data.

During a run, channel history, events, and logs help explain what happened. You can review a time range and export the measurements alongside the events from that run. Read more at Configuration and Storage.

Engine subsystems

The Engine uses a few subsystems that you will see mentioned throughout these docs:

A device module receives a measurement and writes it to RAPID. Inline calculations and dependent event conditions react during that write, so your sensor scaling’s and aborts are evaluated on write. Separate workers send telemetry and record samples. The Interface receives those updates for the operator to view, in for example, a graph.

You can then view all channel data alongside events, logs, and labeled time ranges named DataFrames. Everything in the range can be exported with one click.

Example workspace

The example workspace includes a simulated test stand with sensors, valves, a fill-and-ignition sequence, and faults you can inject. Its repository contains setup instructions and walkthroughs. Start there to see the pieces working together, then follow an exercise to change a calculation or controller.

For a guided setup, First Session walks through installing an Interface, starting a local Engine or connecting to an existing one, and setting up your first workspace. You do not need to write a hardware driver to begin.

DCode, plugins, and clients

Start with an existing driver and configure a project. When you need something custom, where you put your code depends on what it needs to do:

A plugin is an installed package that extends DARTWIC. They can be installed directly from the interface, adding device drivers, new task types, and much more to your workspace.

A module is an instance created by an Engine plugin, such as a connection to one device. Behind them are explicit C++ Objects you can configure and manage. The main use case is for writing device drivers, such as network communicators, and DAQ or control devices. However, you can code whatever you want, camera feeds, voice IP comms, radio links, etc.

A task is a unit of work you can start and stop. One driver plugin can provide several module instances and task types, plus Interface panels for configuring them. The Plugins and Clients guides explain these extension options.

If your system spans several computers, TEMPEST Peer connects named nodes and makes their channels, logs, and events available together with explicit commanding. You can view network traffic, and send telemetry or commands (called operations in TEMPEST), from a registry list, or send something custom.

Most things in DARTWIC can be augmented through Interface and Engine plugins. If there is something you want supported, please leave feedback.

Tracking a Workspace in GitHub explains how to share the whole workspace, including its projects and shared resources, between machines and with your team.

Updates

Updates are published on GitHub Releases, with release notes and downloadable packages. You can also browse the release history. The Engine and Interface have separate versions and can be updated independently; Compatibility, Licensing, and Tiers explains their compatibility requirements.

Visit the DARTWIC Downloads page for the latest Engine, Interface, and client releases.

Updating the Interface and Engine

Open the version menu by clicking the Interface version number, or open Settings → General. Choose Check for updates in the version menu to refresh the available releases.

Select a release in the Interface or Engine version selector. The document icon beside a release opens its notes.

You can then click the download/update action and review the confirmation and any compatibility messages.

Confirm Download and Install for the Interface or Download and Restart for the Engine. DARTWIC downloads and verifies the package before applying it.

Save your work and finish time-sensitive operations before updating an Engine: the restart interrupts its running tasks and connections. Updating a connected Engine or Webserver Interface requires administrator access. Read any installation-lock or retry message if another instance is using the same Engine installation.

Update Files

Updates are stored on the computer hosting the component being updated, separately from portable workspace content.

A disconnected local Engine update can use a temporary preparation instance instead. The resulting Engine software is installed into its Engine folder; workspace files and instance recordings remain separate from the managed software. Configuration and Storage explains those folders.

Documentation, Bugs and Feedback

Open the Interface’s version menu or General settings for Docs, Report a bug, and Give feedback.

Reports open an editable GitHub issue draft with known Interface and Engine versions. Describe what you did, what you expected, and what happened; review the draft for private information before submitting. A GitHub account is required.