Software overview
The whole path from import through processing and preview to emitted machine output.
Controller support
One internal motion program, emitted into the controller you actually run
The core holds the geometry once, in an internal representation with no dialect in it, and each adapter emits that program against the rules of the controller it is talking to. Power scaling alone is four quantisations of the same physical intent, and the scale is read off the machine's own registers at connect time rather than assumed. The desktop application and the industrial marking layer run on the same controller-aware core, written in Nelson, and the figures on this page are from that core.
- GRBL, Marlin, Smoothieware and Generic G-code, each emitted against its own dialect rules, with Ruida running through an external bridge at alpha
- Power scaling as four quantisations of one physical intent: an internal 0 to 10000 range mapped onto the GRBL $30 value read live off the controller at connect time, the Marlin 0 to 255 integer, Smoothieware 0 to 1.0 at four decimal places, and Generic 0 to 1000
- A golden fixture suite holds emitted machine output stable across three dialects, 42 fixtures across two images and seven processing variants, with a conformance validator checking every emitted program against that dialect's rules
One program, several dialects, each emitted against its own rules
Controllers differ in the command they use to turn the beam on, the scale they read power on, the precision they accept, whether they execute arcs, the vocabulary they report status in, and how they want to be fed.
How the emission path is built
The geometry is held once, in an internal motion program with no dialect in it. Each adapter turns that program into the output its controller executes, so a curve becomes an arc command where the controller carries arcs and a run of segments where it does not, and a power value becomes whatever integer or fraction that firmware reads. Adding a controller means writing an adapter and a fixture set, which is why controller reach grows without the geometry engine being reopened.
- One internal, dialect-neutral motion program, emitted into GRBL, Marlin, Smoothieware and Generic, each with its own laser-on command, travel strategy, power scale, precision, arc availability, status vocabulary and streaming discipline
- Power scaling as four quantisations of the same physical intent: an internal 0 to 10000 range mapped onto the GRBL $30 value read live off the controller at connect time, the Marlin 0 to 255 integer, Smoothieware 0 to 1.0 at four decimal places, and Generic 0 to 1000
- Travel moves on GRBL are emitted as G1 F rapid with S0 rather than G0, because GRBL rejects a G0 carrying an F parameter. The adapter applies it, so error 20 never reaches the operator
- Arc commands go only to the dialects that execute them, and the named paths are auto-detected at connect so the adapter is chosen by the machine rather than by the user
- Machine profiles hold setup, defaults and behaviour against the actual device, so switching machines carries the context with it instead of rebuilding it
Explore more
Feature system
The heat map preview, material testing, templates and repeat workflows that sit on top of the same core.
What each path is emitted as
Every row is the same internal motion program, quantised and streamed the way that controller expects it.
| Controller path | Power model | Curves | Streaming and status |
|---|---|---|---|
| GRBL | Dynamic power, an inline power value on every move, internal 0 to 10000 scaled onto the $30 value read off the controller at connect time | G2 and G3 arc commands, with the Experimental arc fitting pass available on top | Character-counting streaming against the 128 byte receive buffer, auto-detected at connect |
| Marlin | Constant power, quantised onto the 0 to 255 integer the firmware reads | Emitted as straight line segments, matching what the firmware executes | Send and wait, one command confirmed before the next goes out, auto-detected at connect |
| Smoothieware | Constant power, 0 to 1.0 at four decimal places | G2 and G3 arc commands | Send and wait, auto-detected at connect |
| Generic or custom G-code | Constant power, 0 to 1000 | Emitted as straight line segments | Basic send, selected manually for machines outside the named dialects |
| Ruida | Driven through an external bridge rather than emitted from the core | Handled by the bridge | Alpha. Validate the path on your own machine and job set before it carries production work |
Constant power is not a constant result
A head decelerating into a corner deposits more energy per millimetre than a head at cruise. That is what burns corners, and it is an energy problem rather than a power setting.
So the controlled quantity is energy per millimetre. The firmware modulates power against actual velocity and the generator emits an inline power value on every move. The core reads the machine's own $30 and $31 registers at connect time and scales every emitted value to that machine's real range, then queries $110 and $111 to derive and validate the effective maximum feed rate. On the dialects that run constant power, the same physical intent is emitted as constant power against the scale that firmware reads.
The software asks the machine what it can do rather than assuming a category average. A power number that means one thing on one board and something else on the next is how a setting that worked last week ruins the part in front of you.
Stopping a laser is easy. Bringing it back to a known coordinate frame afterwards is the engineering
Character-counting streaming tracks bytes in flight against the controller's 128 byte receive buffer and keeps it full, rather than waiting for an acknowledgement per line. Controllers that run better on a strict handshake fall back to send and wait, with three retries on a 3, 8 then 12 second escalation ladder. Preflight primes absolute mode, issues a no-op move and probes laser mode before the job starts.
The stop system has three levels: an emergency stop issuing feed hold, power zero, laser off and the soft reset byte; a soft stop; and a recovery sequence that soft resets, flushes buffers, drains the controller boot chatter, verifies status, clears alarms and restores the user origin. That recovery runs back through the same dialect adapter that emitted the job, so status is verified and alarms are cleared in the words that particular controller answers in, and one board is never left sitting in alarm because another board's reset sequence was assumed.
On a floor the question is never whether the emergency stop works. It is what the operator does in the next two minutes, and whether the origin survived.
What holds emitted output stable between releases
The question a production user rarely gets to ask any laser software: what happens to my parts when this updates.
- A golden fixture suite holds emitted machine output stable across three dialects, 42 fixtures across two images and seven processing variants, with a conformance validator checking every emitted program against that dialect's rules
- A change to the geometry engine cannot silently change what a machine does, because the fixtures are compared byte for byte and a difference has to be reviewed and accepted deliberately
- Exactly one package may import the desktop framework runtime. Code generation, serial communication, controller adapters and power mapping, project and material persistence, licensing, image handling and export are pure Go, unit testable without a window opening
- The boundary is held by a purity guardrail in continuous integration rather than by a style guide. The engine does not know a window exists, and a build fails if anyone tries to teach it
- The alignment framing pass is emitted in constant power mode and clamped to a maximum of 10 percent, so a preview pass leaves the workpiece as it found it
- Updates are fetched from a signed version manifest and every download is verified against a published SHA-256 checksum before installation
Arc fitting: five conditions hold at once before a segment run becomes an arc
One worked example of dialect-aware output: turning a run of short straight segments back into a curve, on the path that executes arc commands.
Status: Experimental
Arc fitting is labelled Experimental in the application and it is labelled Experimental here. It fits consecutive straight segments to circular arcs by Kasa algebraic least squares, solved through a 3 by 3 Cramer's rule determinant, and emits the result as G2 or G3 so a curve runs as one arc command instead of many short lines. It is enabled on GRBL, the dialect that carries arc commands and dynamic power together.
- Five conditions have to hold simultaneously before a segment run is fitted: at least 8 segments, radial error under 0.08 mm, radius deviation under 1.5 percent, a sweep of at least 15 degrees, and consecutive segments within 0.12 mm
- Full circles are split into two semicircles and arcs over 180 degrees are split in half before emission
- The result on suitable GRBL jobs is a smaller emitted program and fewer decelerations through a curve, which is what a scalloped edge on a radius is made of
- Experimental is the status label, so it is an option a user turns on for a job rather than a default the geometry engine applies to every one
Related pages
Feature overview
Where controller-aware output sits against previews, processing, templates, testing and repeat workflows.
Ask about a controller
Send the controller, the firmware version and a job you run, and you get a straight read on the emission path.
Profiles hold the machine context, so a setting is recovered rather than rediscovered
Machine profiles and custom profiles keep setup, defaults and behaviour attached to the actual device. Switching between machines carries that context with it, and a repeat job starts from the settings that produced the last good part.
Estimate calibration tunes timing estimates against the behaviour of your own machine, factoring in repeat passes and the feed rates the controller reports, so a planned job length reflects the device in the room. On repeat and production work that compounds fast, because a schedule built on a guessed average is a schedule that slips quietly.
Written parameters are how a good result survives the person who found it. The same discipline runs on the industrial side of the core, where marking parameters and machine profiles for every material and mark type are saved on the system and written down as part of the handover pack.
Ruida support status
Confirmed
- Ruida runs through an external bridge rather than through a core adapter, and it is labelled alpha in the application and here
- It is an active development path, and its coverage is stated per release
- The alpha label stays on it until the fixture set and the conformance validator cover it the way the emitted dialects are covered
Not confirmed
- Validate the Ruida path against your own machine, your own firmware version and the jobs you actually run before it carries production work
- Read alpha as the status label it is, rather than as parity with the GRBL, Marlin, Smoothieware and Generic paths
Engineering questions about controller support, answered with the constants
Which controller paths does the core emit into?
GRBL, Marlin, Smoothieware and Generic or custom G-code, all emitted from one internal, dialect-neutral motion program against each dialect's own rules, with auto-detection at connect on the named paths. Ruida runs through an external bridge and is labelled alpha.
Why does GRBL get dynamic power and arcs where Marlin gets constant power?
Because that is what each firmware executes. GRBL laser mode adjusts power against actual velocity and runs G2 and G3 arc commands. Marlin runs constant power and straight line segments. The adapter emits to the real capability of the controller in front of it, quantised onto that firmware's own scale: an internal 0 to 10000 range onto the GRBL $30 value read at connect time, and onto the Marlin 0 to 255 integer.
What happens to my output when the software updates?
The golden fixture suite holds emitted machine output stable across three dialects, 42 fixtures across two images and seven processing variants, and a conformance validator checks every emitted program against that dialect's rules, so a change to the geometry engine has to be reviewed and accepted before it reaches a machine. Updates themselves are fetched from a signed version manifest and verified against a published SHA-256 checksum before installation.
What do machine profiles hold?
Setup, defaults and behaviour tied to the actual device, plus the calibrated timing behaviour of that machine. Switching machines carries the context with it, and a setting that produced a good part is recovered rather than rediscovered.
What is the status of arc fitting?
Experimental, and labelled Experimental in the application. It is enabled on GRBL and it fits consecutive segments to circular arcs by Kasa algebraic least squares through a 3 by 3 Cramer's rule determinant, gated on five conditions holding at once: at least 8 segments, radial error under 0.08 mm, radius deviation under 1.5 percent, a sweep of at least 15 degrees, and consecutive segments within 0.12 mm.
Is Ruida at the same status as the other paths?
Ruida is at alpha and runs through an external bridge, while GRBL, Marlin, Smoothieware and Generic are emitted directly from the core against their own dialect rules and held by the golden fixture suite. Validate the Ruida path on your own machine and jobs before it carries production work.
Is this the same core that runs the industrial marking lines?
Yes. The desktop application and the industrial marking layer run on the same controller-aware core, written in Nelson, and the figures on this page are from that core. The industrial layer adds the composition and integration work a marking line needs, and it drives the same emission, streaming and recovery path underneath.
Run it against your own controller
Download the current build and connect the machine. The core auto-detects the named dialects, reads the controller's own registers at connect time, and scales every emitted value to that machine's real range before a single move goes out. The 14 day trial is started and signed in inside the application.
Last updated August 21, 2026