Laser Controller Architecture

1 · The three operating models

The split isn't arbitrary. Three different motion technologies stand behind the three models — and each requires a different communication solution between the computer and the controller.

               Laser Controllers

                     │
      ┌──────────────┼──────────────┐
      │              │              │

 G-code stream   Job-based      List-based
  (stream)          (job)        (command list)

      │              │              │

   GRBL            Ruida          JCZ
   grblHAL         Trocen         BJJCZ
   FluidNC                        EZCAD

2 · G-code stream-based controllers

Includes: GRBL · grblHAL · FluidNC

Operating principle

The computer continuously sends motion commands to the controller. The controller processes them in sequence, and moves the motors accordingly. The communication link stays up for the entire duration of the job — if the connection breaks, the job stops.

G0 X0 Y0
G1 X50 Y0 F3000
G1 X50 Y50
M3 S1000

Data flow

Typical use: Diode lasers · CNC routers · Hobby and semi-industrial machines

GRBL

The best-known open-source G-code-based firmware. Originally built for the Arduino platform. Its job is to interpret G-code and generate STEP/DIR signals for the motor drivers. Its maximum PWM frequency is roughly ~1 kHz — enough for low-speed, low-DPI jobs.

grblHAL

A modern evolution of GRBL with a hardware abstraction layer (HAL). It uses the platform's native timer peripherals — the result is 5–50 kHz stable PWM, depending on platform. Supports multiple axes, Ethernet connectivity, and numerous industrial features.

FluidNC

An ESP32-based control system. A G-code stream-based operating model, with WiFi connectivity, a web UI, and SD card execution. Operationally, a G-code stream-based controller.

3 · Job-based controllers

Includes: Ruida · Trocen

Operating principle

The computer doesn't send continuous motion commands. It prepares the entire job in advance — in its own binary format — and uploads it to the controller's memory. The controller then executes the job on its own, without the computer's involvement.

Typical use: CO₂ lasers · Manufacturing systems · Mass production

Ruida

The most widespread family of CO₂ laser controllers. It receives the entire job in advance and executes it locally. The controller works autonomously during the run. Its hardware basis is a DSP + FPGA architecture — this provides the standalone, deterministic job execution and precise trajectory computation.

Note: Ruida also manufactures its own galvo controller card (RDM4024G-PCI series), which is likewise DSP + FPGA based, and can be combined with an industrial camera. This material mainly covers the CO₂ line's (RDC series) architecture.

Trocen

Its operating principle is very similar to Ruida's system. Also a job-based controller — the entire job is uploaded to the controller in advance.

4 · List-based controllers

Includes: JCZ · BJJCZ · EZCAD-based systems

Operating principle

Most fiber lasers don't move mechanical axes. The beam is steered by galvanometer mirrors — two low-mass, high-precision mirrors that are electromagnetically controlled. By changing the mirrors' angle, the laser beam scans the work surface extremely fast.

This motion technology requires a completely different control model.

The software pre-assembles a command list:

SetSpeed      500 mm/s
SetFrequency  20 kHz
SetPower      70%
Jump          X=0,  Y=0
Mark          X=50, Y=0
Mark          X=50, Y=50
Mark          X=0,  Y=50
Mark          X=0,  Y=0

Typical use: Fiber lasers · UV lasers · MOPA systems · High-speed galvo systems

Speed:              2,000 mm/s
Resolution:            100 µm  (0.1 mm step)
Commands/second:     20,000

5 · Comparison

6 · Why aren't the three systems the same?

The three operating models aren't different by accident. Each is an engineering answer to a specific physical problem — and the physical constraint determines the control architecture, not the other way around.

Motion technology as the starting point

Mechanical axes, low speed — diode lasers
The head moves in the X and Y directions, driven by stepper motors. Speed is 100–600 mm/s. At this speed, the G-code stream is workable — the computer can send commands fast enough, and the controller can process them fast enough.

Mechanical axes, large work area — CO₂ lasers
The principle is the same, but the work area and runtime are orders of magnitude larger. On a 60-minute engraving job, a continuous PC connection is unreliable. The solution: upload the entire job in advance, and let the controller handle execution.

Galvanometer mirrors, extreme speed — fiber lasers
Here the motion technology is fundamentally different. It's not the head that moves — the laser beam moves, via the angle changes of two low-mass mirrors. This enables speeds of 1,000–10,000 mm/s. But at this speed, the G-code stream is physically unworkable. The solution: a pre-compiled, optimized command list, which the controller executes in hardware.

The logical chain

This chain explains why the systems can't be swapped for one another — and why one isn't "better" or "worse" than another. All three are optimal solutions within their own physical constraints.

7 · Common misconceptions

8 · The LaserBase approach

9 · What does the controller actually control?

One of the most common misunderstandings in the laser world is that users call GRBL, Ruida, or JCZ systems "laser controllers."

This is partly true, but technically imprecise.

What actually happens?

Users usually see the laser as the machine's most important element. For the controller, however, motion is what matters.

Setting the laser's power is, by itself, a simple task. Generating a PWM or analog signal is trivial from an electronics standpoint.

The hard task is making the right power show up at the right moment, in the right position.

That's why the most important part of a controller is always motion control.

For GRBL

For Ruida

For JCZ

This is even more visible for the JCZ system. The controller's primary job isn't regulating the laser's power, but precisely positioning the galvanometer mirrors.

The laser is really a peripheral

It may sound strange at first, but from a control-engineering standpoint, the laser can often be viewed as a peripheral. The controller's real job, in every case, is ensuring these four things:

• determining position,
• following the motion path,
• regulating speed,
• ensuring timing.

Turning the laser on is, by comparison, a single output operation.

10 · Why doesn't a universal laser controller exist?

