GRBL-Plotter turns vector files into GCode for a GRBL controller

A sender for GRBL, on Windows, on .NET 4.0

GRBL-Plotter is described as a GCode sender for GRBL, not only for lasers or plotters, and the README is explicit about the environment. It is a GCode sender for GRBL under Windows, using .NET 4.0, which the README says should also work with Windows XP, and it is written in C# with VisualStudio 2022.

That target framework is old, and that is a deliberate choice rather than an oversight. A .NET 4.0 application runs on the workshop machines that people actually own, and the requirement list names VisualStudio 2022 and .NET 4.0 for compiling. The README also notes that the Zip folder contains application files as generated by VisualStudio, at GRBL-Plotter/bin/release, and the repository holds an installer.iss file, which is an Inno Setup script, so there is a packaged installer as well as a portable build.

The audience is the person standing at the machine. A laser engraver, a pen plotter, a tangential knife, a PCB drill or a small router, all of them running GRBL, which is the firmware that turns GCode into step pulses. The program talks to the controller over a serial connection and shows you what is happening.

The project is a single person effort, with a history file, a features file, a Firmware/ directory, a doc/ directory with screenshots and a Linux description, and READMEs in English, German and Simplified Chinese. The homepage is grbl-plotter.de, and the recent releases are v.1.8.1.1 on 2026-10-12, v.1.8.1.0 on 2026-08-15 and v.1.8.0.2 on 2026-06-06, with the last push on 2026-10-12.

One detail worth noting up front, because it sets expectations correctly. The README states that the program is free and you can use it at your own risk, as you understand there is no warranty of any kind. For software that drives a laser, that is the correct disclaimer to have in front of you.

The import list is broad, and unevenly complete

The import and export section of the feature list is the longest part of the README, and it is where the real capability of the tool sits.

GCode can be loaded by file, by drag and drop, or by copy and paste, with optional replacement of the M3 and M4 commands, which the README points out is helpful for laser mode with the $32=1 setting. GCode can also be edited and saved, and there is a recent file list covering both files and URLs.

Beyond GCode there is SVG import, by file load, drag and drop, by URL, or by copy and paste, tested with SVGs generated by Inkscape, with an optional resize to a fixed size, an optional output of nodes only, which generates drill holes and is the mechanism behind the string art example, an optional sorting of paths by used color, and an optional tool change. Text has to be converted to a path first before it can be imported.

DXF import is tested with files from LibreCAD, and the README says plainly that a few entities are missing. HPGL import is supported by file load and drag and drop. There is also drill file import, CSV import, image import by file load or drag and drop, and a Gerber file import which the README labels a rough implementation.

That last pair of qualifiers is the honest core of the evaluation. Two of the import paths are described as incomplete by the author, so if your artwork arrives as Gerber or as an exotic DXF entity, the conversion is where you will lose fidelity, and the fix is to export from your CAD tool to SVG instead.

Drawing without importing: text, shapes, barcodes and QR codes

The GCode creation section is where GRBL-Plotter stops being a file converter and starts being a small CAM tool in its own right.

You can create text from a Hershey font or a Windows system font, and the project also has its own Dot Matrix font that it created. Simple shapes are there, and you can create a barcode and a QR code. There is also a route for generating GCode through tool extensions, which is the extension point for adding your own generator.

The Hershey and system font options are worth contrasting. Hershey fonts are single line stroke fonts, which is exactly what a plotter with a pen wants, because the tool follows a path rather than filling an area. A Windows system font is a filled outline font, which is what a laser needs, and the tool can produce the outline. The Dot Matrix font is the third option, and it exists because neither of the other two suits every case.

Combined with the tool change support in the SVG import, this is a coherent design. A single artwork file can be split by colour into separate passes with a pen change or a tool change between them, which is the standard workflow for a plotter drawing a multi colour drawing, and the same machinery is what a laser needs to change power settings between passes.

Import options for the geometry real machines need

The import options list is short and every entry is a real workshop problem.

Pen width can be processed as Z depth, which is how a laser is driven, and circle radius can optionally be processed as a dot, also with Z depth, which is how a drag knife or a tangential setup handles small circles. Paths can be modified for a drag knife, angle information can be added for a tangential axis, hatch fill can be added to closed paths, a closed path can be repeated for a small distance, which is what a laser cutter needs to cut through, and the graphic can be tiled.

The drag knife point deserves a word, because it is the option that makes this tool useful for vinyl cutting as well as drawing. A drag knife is dragged rather than pushed, so it cuts slightly outside the intended line, and the compensation has to be applied to the path, not to the tool setting.

The hatching option is the other one that changes the output fundamentally. A closed path drawn as an outline is a single line, but a closed path filled with hatching is a solid area, and for a laser that is the difference between engraving an outline and engraving a filled shape.

The grouping and tiling options are about output organisation rather than geometry. GCode can be grouped by graphic properties, layers, colors and pen widths, so each group becomes one pass, and the whole graphic can be tiled, which is how you take a design that is larger than the bed and split it into pieces that each fit.

The drag tool compensation is documented on its own page in the project wiki, which tells you it is treated as a first class feature rather than a checkbox.

Machine control: probing, auto levelling and camera teaching

The machine control section covers the parts of the job that happen at the machine rather than at the desk.

There is a height map and auto levelling, and a probing dialog. Individual commands can be sent through user defined buttons, and there is a joystick like control in the user interface, with support for no name USB gamepads and joysticks.

