Searching for an EZCAD to G-code conversion usually means a shop has both worlds on the bench: a fiber marking unit that came with EZCAD-style software, and a gantry machine (engraver, router, or laser table) that runs G-code. The instinct to bridge them with a converter is reasonable and wrong, because the two machines do not share a motion model at all.
What kind of machine does EZCAD actually drive?
A galvo marker. Inside the scan head, two galvanometer mirrors tilt at very high speed, steering the laser spot anywhere in a fixed marking field (commonly on the order of 100-300 mm square) without anything mechanical traveling across the table. The software sends the controller vectors, fill patterns, and laser parameters (power, frequency, speed, hatch), and the mirrors draw them in milliseconds-per-character territory. There is no axis carriage to command, which is precisely why laser engraving at marking speeds is a galvo specialty: serial numbers, barcodes, logos on metal, all permanent and all faster than any gantry could traverse.
Why is there no meaningful G-code conversion?
Because G-code’s job is to coordinate physical axes through space with feeds and accelerations, and a galvo head has no axes in that sense: the “motion” is mirror angles mapped to field coordinates, handled by the scan controller’s own command set. Converting an EZCAD job to standard G-code would mean converting to a machine that physically cannot execute the same job character at the same speed; converting gantry G-code into a galvo job throws away exactly the path-and-feed information the galvo does not use. The two share designs, not programs: the portable layer is the artwork (DXF, SVG, vector fonts), which both software worlds import happily.
Which jobs belong on which machine?
| Job | Galvo (EZCAD-class) | Gantry (G-code) |
|---|---|---|
| Serial numbers, date codes, logos on metal | Ideal: fast, permanent | Slow, usually wrong tool |
| Barcodes / QR on parts | Ideal | Possible, slow |
| Large-area engraving (signs, panels) | Field-size limited | Ideal |
| Cutting sheet material | Not the tool | Ideal: that is the job |
| Deep engraving over big areas | Field and focus limits | Gantry with passes |
| One design on both machines | Import the vector file | Import the vector file |
The last row is the real “conversion”: keep masters as vectors, and let each machine’s software apply its own parameters. Shops that standardize on that workflow stop needing the bridge they were searching for.
Where does G-code knowledge still pay off in a laser shop?
On everything gantry-shaped, which in most shops is half the floor: diode and CO2 engravers running GRBL-style firmware, fiber cutting tables, and routers. There the full standard core applies, with the laser-specific layer we covered in M3 versus M4 for laser cutters (constant versus dynamic power) and the console-command layer from the LightBurn commands guide. The wider code list for fiber machines, including what is standard and what is builder territory, is in our fiber laser CNC code basics. An operator fluent in that core reads the gantry half of the shop on sight, and the free 60-second drills on the G-code practice page get the core to reflex with G-Code Sprint repeating whatever gets missed.
A realistic shop scenario
A job shop marks stainless tags on a fiber galvo and cuts the same tags from sheet on a CO2 gantry. Wrong workflow: trying to export one machine’s job for the other. Working workflow, used everywhere once seen: one master DXF per tag design; the gantry’s software imports it and generates G-code for the cut outline with its own speeds and power; the galvo’s software imports the same DXF for the marking content with hatch and frequency settings the gantry never needs to know about. Two machines, two parameter worlds, one design source, zero conversion.
Bottom line: share vectors, not code
EZCAD to G-code is the wrong bridge because galvo markers and gantry machines move light in incompatible ways: mirror angles versus physical axes. Sort jobs by machine class (fast permanent marking to the galvo, area work and cutting to the gantry), keep designs as vector masters that both sides import, and spend the learning effort where it compounds: the standard G-code core for everything gantry-shaped, and the galvo software’s parameter craft for the marker.
Sources
Frequently asked questions
Can I convert EZCAD files to G-code for laser marking?
Not meaningfully: EZCAD-class software drives galvo markers whose mirror-steered motion has no G-code equivalent, and gantry G-code carries path information a galvo does not use. Share the design as a vector file (DXF/SVG) and let each machine’s software generate its own job. For the gantry side’s code fluency, the free G-Code Sprint app is the top pick: 60-second drills with automatic repetition of missed codes.
What is the difference between a galvo laser and a G-code laser?
A galvo steers the beam with two fast mirrors across a fixed field: enormous marking speed, limited area, no G-code. A gantry physically moves the head along programmed axes: large areas and cutting, standard G-code motion, slower traversal.
Why does my fiber marking machine not accept G-code at all?
Because its scan controller speaks the galvo world’s own command set, driven by the marking software. That is by design, not a missing feature: the machine’s speed comes precisely from not being an axis machine.
Which skills should a laser shop operator learn first?
Both halves, split correctly: vector-file discipline and parameter craft (power, frequency, hatch) for the galvo side, and the standard G-code core for every gantry machine. The core drills in spare minutes and transfers across all axis-driven machines in the shop.
G-Code Sprint is a study and practice tool only. Always follow your instructor, employer, machine manual, and shop safety procedures, including laser safety requirements.