The question often comes up: if every laser ultimately does the same thing — cuts, engraves, or marks material — then why isn't there a single universal controller that handles every machine type the same way?

The answer is simple: because the different laser systems aren't solving the same physical problem.

GRBL: streams motion

GRBL-based systems expect a continuous G-code command stream. The computer and the controller work together: the PC sends commands, and the controller processes and executes them in real time.

This model is simple, open, and works well for diode lasers, where the head moves on mechanical axes.

Ruida: runs a job

Ruida- and Trocen-type CO₂ controllers don't expect a continuous G-code stream. They receive the entire job in advance, load it into their own memory, then execute it without a PC.

Here the controller is no longer a simple command-receiving device, but a standalone job-execution system. It has its own display, memory, control panel, and internal workflow.

JCZ: executes a galvo command list

JCZ-based fiber systems differ even further. These don't move mechanical axes, but control galvanometer mirrors. The controller receives a pre-assembled command list, in which motion, mirror position, laser timing, and process parameters all appear together.

This isn't simply a faster version of G-code control. It's a completely different execution model, because the galvanometer system's timing requirement is orders of magnitude stricter.

Why can't all three be replaced by a single firmware?

A universal firmware would simultaneously have to:

• receive a G-code stream and execute it in real time,
• store complete job files and run them standalone,
• execute galvanometer command lists with hardware timing,
• precisely handle both stepper-motor and galvo systems,
• support the differing power and timing models of different laser types.

This might seem possible in theory, but in practice it wouldn't be a single controller — it would be three different control architectures crammed into one box.

The common ground isn't the firmware, but the software layer

It's not worth looking for unity between the three systems at the controller level, but in the higher layers of the software.

A well-built laser software package can be capable of translating the same user-facing logic — material, technique, speed, power, layers, raster or vector operations — into different control models.

But the output layer always has to adapt to the controller's architecture:

• G-code generation and streaming for GRBL,
• job-file generation and uploading for Ruida,
• command-list building and execution for JCZ.

11 · How did today's laser controllers evolve?

Today's laser controllers didn't appear all at once, and weren't built as each other's direct competitors.

Each one was born to solve a given era's specific technical problem.

The CNC legacy

The story starts with CNC machines. The G-code language was created to describe the motion of milling machines, lathes, and other numerically controlled machines — its first standardized version, RS-274, appeared in 1963, published by the Electronic Industries Alliance. This protocol was born nearly 60 years ago, exclusively for controlling mechanical machine tools.

CNC machines
    ↓
G-code (RS-274, 1963)
    ↓
Motion control

G-code's goal was simple:

• move the tool,
• at a given speed,
• to a given coordinate,
• along a predetermined path.

This model worked excellently with mechanical axes, where the machine head or the workpiece moves. It wasn't designed for raster image processing — where the laser's power has to switch pixel by pixel.

The arrival of diode lasers

When hobby and semi-industrial diode lasers became widespread, the simplest solution was to reuse the existing CNC world.

CNC world
    ↓
GRBL
    ↓
Diode lasers

Here, from a control-engineering standpoint, the laser is practically a new tool.

Mill spindle
or
Laser

For the controller, both are one output. The difference is that with milling, the spindle spins, while with a laser, power is regulated by a PWM signal.

The problem of large CO₂ systems

With CO₂ machines, the work area and runtime grew significantly. Larger, industrial-type machines appeared:

• 600×400 mm,
• 900×600 mm,
• 1300×900 mm,
• 1600×1000 mm or a larger work area.

On a machine like this, an engraving or cutting job can take hours. If the controller needed a continuous PC connection, a single network dropout or USB glitch could ruin the entire job.

This led to job-based control:

Drawing
    ↓
Full job
    ↓
Controller memory
    ↓
Standalone execution

This is how Ruida- and Trocen-type controllers came about. Ruida Technology was founded in 2008, and specialized in DSP-based motion control and laser applications. These controllers are no longer simple command-receiving units, but standalone job-execution systems with their own memory, display, and control panel.

The arrival of galvanometer systems

Fiber and UV galvo systems brought a completely new problem. Here, it's no longer the head that moves over the work area.

The laser beam moves.

Mechanical head
        ↓
Galvo mirror

Galvanometer mirrors are low-mass, high-speed optical elements. The laser beam's position is set by changing mirror angle, not by moving mechanical axes.

This raises speed by orders of magnitude:

• typically 100–600 mm/s for mechanical axes,
• 1,000–10,000 mm/s for galvo systems.

At this speed, the G-code stream model becomes physically and timing-wise unsuitable. List-based control appeared:

Drawing
    ↓
Command list
    ↓
Galvo controller
    ↓
Real-time execution

This is how the JCZ architecture and the control world built around EZCAD came to be.

The development chain

This developmental arc helps explain why the different controllers aren't flawed or improved versions of each other. Each is a logical, justified solution within its own technological environment.

12 · Where do laser software packages fit in?

The next misunderstanding usually forms around the software. Many people think a laser software package is itself the controller.

This isn't accurate. LightBurn, LaserGRBL, RDWorks, EZCAD, or any other laser software isn't the same layer as the hardware controller itself.

LightBurn's role

LightBurn is a good example of how several completely different output models can work behind the same user interface.

             LightBurn

                  │

      ┌───────────┼───────────┐
      │           │           │

   G-code       RDJob      JCZ API

      │           │           │

    GRBL       Ruida       JCZ

The user sees the same drawing, works with the same layers, speed and power fields. In the background, however, the software produces completely different output depending on which controller is selected.

• For GRBL, a G-code stream is created.
• For Ruida, an RDJob-type job file is created.
• For JCZ, the system fits a list/API-based execution model.

For the controller, these aren't interchangeable. A Ruida controller doesn't accept a GRBL G-code stream, GRBL firmware doesn't interpret a Ruida job file, and a JCZ galvo controller doesn't work off G-code written for classic mechanical axes.

