Software overview
See how machine-aware setup fits into the wider workflow from import to preview to output.
Controller support
Machine-aware software, not a generic sender
Light Lane is built around real machine context. It remembers setup, respects controller differences, and helps generate output that matches the machine actually being used.
- Supports GRBL, Marlin, Smoothieware, and generic or custom G-code workflows
- Ruida support available in alpha
- Built around saved setup, repeatability, and controller-aware output
Built around real machine setups
Light Lane is designed to work with real machine context, not a generic idea of a laser.
Different controllers behave differently. Different machines expect different output patterns, setup assumptions, and workflow decisions. A serious engraving product should reflect that reality instead of flattening everything into one vague “send job” flow.
That is why Light Lane is built to remember setup, respect controller differences, and help create output that matches the machine actually being used.
What machine-aware workflow means in practice
The point is not just to support more controller names. The point is to get the most out of each path.
Why this matters
Light Lane focuses on what each controller is actually capable of and how the workflow should adapt around that. That includes remembering setup, generating controller-aware output, keeping machine-specific defaults, and tuning estimates and behaviour around the actual device so the result is cleaner, more repeatable, and more accurate.
- Machine Profiles and Custom Profiles keep machine context, saved defaults, and setup consistency tied to the actual device
- Controller-Aware Output Path keeps generation and output logic aligned with the selected machine or controller
- Estimate Calibration helps timing estimates reflect how the real machine behaves instead of relying on guessed averages
- Machine switching becomes cleaner because setup and behaviour stay attached to the profile instead of being rebuilt every time
- The software aims to get the best result from each controller path, not just claim broad compatibility
Explore more
Feature system
Look at related features like previews, material testing, repeat workflows, and templates.
Supported controller paths
Light Lane is built around several real controller and output workflows, with support handled according to what each path can actually do well.
- GRBL support for GRBL-based workflows, including controller-aware generation and an experimental arc fitting mode for smoother arcs where appropriate
- Marlin support for Marlin-based machine workflows
- Smoothieware support for Smoothieware-based setups
- Generic or custom G-code support for machines that fit a broader G-code workflow
- Ruida support in alpha for users evaluating that path carefully
If your controller path already looks right, move straight to the app
Download the current build when you are ready to validate Light Lane on your own machine, then start a free trial in the portal and sign in inside the app.
Profiles and saved setup
Repeated setup is one of the most annoying taxes in laser work.
Machine Profiles and Custom Profiles exist so users can keep machine context, defaults, and setup consistency tied to the actual device. That makes switching cleaner, repeating easier, and normal day-to-day work less fragile.
Instead of treating every session like a fresh start, Light Lane is designed to help the workflow remember what matters.
Controller-aware output
Output should not feel generic when the hardware is not generic.
Light Lane’s generation and preview flow are tied into controller-aware output logic so the software can behave more like a serious machine-side workflow tool and less like a generic sender with a controller badge slapped on top.
This is a big part of what makes the product feel operationally smart. It is built around the idea that software should adapt to the machine reality instead of pretending all lasers behave the same.
Timing estimates that respect reality
Planning is only useful if it reflects what the machine will actually do.
Estimate Calibration exists so timing estimates can be tuned against the behaviour of the real machine. That leads to more realistic planning and a workflow that feels grounded in reality instead of averaging across assumptions that do not match your setup.
For repeat jobs and production work, that gets more valuable fast.
Experimental arc fitting for GRBL
One example of the controller-specific mindset is how Light Lane approaches GRBL output.
What arc fitting mode is
Light Lane includes an experimental arc fitting mode for GRBL controllers that aims to represent suitable curved paths more smoothly. The point is not to add novelty. It is to get cleaner arc behaviour where the controller path can benefit from it and where that output choice improves the result.
- Focused on getting smoother arc behaviour in suitable GRBL workflows
- Experimental by design, so it should be positioned as an advanced option rather than a guaranteed default for every job
- Part of the wider philosophy of matching output strategy to controller capability
- A good example of Light Lane trying to get the most out of what a controller can actually do
Related pages
Feature overview
See how controller-aware output fits into previews, processing, templates, testing, and repeat workflows.
Contact us
Talk through whether your machine or controller path is a good fit for your workflow.
Ruida support status
Confirmed
- Ruida workflow support is available in alpha
- Ruida should be treated as an active support path being evaluated and improved, not as fully mature parity with long-established controller paths
- Best suited for users who understand that this is an early support stage and want to assess fit carefully
Not confirmed
- Do not position Ruida as fully mature or fully equivalent to more established supported paths yet
- Do not imply complete coverage of every Ruida workflow edge case without validation
Questions people usually ask about controller support
Which controller paths does Light Lane support?
Light Lane supports GRBL, Marlin, Smoothieware, and generic or custom G-code machine workflows. Ruida support is also available in alpha.
Is this page just about compatibility?
No. The bigger point is machine-aware workflow. Light Lane is designed to remember setup, respect controller differences, and generate output in a way that matches the actual machine being used.
What do Machine Profiles actually help with?
They help keep machine context, defaults, and setup consistency tied to the real device, which makes switching cleaner, repeating easier, and normal work less repetitive.
Why does controller-aware output matter?
Because the hardware is not generic. A serious workflow should reflect controller differences rather than pretending every machine expects the same thing.
What is the GRBL arc fitting mode for?
It is an experimental mode aimed at producing smoother arc behaviour in suitable GRBL workflows. It is part of Light Lane’s wider approach of focusing on what each controller can actually do well.
Is Ruida fully supported yet?
No. Ruida support is currently in alpha, so it should be discussed as an active support path rather than as fully mature support.
See how Light Lane fits your machine setup
If you want to understand controller fit, saved setup, machine-aware workflow, or whether Ruida alpha is the right path for you, get in touch and talk it through.
Last updated March 30, 2026