Optimized Vinyl Cutting Tool Paths (for sharp corners)

I have been exploring vinyl cutting with my Shapeoko 4. While ‘smoothed’ tool paths work fine with the drag knife approach/holder I’m using (see DIY Vinyl Cutting Drag Knife for Desktop CNC | MCU on Eclipse) I faced issues with ‘sharp’ corners.
I have found a solution with generating an optimized tool path using ‘swivels’ using dxf2gcode and the corresponding settings so it can be used with Carbide Motion.
I have documented it in my blog (Optimized Vinyl Cutting G-Code Tool Path with DXF2GCODE | MCU on Eclipse), and if you try vinyl cutting, I hope you find that useful.
Result I achieved (metric cm/mm scale):

I hope this helps,


Thanks for sharing, I had no idea dxf2gcode had a dragknife option to add swivel moves. Pretty sharp results you got there. And nice blog too. Software engineer with a Shapeoko is a thing, you’ll find likely-minded folks here :wink:


Thanks, good to see likely-minded folks here :grinning:. What I’m still working on is a thing about the feed rate (F codes): DXF2GCODE puts them on separate lines/commands, and somehow the machine does not like them (moving slow). Manually increasing the feed rate in Carbide Motion is the workaround, but I would like to find a proper solution.
There is a similar thing going on in the following discussion: Feed Rate Too Low - #7 by Julien

Allright, my interest was piqued so I checked, and apparently

  • GRBL itself will gladly accept a standalone F command
  • but Carbide Motion will filter it out
    • With the Log window open, if I use the MDI to send “F500”, nothing happens
    • if I use the MDI to send /F500 (the slash forces CM to send the command unprocessed to GRBL), the F500 does appear in GRBL console and is acknowledged (“ok”)

This is one of those things that CM filters, I couldn’t say what the rationale is for that specific case, @robgrz should know (and can decide whether or not he’d like to remove that behavior)

In the meantime, as a workaround you could post-process the generated G-code file to artificially add a X/Y/Z coordinate in front of the lonely F command, like @fenrus mentioned in that other thread. Or use a different G-code sender.


Thanks for checking, really helpful.
I have created a workaround now with adding F codes for each move generated:

Not ideal, but seems to work well.
I will update the blog article about it too.


You won’t need the feedrate on the rapids.

You could always use a different sender.


dxf2gcode and a few other tools are mentioned in the context of drag knife support on the wiki:


FWIW, I’ve been programming this sort of thing by hand in G-Code (see the wallet I posted a bit ago) — tedious, but it works.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.