The controller and the software are two separate layers

The difference in brief:

That's why it's misleading to say a piece of software "handles" the different controllers "the same way." The interface can be unified for the user, but the output layer is completely different per controller.

13 · Where does LaserBase fit in?

Most laser software starts from controller-centric thinking.

The user selects:

• the machine,
• the controller,
• the communication method,
• then adapts to their limits.

This is an understandable approach, because most laser software's primary job is to communicate with a given controller.

A technology-centric approach

LaserBase's outlook is different. It doesn't start from the controller, but from the technology.

The process doesn't start like this:

GRBL
    ↓
What can the machine do?

But like this:

Material
    ↓
Technology
    ↓
Image processing
    ↓
Optimal parameters
    ↓
Controller-specific output

In this model, the controller isn't the system's center, but one possible target of the execution layer.

LaserBase's place in the architecture

LaserBase
    ↓
Material database
Process knowledge
Image processing
    ↓
Execution layer
    ↓
GRBL
Ruida
JCZ

LaserBase isn't firmware, isn't a controller, and isn't a simple file-sending program. It can be understood as a higher abstraction layer: it translates user intent and process knowledge into a form the given controller can execute.

What does this mean in practice?

Ideally, the user doesn't start from what command needs to be sent to the controller.

But from what they want to achieve:

• I want to engrave 3 mm birch plywood.
• I want to mark stainless steel.
• I want to engrave a photo onto anodized aluminum.
• I want to cut acrylic with a CO₂ laser.
• I want to stably reproduce a black-and-white raster image.

The system's job is then to:

• identify the material,
• select the technology,
• determine the optimal parameters,
• check the hardware's physical limits,
• produce the appropriate controller-specific output.

Why does this matter?

If software is exclusively controller-centric, the user has to adapt to the controller's way of thinking.

If, instead, it's technology-centric, the software takes on the translation between the user's goal and the controller-specific execution.

14 · Closing summary

The evolution of laser controllers isn't random. The different architectures were born to solve different physical problems.

• GRBL → G-code stream-based control for mechanical axes.
• Ruida / Trocen → job-based control for larger, standalone CO₂ systems.
• JCZ → list-based control for high-speed galvo systems.

These aren't better or worse versions of each other. They're systems optimized for different goals.

The job of modern laser software isn't to handle every controller with the same method. That would be technically misleading. The real job is to be able to translate the same process knowledge into different control models.

This is the outlook that makes it possible for the same knowledge to be applicable on diode, CO₂, and fiber systems — while, in the background, every controller gets output matching its own operating model.

15 · Control layers and system architecture

A laser system isn't a single unit — it's a chain of layers built on top of each other. The user touches the topmost layer, physical execution happens at the bottom.

Most misunderstandings come from these layers blurring together — for example, treating the software as the controller, or the controller as the laser itself.

CPU · DSP · FPGA — what's each for?

Modern laser controllers' hardware architecture isn't uniform — different processing units perform different tasks:

GRBL-based systems run on a CPU — enough for mechanical axis control at low-medium speed. Ruida's DSP+FPGA combination enables standalone, PC-independent job execution and precise path following. For galvo systems, the FPGA or dedicated hardware provides the sub-µs timing precision that galvo positioning requires.

JCZ controller  →  XY2-100  →  Galvo unit  →  Mirror angle  →  Beam position

— Sources used

16 · Glossary

17 · Separating JCZ and EZCAD architecture

One of the most common misunderstandings in the fiber laser community is mixing up the concepts of "JCZ" and "EZCAD." The two actually represent completely different layers: one is hardware, the other is software — and this separation is the basis for understanding the system.

The JCZ hardware card family

BJJCZ (Beijing JCZ Technology Co., Ltd.) is one of the most significant manufacturers of galvo controller cards. The card family's evolution reflects the evolution of galvo control well — from early PCI-based cards to standalone USB- and Ethernet-based systems:

The EZCAD software family

EZCAD is the PC-side software built for JCZ hardware cards. The two main versions target different card generations, and their architecture differs fundamentally:

The layer boundary and integration options

There are two possible integration points between the JCZ hardware and the EZCAD software, with different reliability and complexity:

EZCAD3's TCP/IP API is the most reliable integration route: documented, maintained by the manufacturer, and lets external applications — including LightBurn 1.4+'s galvo mode — control EZCAD3 directly. This requires EZCAD3 to be installed and running on the host computer.

The second route is the direct USB protocol — this is based on community reverse-engineering (the EduTech Wiki LMCV4-FIBER-M RE project). This enables native control without EZCAD, but is riskier from a legal and stability standpoint, and protocol changes have to be tracked.

18 · DSP / FPGA / CPU roles in detail

Understanding controllers' internal architecture is essential to clearly seeing why GRBL, Ruida, and JCZ differ in performance and capability. The three fundamental processing elements — CPU, DSP, and FPGA — are each optimized for different tasks, and appear in different combinations in different controller classes.

CPU — general-purpose processor

A traditional, general-purpose processor is flexible and easy to program — but not optimized for real-time, µs-precision I/O tasks. The operating system's scheduler, interrupt handling, and cache misses introduce latency into the system, which is a problem for applications that need deterministic timing.

CPU-based systems' advantage is flexibility, low cost, and an open-source software environment — their drawback is that stepping frequency and real-time performance are limited. GRBL is the most mature CPU-based firmware, but its design limits (linear ring buffer, 8-bit Arduino origin) have been unchanged for nearly two decades, and are only partially exploitable on modern platforms.

DSP — digital signal processor

