Gantry

Study

Gantry started from a simple annoyance. CNC has CAM software and G-code senders. Pen plotters often get scripts, plugins, and a lot of careful human glue.

I wanted one place where artwork becomes a safe physical plot.

That sounds smaller than it is. The tool has to know the bed size, the origin, the pen lift, the paper position, the drawing scale, the plotter backend, the travel moves, and the moment where a preview stops being harmless and a machine starts moving.

So Gantry became the missing middle for my plotter work: part plotter CAM, part G-code sender, part small plotting studio. It supersedes my older endpoint tools, SVGToolBox and SVG2WaterColor. Those were useful experiments. Gantry is the current endpoint.

The drawing can come from Generative Art, CityPlot, VHS, Tracer, Vectorize, Inkscape, or a plain image file. Gantry is where that input becomes a job.

What it does now

The repo has moved past the first “can this make G-code?” question. It can.

The current app can:

• import SVG files
• import raster images and turn them into plottable SVG
• run image-art processors with live preview
• run the SVG preparation work that used to live in SVGToolBox
• position, scale, rotate, and mirror artwork on a virtual bed
• flatten curves into plottable polylines
• optimize stroke order
• run optional multipass plotting
• handle optional watercolor stations and brush refill logic from SVG2WaterColor
• export G-code or stream it over serial to a GRBL controller
• run a mock backend for no-hardware testing
• save projects and recover unsaved work
• report plot metrics such as command count, draw distance, travel distance, estimated time, tiny segments, and warnings

The current question is more annoying:

Can someone else download Gantry, follow the safe path, complete a mock plot, and then produce useful G-code or a small real plot without me standing next to them?

That is the adoption problem. It is less glamorous than another geometry feature. Also more useful.

Image import became real

For a while, “image to plotter” meant passing a raster image through a separate vectorizer and hoping the output behaved. Gantry now treats image import as part of the same plotter workflow.

The experimental image-art modes include:

• squiggle shading
• oriented needles
• tonal isolines / topographic contours
• sketch / blueprint trace

These are fun. They are also dangerous in the boring plotter sense. A processor can make a nice preview and still produce a ridiculous amount of pen-up travel, tiny segments, or plot time.

So the new work has two jobs: make images look interesting, and make the generated plot sane. Gantry measures the generated job and reports warning values. If the travel ratio is too high, the warning says how high. If the job has too many tiny segments, the warning gives the measured count.

That makes image-art modes reviewable. Less “looks nice on screen”. More “will this waste an afternoon and murder a fineliner?”

Why Gantry sits after Inkscape

Inkscape is good at drawing. I use it for drawing-shaped work.

A plotter job is machine setup. That is a different center of gravity.

The old plugin-shaped route made the machine feel like an afterthought. It kept the workflow inside a program whose main job is editing artwork. For quick export that can be fine. For repeated plotting, GRBL setup, pen lift modes, bed positioning, job preview, export, replay, cancellation, and future pressure or watercolor experiments, I want the plotter to be the center.

Gantry moves the center to the plotter.

The pipeline

Artwork or image
  → prepare SVG / vectorize image
  → place on machine bed
  → flatten to command model
  → optimize / multipass / optional watercolor refill
  → preview and safety check
  → export G-code or stream to GRBL

The important part is the command model in the middle. SVG remains the artwork format. G-code is the machine output. Between them Gantry keeps a model of layers, moves, draws, refill commands, placement, settings, and warnings.

That middle layer answers practical questions:

• Does this fit on the bed?
• Where will the pen travel without drawing?
• Which layers should plot with which pen?
• How long might this take?
• How many tiny movements did this image processor produce?
• How will the pen lift?
• Can I export the same job again?
• Can I stop without dragging the pen through the paper?

Boring questions. Exactly the kind that matter when motors start moving.

What changed from the older tools

SVGToolBox taught that artwork is rarely plot-ready. Fills need hatching. Colours need to match actual pens. Paths need simplification, sorting, merging, and sometimes a stern talking-to.

SVG2WaterColor taught that plotting is more than SVG export. Once brushes, paint stations, refill distances, and machine moves enter the picture, the problem becomes a command model.

Those two tools also taught the less romantic lesson: splitting preparation, command generation, and hardware control across tools makes the workflow fragile. Coordinates drift. Settings get repeated. One program knows the drawing. Another knows the machine. The human in the middle becomes the integration layer.

I dislike being the integration layer.

Gantry pulls the useful parts into one Java 17 / Maven project with one GUI, one coordinate model, and one hardware path.

Safety and first plots

The docs care a lot about first-run safety now.

There is a mock backend, a setup wizard, safe import defaults, a pre-plot check, jog controls, GRBL troubleshooting, release checklists, and a known-good setup matrix. The matrix should stay evidence-based. Empty is better than fake confidence.

A plotter looks harmless until it moves in the wrong direction with a pen down. Then it becomes a small, confident vandal.

So the current study is partly about software architecture and partly about trust. Can the preview match the plot? Can stop and cancel leave the pen up? Can a first-time user tell when nothing will move and when something absolutely can move?

That matters more than another fancy processor.

Current state

The repository already contains the main structure:

• model: shared drawing and command data
• svgtoolbox-core: SVG preparation processors
• pipeline-core: SVG import and command-model work
• vectorize: image-to-SVG front stage and image-art processors
• watercolor: optional station and refill logic
• plotter: mock, G-code file, serial GRBL, and replay backends
• cli: headless conversion, metrics, and G-code export
• app: Swing / FlatLaf GUI, projects, recovery, history, visualization, and help surfaces

There is a 1.0.0-rc.1 pre-release on GitHub. It has GUI and CLI JARs, checksums, the README, and the license. It still assumes the user understands Java. That is the next packaging problem.

The roadmap now says the active work is beginner usability and adoption. The core workflow exists. The useful proof now is outside the code: real hardware acceptance, known-good setup entries, novice walkthroughs, screenshots, demo material, and release artifacts that do not require knowing what Java is.

Storefront, eventually

The GitHub repo is the workshop shelf. It has the source, issues, releases, checksums, and docs.

A public download page should be simpler. One page for someone who wants to try Gantry without reading the repo first:

• what Gantry does
• latest recommended download
• how to try mock mode with no hardware
• what Java/runtime assumptions remain
• first-plot guide
• safety notes
• link back to GitHub for releases and source

That page should be honest about Gantry’s rough edges. It should make the first safe attempt less weird.

Next

The next honest work is packaging and evidence.

First, make the release page easier to understand. Then make the packaged app easier to run. Then record a real hardware pass for the current setup and put it into the known-good setup matrix. Then let someone else try the mock workflow from the release page and first-plot guide. No coaching if possible. Every confused pause becomes either a docs fix, a UI fix, or a sign that Gantry still assumes too much.

The pressure path from Tracer and VHS can wait until the ordinary plotter-CAM problem is less wobbly. If Gantry cannot make normal pen plotting feel sane, pressure-aware plotting will only make the mess more expensive.

Source: github.com/utrost/Gantry · Releases: GitHub Releases · License: AGPL-3.0

See also: From Pixel to Pen, Tracer, VHS, Ductus, PPCT, SVGToolBox, SVG2WaterColor, Generative Art, CityPlot, Vectorize, Primitive, Studies