Developers

Connected automation with setup and loop

Bring devices, process logic, and native operator screens into one maintainable application.

RuntimeNative scripting, TCP, serial, and data APIs
FirmwareDevice-specific; expansion starters planned
HardwareExamples use synthetic inputs only

JetFlight's setup/loop model also fits connected equipment beyond CNC: monitoring stations, fixtures, test stands, conveyors, and process sensors. One host can combine device adapters, local logic, records, and an operator display in a small deployable application. Several stations can exchange application data over a managed network.

The opportunity is a consistent way to build and maintain automation across a workshop, factory, or larger plant. Refineries and power plants are examples of environments with many connected processes; they are application goals, not a claim that JetFlight is a certified process-safety controller or an already commissioned plant-wide system.

A station that can run with or without a screen

An application that never calls ui.* stays headless. Add a native HMI when an operator needs a local screen without rewriting the device adapters or process model.

LayerJobMaintenance benefit
Device adapterDecode a supported serial/TCP device into named valuesReplace the sensor without rewriting every screen
Station stateKeep value, units, timestamp, and connection health togetherA disconnected device cannot masquerade as a fresh reading
Process logicHandle permitted transitions and timeoutsBehavior can be exercised with synthetic inputs
HMIShow readings, trends, alarms, and operator requestsDisplay and application use the same named state
DeploymentVersion scripts, configuration, and compatible runtimeReproduce a known installation and roll back deliberately

Example: three stations, one readable health view

This headless example uses synthetic readings only. It does not open sockets, connect to hardware, or command outputs. Station 2 deliberately stops updating after three seconds so its stale status becomes visible.

var stations = {
    station1: { value: null, seen: null },
    station2: { value: null, seen: null },
    station3: { value: null, seen: null }
};
var started = 0;
var nextSample = 0;
var nextReport = 0;

function acceptSample(id, value, now) {
    if (!Object.prototype.hasOwnProperty.call(stations, id)) return;
    if (typeof value !== 'number' || !isFinite(value)) return;
    if (value < 0 || value > 100) return;
    stations[id] = { value: value, seen: now };
}

function setup() {
    started = Date.now();
    console.log('SIMULATION: three stations; no device connections');
}

function loop() {
    var now = Date.now();
    if (now >= nextSample) {
        nextSample = now + 500;
        acceptSample('station1', 35, now);
        acceptSample('station3', 68, now);
        if (now - started < 3000) acceptSample('station2', 52, now);
    }
    if (now < nextReport) return;
    nextReport = now + 1000;

    Object.keys(stations).forEach(function(id) {
        var station = stations[id];
        var stale = station.seen === null || now - station.seen > 2000;
        console.log(id + ': ' + (stale ? 'STALE' : station.value + '%'));
    });
}

Save as main.js and run JetFlight --script ./main.js --port 49397 in a separate working directory with that port unused. Replace the synthetic producer only after validating the real device's framing, identity, units, limits, reconnect behavior, and timestamp rules. Reuse the same station state to drive labels or indicators in the native HMI.

Connect the devices the application actually needs

The runtime exposes asynchronous files and SQLite, TCP sockets, and an Arduino-style Serial API. Serial ports support data callbacks or buffered reads, and multiple ports can represent different adapters.

These are integration primitives. A USB-to-RS485 adapter does not itself implement every RS485 protocol; similarly, a CAN adapter does not automatically understand a motor or sensor. A device adapter must define the message framing, parse partial messages, bound its buffers, reject invalid samples, and report disconnection explicitly. The extension catalog distinguishes planned starters from supported combinations.

For applications spanning multiple machines, keep local responsibility explicit: each station knows its devices and what to do when communication is lost. Share measurements and requests through a defined protocol instead of assuming every remote value is always fresh. Ordinary process telemetry is distinct from the synchronized motion network.

A secure deployment is an engineered deployment

Put controllers and stations on a managed control network. Restrict access to the needed hosts and ports, and use authenticated, encrypted remote access at the network boundary. Keep secrets out of HMI packages and run applications with the privileges they actually need.

The documented raw TCP scripting API is not an authenticated or encrypted device fabric by itself. Device identity, authorization, encryption, recovery, and audit requirements must be designed and validated for the installation. Safety interlocks and certified safety functions remain independent of application scripts.

Grow without creating an unmaintainable one-off

Use a small module for each device, a shared vocabulary for units and status, versioned configuration, and fixtures for disconnected or invalid inputs. Keep setup() focused on initialization, loop() short, and event handlers specific. That makes the control understandable to the next person who has to service it.

Open-source Arduino and ESP32 peripheral starters are planned for commercially reusable expansion. A starter becomes downloadable after its source, license, interface contract, and tested instructions are ready.

Reviewed 2026-11-06. Confirm the hardware catalog and current published release before connecting a machine.