A DSP (Digital Signal Processor) is a processor specifically optimized for high-speed execution of mathematical operations — multiplication, addition, filtering. It has a hardware multiply-accumulate unit (MAC unit), a dedicated data bus, and circular-buffer memory handling. These make it suitable for real-time computation of motion trajectories and laser power curves.

Ruida's RDC-series controllers use Texas Instruments DSP chips — likely from the C2000 real-time control family. The DSP's jobs in the Ruida system:

• Interpreting and segmenting the job file (.rd format)
• Computing the motion trajectory — acceleration and deceleration profiles, arc approximation
• Computing the laser power curve on the fly, speed-dependent (Power Scale function)
• Handling communication: Ethernet, USB, RS-232 channels
• Driving the control panel and the display

The DSP alone — however fast — isn't capable of sub-µs, deterministic I/O generation. That requires the FPGA.

FPGA — field-programmable gate array

An FPGA (Field-Programmable Gate Array) isn't a processor in the traditional sense — it's programmable hardware. Inside the FPGA, logic gates and flip-flops are wired together, executing hardware functions in parallel and in real time, with no software overhead whatsoever.

The FPGA's role in different laser controllers:

The power of the DSP + FPGA combination

Ruida and JCZ systems both use both units — and this isn't an accident. The two perform complementary, mutually completing tasks:

DSP                              FPGA
─────────────────────────────    ─────────────────────────────
Job interpretation               STEP/DIR pulse generation
Trajectory computation           XY2-100 data stream generation
Laser power curve                PWM modulation
Communication handling           Encoder processing
User interface                   I/O latching
─────────────────────────────    ─────────────────────────────
Flexible, programmable           Deterministic, hardware-based
µs latency                       ns latency

The DSP determines what needs to happen. The FPGA executes it exactly when needed — with nanosecond precision and a determinism software can never reach.

This architecture is what lets Ruida run even an hour-long engraving job standalone, without a PC, stably and reproducibly — and lets the JCZ controller send 100,000 position updates per second to the galvo unit, without interruption.

19 · XY2-100 in detail

The XY2-100 protocol is the standard industrial communication interface for digital galvanometer scanner systems. It was first developed by Cambridge Technology (now Novanta), and has since become the industry's de facto standard — every major galvo manufacturer (Scanlab, Cambridge, II-VI, Sino-Galvo) implements it. Earlier chapters briefly touched on the protocol — this chapter provides the full technical detail.

Physical layer

Electrically, XY2-100 follows the RS-422 differential signaling standard. This physical layer provides noise immunity and reliable communication even over longer cable runs in an industrial environment:

• Differential line pair: every signal runs as a +/− pair, which filters out common-mode electromagnetic interference
• Clock (CLK): a 2 MHz symmetric square wave — this sets the data rate
• Data line (MOSI / DATA): position data and control bits going from the controller to the galvo
• Feedback (MISO / STATUS): status information returned by the galvo (optional, implementation-dependent)
• Maximum cable length: typically 5–10 m, depending on shielding and signal quality

Frame structure and data format

XY2-100 builds every communication frame from 20 bits, in sync with the 2 MHz clock:

20 bit × (1 / 2 MHz) = 10 µs / frame
→ 1 s / 10 µs = 100,000 position updates per second

The structure of a single frame's bits:

The 16-bit position data covers 65,536 steps across the entire scan field. For a typical 110 mm × 110 mm scan field, this gives a step density of:

110 mm / 65,536 steps ≈ 1.68 µm / step

This resolution is far finer than the laser's focal spot size (typically 20–50 µm at 1064 nm, with a 163 mm F-Theta lens) — so the XY2-100 protocol isn't the resolution bottleneck; the optics and focal spot size are.

The XY2-100E extension

Some premium galvo systems use the extended version of XY2-100, the XY2-100E protocol. This provides 20-bit position data (1,048,576 steps), which increases resolution roughly 16-fold compared to the base protocol. This is especially important for large-work-area, high-precision applications — for example on a 300 × 300 mm work field, where the base 16 bits is no longer precise enough.

Timing model and consequences

The galvo servo system continuously tracks the incoming position data in real time — it doesn't wait for a "position reached" feedback signal. This means the controller has to precisely schedule the sending of position data, so the galvo mirror moves at the desired speed and along the desired path.

Laser synchronization alongside XY2-100

XY2-100 itself doesn't carry a laser control signal — the laser is controlled by a separate channel (typically a TTL or analog signal to the laser's modulator). The JCZ controller's job is to synchronize the laser on/off signal with the position data at nanosecond precision — the FPGA implements this at the hardware level.

The synchronization delay parameters can be set in the EZCAD software:

• Laser On Delay: the time between the galvo starting to move and the laser turning on
• Laser Off Delay: the delay in turning off the laser at the end of the move
• Polygon Delay: extra wait time applied at direction changes

With incorrect synchronization, blurring, breaks, or spurious marking appear at the start and end of contours. These parameters are individually calibrated on every machine during service setup.

20 · The physics of galvanometer systems

To understand the galvanometer mirror control system, it's worth going back to the underlying physics. The galvo actuator isn't a motor in the usual sense — it's a precisely controlled electromagnetic actuator that changes the mirror angle in proportion to the applied current. This principle is what enables the extraordinary speed and repeatability.

The electromagnetic actuator principle

The galvanometer's basic principle is the Lorentz force: a current-carrying coil in a magnetic field experiences a rotational torque. For a galvo:

• The coil sits on the rotor shaft — this carries the mirror
• The permanent magnetic field is fixed as part of the housing
• The direction and magnitude of the applied current determine the angular deflection
• A restoring force (a mechanical spring or electrical negative feedback) pulls it back to the zero position

The relationship between angle and current is ideally linear — the closed-loop servo system ensures this in reality, compensating for nonlinearities and mechanical disturbances.

Mirror sizes and inertia