The most distinctive feature is the optional use of a webcam with a separate coordinate system. It gives you a graphics overlay of the current GCode, so you can set the zero point, measure an angle and zoom, and it adds shape recognition to make teach point assignment, in other words fiducials, easier. The README describes transforming GCode with camera aid to match a drill file with a PCB view, and links the wiki page on PCB drilling.

That is a substantial piece of engineering and it is the feature that separates GRBL-Plotter from a plain GCode terminal. Matching a drill file to a board layout normally means entering coordinates by hand from a drawing, and a camera overlay with shape recognition turns that into pointing at the thing.

There is also a serial COM window, and the screenshots show that there can be more than one, one for the CNC and one for the tool changer or the 4th axis. And the flow control section adds email and Pushbullet progress notification, so a long job can be monitored remotely.

Probing through GCode, and a second GRBL board

Two details in the flow control section are the most reusable pieces of knowledge in the README, because they work with any GRBL machine rather than only with exotic setups.

The first is subroutine support. GRBL-Plotter supports the M98 and M99 sub program call with the P and L parameters, so a program can call a routine with parameters and return. That turns a GCode file into something closer to a small program, which is how you avoid repeating the same probing or offset sequence at several places in a job.

The second is the internal variable used to support probing. The README gives two examples of the GCode that does it:

  - G38.3 Z-50		(probe toward tool length sensor, stop on contact - because of deceleration stop-pos. is not trigger-pos.)
  - G43.1 Z@PRBZ	(Offset Tool with value stored on trigger of sensor switch)

The first is a probing move toward a tool length sensor that stops on contact, with the README noting that because of the deceleration the stop position is not the trigger position. The second applies a tool offset using the value stored when the sensor switch triggers, and the README points to SerialForm.cs for the implementation.

The GRBL support section completes the picture. There is automatic reconnect on program start, support for GRBL 1.1 and also 0.9, a check for the 30 kHz maximum step pin frequency, and the new GRBL 1.1 features including jogging, feed rate override, spindle speed override and a real time display of GRBL states in the COM CNC window. The program also checks the limits of the GRBL setup, the maximum step frequency and the minimum feed rate.

A second GRBL controller can be controlled, and a 4th axis is supported using the A, B, C, U, V or W commands, with status and control, which the README notes needs a special GRBL version.

Windows first, with a community described Linux route

The platform story is short and worth reading carefully, because it decides whether this program is usable in your environment at all.

The program is a Windows application, and the requirements for compiling are VisualStudio 2022 and .NET 4.0. The README also notes that the Zip folder contains the application files as generated by VisualStudio, at GRBL-Plotter/bin/release, which tells you the release artefact is a build output rather than a source distribution.

For Linux, the README does not offer a native build. It points to a description by another user, metzger100, in the document doc/GRBL-Plotter-Linux.md in the repository, under a heading that reads GRBL-Plotter-Linux. So Linux support is a community supplied route rather than a first class platform, and the fact that the project publishes it as a document rather than as a port is the honest signal.

The repository structure supports the same conclusion. There is a GRBL-Plotter.sln and a GRBL-Plotter/ directory for the C# project, an installer.iss for the installer, a Firmware/ directory, a doc/ directory with screenshots and the Linux description, a Features.md and a History.md, and three READMEs, in English, German and Simplified Chinese.

The workflow for a Linux user is therefore: work out from the community document whether the described route works for your setup, or run the Windows program under a compatibility layer, and in either case remember that the project is a single person effort with a stated disclaimer that there is no warranty of any kind, which matters more than usual for software that commands a laser.

GPL-3.0, a fast release line, and the warranty that is not there

The licence is GPL-3.0, with the LICENSE file at the repository root. For a machine control tool, copyleft is the right default, and it means that if you modify and redistribute the program you have to publish your modifications, which suits a project whose users are exactly the people who end up forking it to fit their own machine.

The release line is busy. The recent tags are v.1.8.1.1 on 2026-10-12, v.1.8.1.0 on 2026-08-15 and v.1.8.0.2 on 2026-06-06, and the last push was on 2026-10-12, so the current build and the newest tag are the same day. The version numbers carry four components, which is a sign of a project that treats each release as a coordinated set of application, firmware and documentation changes rather than a library version.

The Features.md and History.md files at the repository root are where the details live, and the wiki holds the deeper documentation, including the drag tool compensation page and the PCB drilling page. The firmware directory is a reminder that this project spans more than the desktop program, since GRBL itself is the firmware that has to be on the controller board.

And the disclaimer is the thing to end on. The program is free and you use it at your own risk, understanding that there is no warranty of any kind. For a laser that can start a fire or a knife that can break a blade if the offsets are wrong, that is a reasonable position for a volunteer maintained tool, and it is also the reason to test any new version on scrap stock before you point it at a real job.

Editorial conclusion

Adopt GRBL-Plotter if you drive a GRBL controlled laser, pen plotter, tangential knife or CNC router from a Windows machine and you want one application to convert artwork, add the machine specific geometry and then send it, especially if you use a second GRBL board for a tool changer or a rotary axis. Do not adopt it if your controller is Marlin rather than GRBL, if you need a Linux native application rather than the community described port, or if you need a CAM package with toolpath strategy rather than an import and send pipeline. Before you start, check that your file format is fully supported, since the DXF import is described as missing a few entities and the Gerber import as a rough implementation, and read the machine specific settings export so your controller limits, maximum step frequency and minimum feed rate match your hardware.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. svenhb/GRBL-Plotter on GitHub