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):
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
Thanks, good to see likely-minded folks here . 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.
. 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.