A galvo system's speed is directly tied to the mirror's size and mass. A smaller mirror = a smaller moment of inertia = faster motion and a shorter settling time. This relationship is key in system design:

Servo system, bandwidth, and settling time

The galvo servo system operates in a closed loop: a position sensor (capacitive or optical encoder) measures the mirror angle, and the servo amplifier sets the current in proportion to the difference between the measured and the desired angle. This PID control typically achieves 1–3 kHz mechanical bandwidth — meaning the galvo can no longer follow changes faster than 1–3 kHz.

"Settling time" is the critical parameter: this is the minimum time needed for the galvo to move to the desired position and stabilize there within the specified accuracy tolerance — before marking begins.

The scan field and optical distortion

The galvo mirror pair (X and Y axis) provides two mutually perpendicular angular degrees of freedom. The two mirrors, however, aren't located at exactly the same point — there's a few millimeters of axis offset between them. This causes optical distortion (so-called pincushion or barrel distortion), especially at the corners and edges of the work field.

The amount of distortion increases with:

• a larger scanner angle — i.e. a larger work area at the same focal length,
• a shorter-focal-length F-Theta lens,
• a larger axis offset between the two galvo mirrors.

Correction tables are used to handle this — covered in detail in the next chapter.

Mirror coatings and wavelength compatibility

A galvo mirror's coating has to be matched to the laser's wavelength — the wrong coating causes reflection loss, heating, and coating damage at high power:

In high-power systems (50 W, 100 W fiber), mirror coating quality and cleanliness are critical. A dirty or damaged mirror coating can locally absorb the laser, leading to thermal damage, loss of accuracy, and complete mirror failure. Regular cleaning and condition monitoring are mandatory.

21 · F-Theta optics

One of the most important and most commonly misunderstood elements of a galvo system's optical design is the F-Theta objective. To understand it, it's worth comparing it to a traditional focusing lens — and understanding why the two aren't interchangeable in a galvo application.

The problem with a traditional lens in a galvo system

A simple converging lens (plano-convex, aspheric) focuses the incoming parallel beam to a focal point — this point sits on the lens's optical axis, at the focal length f. If the galvo mirror deflects the beam, the lens still focuses, but the focal point moves on a spherical surface, not a flat one.

Mathematically: if the galvo angle is θ, the position projected onto the work surface for a standard lens is:

y = f · tan(θ)

This isn't linear at large angles — at the corners of the work field the spot "falls" out of focus, blurs, and deviates from the nominal position. This degrades both marking quality and geometric accuracy.

The F-Theta lens's solution

The F-Theta lens is a specially designed, compound optical system with two simultaneous goals:

1. Flat-field focusing: the focal point stays on a flat surface across the entire work area, not a spherical one
2. Linear mapping: the galvo's angular change is linearly proportional to the displacement on the work surface

y = f · θ    (F-Theta relationship)

"Linear mapping" is especially important: JCZ/EZCAD software assumes a directly proportional relationship between the galvo angle and the work-area coordinate. If this condition isn't met — because unsuitable optics are used — the marked shapes distort, and the correction table can't fully compensate for the error either.

F-Theta lens specifications and work areas

Telecentric F-Theta lens

With a standard F-Theta lens, the beam arrives at the work surface at a slightly oblique angle near the edges of the work area. In most applications this is negligible — but in certain cases (deep engraving, precise side-wall shaping, accuracy-critical drilling, processes requiring a parallel beam) the beam needs to stay exactly perpendicular to the work surface at all times.

This is what the telecentric F-Theta lens is for, where additional optical elements ensure the outgoing beam stays parallel to the optical axis across the entire work field — regardless of the galvo angle. This is more expensive and optically more complex, but indispensable in some critical applications.

Determining the focal spot size

The focal spot diameter (d) can be estimated with the diffraction-limit approximation:

d_min ≈ (4 · λ · f) / (π · D)

where λ is the laser's wavelength, f is the F-Theta lens's focal length, and D is the incoming beam's diameter. It follows that: a smaller spot needs either a shorter focal length or a larger beam — but a shorter focal length means a smaller work area. This basic law is a tradeoff every galvo system designer faces between spot size and work area.

22 · Correction tables and COR files

Even with the best F-Theta optics and the most precise galvo system, perfect geometric fidelity can't be achieved without calibration. Distortions arising from mechanical assembly, optical deviations, and galvo nonlinearity can be compensated for with correction tables.

Sources of distortion

• Galvo nonlinearity: the servo isn't perfectly linear across the full angular range
• Axis non-perpendicularity: the X and Y galvo axes aren't exactly at 90° to each other
• Optical distortion: the F-Theta lens isn't a perfectly ideal mathematical model either
• Mounting error: the galvo's axis isn't exactly perpendicular to the optical axis
• Temperature dependence: thermal expansion of the mechanical elements causes a small change in the work field

Together, these errors typically cause a few tenths of a mm to 1 mm of distortion at the edges of the work field, which is unacceptable in precision applications.

The structure of the COR file

The correction file (.cor extension) used by EZCAD software contains a two-dimensional grid with correction vectors. The grid is typically 65 × 65 or 128 × 128 points, and evenly covers the whole work field.

Every grid point has a (Δx, Δy) correction vector attached — this says by how much the galvo has to "shift" the given nominal coordinate to reach the actual target position. Between two grid points, the software computes the correction for any intermediate position by bilinear interpolation.

Correction limits

• Doesn't compensate for focal-length change (a z-direction error) — dynamic focus control (a 3D galvo system) is needed for that
• The correction's accuracy is limited by measurement accuracy — a coarse measurement gives a coarse correction
• With large distortion, bilinear interpolation isn't enough — a denser grid or higher-order interpolation is needed
• Calibration is valid for a given focal length (work height) — at a different height, the distortion differs
• Mechanical expansion from temperature change causes a small amount of drift over the course of a work session

The COR file's relationship to layer separation

Handling the COR file is entirely a software-side task — the JCZ card knows nothing about the correction. EZCAD applies the correction to the coordinates before sending them to the card. This also means that if an external piece of software (LightBurn, LaserBase, or a custom application) controls the JCZ card directly, bypassing EZCAD, it has to implement and apply the correction-table logic itself — this is one of the most serious technical challenges of direct JCZ integration.

23 · LightBurn backend architecture

LightBurn is one of the most widespread software packages in the laser community — and a good illustration of how the same user interface can be built over several completely different control models.

The LightBurn layer model

The GRBL driver in LightBurn

The GRBL driver in LightBurn is the simplest and most transparent — the G-code standard is public:

• Vector layers → G-code motion commands (G0 positioning, G1 line, G2/G3 arc)
• Images → line-by-line scanning, switching power pixel by pixel in M3 S{value} format
• Cluster mode → G1 Y-0.1S0.875:0:0:0.5:0.875 format, where multiple pixels' S values are sent at once
• Real-time streaming: LightBurn itself handles buffer filling, pacing the sending by watching for OK acknowledgments

The Ruida driver in LightBurn

The Ruida driver is more complex — Ruida's .rd format isn't public, and is based on community reverse-engineering:

• LightBurn generates a binary job file, which it uploads to the controller over Ethernet (UDP protocol) or USB
• The format contains: layer parameters, motion commands, laser power curves, corner-slowdown settings
• LightBurn performs Ruida-specific optimizations: Power Scale speed-dependent power correction, Corner Power setting

Galvo / JCZ driver — LightBurn 1.4+

LightBurn's galvo and fiber laser support appeared in version 1.4, and has been actively developing since:

• Communicates over the EZCAD3 TCP/IP API — this is the most reliable, manufacturer-supported route
• Direct LMC4 card communication is also possible as an alternative (LightBurn's built-in LMC driver)
• Correction-table handling: LightBurn can apply its own correction, or delegate it to EZCAD3
• MOPA parameters (pulse width, frequency) can be handled as galvo layer parameters

The limits of the device abstraction

LightBurn's device layer provides strong abstraction — but the price of that abstraction is that some controller-specific capabilities can't be fully exploited through the unified user interface:

• Ruida's Power Corner setting is available in LightBurn, but isn't meaningful on other controllers
• JCZ galvo-specific parameters (jump speed, mark delay, polygon delay) show up in the galvo layer parameters, but aren't applicable in a GRBL context
• The cluster mode G-code option applies to GRBL, while a different mechanism applies for Ruida or JCZ

This is why the claim "LightBurn handles everything the same way" is true at the user level — but in some professional applications, the native software (EZCAD3, RDWorks) provides deeper access.

24 · LaserBase's multi-controller model

One of the defining goals of LaserBase's architecture is realizing a technology-first, multi-controller model. This means user intent — material, technique, desired outcome — isn't tied to the controller type. The same process knowledge is translated into controller-specific output, depending on what hardware is connected.

The technology-first approach in detail

In traditional laser software, the user organizes their work around the machine and the controller — the software primarily communicates with the controller, and the user adapts their parameters to that. In the LaserBase model, the order is reversed:

Identifying the material (material library)
        ↓
Selecting the technology (engraving / cutting / marking)
        ↓
Image processing and optimization
        ↓
Checking hardware limits (step/mm, PWM, rise/fall time)
        ↓
Generating controller-specific output

In this model, "generating controller-specific output" is the last step — not the first. The system starts from user intent, and adapts the final output to the given controller's architecture.

The output-adapter layer

In LaserBase's internal architecture, the output-adapter layer is responsible for translating the same processing result into different controller formats:

GRBL-specific LaserBase optimizations

In LaserBase's current GRBL integration, a number of controller-specific optimizations are applied, based solely on knowledge of the GRBL and stepper-motor systems' architecture:

Step/mm-based raster alignment: LaserBase calculates the physically achievable DPI values from the machine's step/mm value — resolutions that fall on a whole number of stepping units. It fits the raster to these, avoiding the sub-pixel positioning error that arises from step/mm and DPI incompatibility.

f_img frequency check: Before every speed–DPI combination, LaserBase computes the required image modulation frequency (f_img = v × DPI / 1524), and compares it against the firmware's and the laser module's physical limits. If the combination falls outside the hardware's limits, the system warns — preventing buffer starvation and image quality degradation.

Cluster mode output: For raster engraving, LaserBase generates cluster-mode G-code — sending multiple pixels' S values in one command, drastically reducing planner load, which is critical especially at high speed and high DPI.

Future directions: Ruida and JCZ integration

Ruida integration is based on the community-reverse-engineered .rd format — LightBurn has proven this is achievable and can be run stably. LaserBase's goal is to make the technology knowledge base (material database, parameter optimization, image processing) accessible on CO₂ Ruida systems too.

For JCZ / BJJCZ integration, the EZCAD3 TCP/IP API is the most promising route. This is documented, manufacturer-supported, and lets LaserBase communicate with EZCAD3 over TCP/IP instead of directly over USB with the JCZ card. This requires EZCAD3 to be running on the host computer — which is typically the case on fiber galvo machines.

25 · MOPA technology

MOPA (Master Oscillator Power Amplifier) is a two-stage fiber laser architecture that differs fundamentally from a traditional Q-switched fiber laser. The difference isn't merely about power — the free adjustability of pulse parameters is what makes MOPA suitable for applications that can't be achieved with the same flexibility using a Q-switched source.

MOPA vs. Q-switched fiber laser

How MOPA works

The MOPA architecture is built from two main components:

1. Master oscillator (seed laser): generates low-power, but precisely controlled laser pulses. Pulse width, frequency, and the pulse's time profile are determined here — based on the electrical parameter-control signal sent by the JCZ controller. The seed laser is typically a diode laser or semiconductor laser of a few mW.
2. Power amplifier (YDFA — Ytterbium Doped Fiber Amplifier): the Yb-doped optical fiber amplifier boosts the seed pulses to the desired output power (e.g. 20 W, 50 W, 100 W). The amplifier doesn't change the pulse's time profile — it only raises the energy level.

This two-stage architecture lets the pulse parameters (width, frequency) and the output power vary in relatively independent ranges — unlike a Q-switched system, where the cavity's physics fixes the possible pulse width.

Pulse width and material effect

MOPA's biggest advantage is pulse-width control, which fundamentally determines the nature and depth of the material-laser interaction:

Colored marking on stainless steel — a MOPA-specific application

One of MOPA's most spectacular and significant applications is colored marking of stainless steel. The mechanism is based on the oxide layer's thickness: differently thick mixed Cr₂O₃ / Fe₂O₃ oxide layers reflect different wavelengths — this is thin-film interference, the same physics behind the iridescent colors of soap bubbles and thin oil films.

MOPA can precisely set the oxide layer's thickness by combining pulse width and repetition rate. Typical parameter-to-color mappings:

• Gold / yellow: a specific PW + frequency + speed combination
• Blue / violet: a different PW / higher frequency
• Green, red: further parameter combinations

This process is extremely parameter-sensitive — speed, power, PW, and frequency together determine the result, and even a small change gives a different color. A reproducible result requires a material library, a precisely calibrated machine, and careful parameter documentation. A well-built MOPA material-profile system (like LaserBase's material library) is exactly what enables this reproducibility.

MOPA parameters in the JCZ / EZCAD system

The JCZ LMCV4-FIBER-M card and the EZCAD software specifically support MOPA sources too. In the command list, MOPA-specific parameters appear as separate control entries, which the card sends to the source's modulator via the FPGA, at nanosecond precision:

• Pulse Width (PW): the pulse's time duration in nanoseconds — the most critical MOPA-specific parameter
• Pulse Repetition Frequency (PRF): pulses per second, in kHz
• First Pulse Suppression: suppressing the first pulse — at the start of every marking line, the source's first pulse differs energetically from the rest, and this compensates for it
• Power: average power as a percentage of the rated maximum

MOPA manufacturers and market positioning

26 · Further reading

The sources below provide deeper theoretical and practical grounding for the topics covered in this document.

Galvanometer systems and optics

• Saleh, B.E.A. & Teich, M.C. — Fundamentals of Photonics (Wiley, 3rd ed. 2019) — One of the most authoritative textbooks on optics fundamentals and laser optics. Its chapters on galvo systems and focusing optics cover the physical basics in detail.
• Marshall, G.F. & Stutz, G.E. (eds.) — Handbook of Optical and Laser Scanning (CRC Press, 2nd ed. 2004) — A handbook specifically focused on scanning systems, with detailed coverage of galvo, F-Theta optics, calibration, and industrial applications.
• Svelto, O. — Principles of Lasers (Springer, 5th ed. 2010) — Laser fundamentals and source technology, including fiber amplifiers and gain principles.

Motion control and firmware

• grblHAL documentation and wiki — github.com/grblHAL — Detailed technical documentation on grblHAL firmware architecture, the HAL interface, the cluster mode implementation, and platform-specific optimizations.
• GRBL GitHub Wiki — github.com/gnea/grbl/wiki — Complete documentation for the original GRBL firmware: motion planner, buffer handling, G-code implementation, configuration parameters.

Fiber lasers and MOPA technology

• Richardson, D.J. et al. — High power fiber lasers: current status and future perspectives — Journal of the Optical Society of America B, 2010. — A reference article on high-power fiber lasers and amplifier architectures, open access.
• Zervas, M.N. & Codemard, C.A. — High Power Fiber Lasers: A Review — IEEE Journal of Selected Topics in Quantum Electronics, 2014. — A comprehensive review of MOPA and other fiber laser technologies, and the physics of peak-power scaling.

Industrial laser applications

• Ready, J.F. & Farson, D.F. (eds.) — LIA Handbook of Laser Materials Processing (Magnolia Publishing, 2001) — A comprehensive handbook of industrial laser applications: the physics and technology of material processing, marking, cutting, and welding.

Protocols and interfaces

• XY2-100 Interface Specification — An industrial standard developed by Cambridge Technology. The specification is publicly available as a PDF (distributed by ilphotonics.com). Contains the physical layer, frame structure, and timing diagrams.
• EduTech Wiki — LMCV4-FIBER-M reverse engineering — edutechwiki.unige.ch — Detailed community reverse-engineering documentation of the JCZ LMC4 card's USB protocol. Unofficial, but the most complete publicly available source for understanding the closed protocol.

Online community resources

• LightBurn Community Forum — forum.lightburnsoftware.com — An active community with detailed technical discussions on protocol-specific questions, firmware compatibility, and image processing.
• LaserGRBL GitHub Discussions — github.com/arkypita/LaserGRBL — The development discussions for the raster protocol and cluster mode are documented here.
• Inventables / LightBurn Forum — Fiber and Galvo threads — A lot of practical user experience on galvo system calibration, COR file handling, and MOPA parameterization can be found here.

27 · Extended source list

28 · Ecosystem-based systems

Alongside the three architectural categories (G-code stream, job-based, list-based), there's a fourth dimension that cuts across them: the open vs. closed ecosystem axis. This isn't a control architecture — it's a dimension characterizing the system's integrability and openness.

Some manufacturers — for example AlgoLaser, xTool, and Twotrees — don't just supply hardware, they build their own integrated software-hardware ecosystem. Based on the communication model, these are generally G-code stream-based or job-based systems, but this is hidden from the user.

What does this mean for the user?

These systems are more convenient for beginners — the manufacturer takes care of optimization, software-hardware matching, camera-based positioning. The downside is that the user can't swap out the software, can't integrate deeply, and is dependent on the manufacturer's future decisions — for example, if a software version is discontinued, or the cloud server shuts down.

Architecturally this isn't a new category — but it's a separate dimension in terms of openness. That's why, in a comparison table, it's worth distinguishing between open (GRBL) and closed (xTool P series) systems within the same communication model.

29 · Emerging platforms — Klipper, FluidNC, MKS DLC32

The world of laser control isn't static. Over the past few years, several platforms have appeared or matured that don't fit cleanly into the traditional three categories — or that cut across them.

Klipper — Linux-host-based control

Klipper firmware deserves attention as a special case. It doesn't fit cleanly into either traditional category — it's G-code-based, but computation and real-time execution are split apart:

Klipper's core idea is that the heavy computation is done by the Linux host, while the microcontroller only does real-time step generation. This enables very precise motion planning, resonance compensation (input shaping), and other advanced features that aren't available on an ESP32-based system.

A cheap Linux host option: an Android TV box (~15–20 EUR, 64 GB storage) is more powerful than a Raspberry Pi 3, and can run Armbian — this is the cheapest option for a Klipper host. A proper motherboard (mini ITX, 6–8 GB RAM) is a significantly more powerful platform, but at a higher price. The TV box is clearly a higher tier than the ESP32 level, but it's the best-value cheap option.

A LaserBase-validated Klipper configuration isn't currently available — a monitored, actively developing area.

FluidNC — ESP32-based, with SD card standalone running

FluidNC is G-code stream-based firmware, but in terms of standalone running it's closer to Ruida-type systems than to traditional GRBL. SD card support has to be configured in the config.yaml file (the sdcard and spi sections, with the right GPIO pins) — once successfully configured, a file can be run directly from the SD card, without a PC, using the $SD/Run=/file.nc command.

The FluidDial and FluidTouch accessories add a physical control interface — jog-wheel-style control, a menu system, an SD card browser. With these, the FluidNC experience gets closer to standalone, Ruida-type controllers, while the communication model stays G-code-based.

MKS DLC32 — an ESP32 board designed for offline engraving

The MKS DLC32 is an ESP32-based controller board specifically developed for offline engraving — with a built-in SD card reader and an optional 3.5-inch touchscreen. It ships with GRBL-based firmware by default, but can also be flashed with grblHAL.

30 · SD card and standalone running — a platform-level comparison

In the comparison table (Chapter 5), the "PC needed while running" row gives a simplified picture. The reality is platform-dependent — the ability to run standalone isn't an architectural property, but a matter of hardware and firmware capability.

The communication architecture (stream / job upload) and the ability to run standalone are two different dimensions:

• grblHAL runs a G-code file from an SD card — communication-wise this is a G-code stream-based model, but PC-independent execution.
• Ruida loads and runs its own binary job file — also PC-independent, but in a completely different format.
• So standalone capability isn't an architectural boundary, but a matter of hardware capability.

31 · Professional corrections and audit notes

This chapter collects the corrections identified during online validation and community audit — fixes to claims that appeared inaccurate or oversimplified in earlier versions of this material.

1. FluidNC SD card — "natively supported" vs. "needs configuring"

Earlier versions of this material may have implied that FluidNC runs from an SD card by default. The reality: the SD card isn't a default — the sdcard and spi sections have to be configured separately in the config.yaml file, with the right GPIO pins. FAT-32 format is mandatory; ExFAT isn't supported. Cards larger than 64 GB only work if reformatted to FAT-32.

2. MKS DLC32 — processor type and firmware compatibility

The MKS DLC32 and the MKS DLC32 Max contain different processors (ESP32 vs. ESP32-S3). The two variants need different firmware. The MKS ESP32 Download Tool doesn't validate the chip ID — so the processor type has to be checked every time before uploading firmware. Uploading the wrong firmware can brick the board.

3. xTool — model-level differences

The claim "xTool is a closed ecosystem" can't be generalized to the entire product line. The xTool D1 and D1 Pro are G-code-based, fully compatible with LightBurn. The closed ecosystem mainly applies to the xTool P2/P2S and P3 models, where LightBurn support is limited.

4. Klipper laser support — not experimental, but mainline

As of December 2023, Klipper's fast PWM update landed in mainline. With the pwm_tool configuration, M3/M4/M5 G-code commands work. Laser support therefore isn't experimental — but it's primarily a system built for 3D printing, into which laser support was added later. Important safety note: diode lasers are usually inverted, and on an MCU restart the laser can briefly stay at full power — configuring a safety timeout is mandatory.

5. Ruida speed — 100–1,500 mm/s

In the comparison table, Ruida's speed appeared as "100–800 mm/s." The reality: some Ruida systems work in the 1,000–1,500 mm/s range for engraving too. The more accurate figure: typical: 100–1,500 mm/s, depending on model and configuration.

6. "G-code wasn't built for raster" — a more precise phrasing

This claim is a useful simplification for teaching purposes, but the technically more precise version is: G-code was originally built to describe vector tool paths (RS-274, 1963). Raster engraving was layered on top later — as an adaptation, not an original design goal. Cluster mode (LightBurn 1.2.02+) made this adaptation significantly more efficient.

7. "A fiber laser can't work with G-code" — a more precise phrasing

This claim, as stated, is too strong. The more precise phrasing: a fiber galvo system could in theory be controlled with paths described by G-code — but the classic G-code stream architecture isn't suited to meeting the required timing and speed requirements. The limit isn't in the G-code language, but in the stream communication model and the USB/PC-side latency.