I’m saving a Gcode file from a Vcarve project. I don’t know which Post Processor CM uses. According to the VCarve Forum, I should select either the “Shapeoko Inch” or the “Gcode inch” PP before I save my Gcode file to disk.
Doing so produces a file with the extension of either “.gcode” for the “Shapeoko Inch” PP or “.tap” for the"Gcode Inch" PP.
Both files open with Notepad and display what looks like nearly identical Gcode format with a couple minor exceptions…
“Shapeoko Inch” begins with
“Gcode Inch” begins with
I understand these codes and know that the G20 would have been redundant in the “Gcode Inch” file.
Other than that the only other difference between the two was…
“Shapeoko Inch” ended with M02
"Gcode Inch" ended with M30.
So I guess my question is… Can I just change the filename extension to “.nc” to make either of them acceptable to Carbide Motion?
Yes, changing the file extension should be all that’s needed — what is the default extension which VCarve uses? We should add that to CM.
Thanks for the reply William.
I’m at work right now, I’ll check and reply this evening.
Did a little checking and found that the default for VCarve is the Mach PP. They say the following…
“This one allows it to halt for manual tool changes and manually setting the tool Z zero, then resume cutting.”
You select your PP just before saving and their list shows dozens, many with Inch and mm versions.
I still didn’t catch which one is used by CC???
There’s a bit on this on the wiki: http://www.shapeoko.com/wiki/index.php/Commercial_Software#2.5D_CAM
Software for 2D design and calculation of 2D and 2.5D toolpaths for cutting parts on a CNC Router. They also have Aspire, which is “built on the same platform” as well as the hobby-oriented Cut2D 1.5. A set of Post Processors is available at the following forum post Vectric Aspire Post Processor. Alternately use the ‘g-code (inch) (*.tap)’ post processor — put the code G20 at the beginning for inches. ShapeokoPP.zip
Nomad post-processors by Mark Bellon (mbellon on the Carbide3D forums):
Vectric Aspire Post Processor for SO3
v8.5 and later include a Shapeoko pre-processor.
Further discussion at:
Drag Knife Support.
Vectric Aspire Post processor for Laser engraving
Reddit: ShapeOko3 ordered. Question about Aspire
Paul Rowntree: Gadgets for Vectric’s Aspire 4 and V-Carve Pro 7
On my Nomad Pro, I use the post-processor written by @MechanicalGoose and linked on the Shapeoko Wiki, with a few edits (change UNITS=“INCHES” to UNITS=“MM”, change " G20" to " G21", remove line containing only " %"). It’s been rock solid for me with VCarve Desktop 8.5 and Carbide Motion. The file extension is part of the post-processor definition, and this one uses “.nc”.
(the switch from inches to mm works around a GRBL error that can show up in tight curves)
Thanks for the replies guys.
I have no idea what a "pre"processor is. Could someone fill me in?
I would still like to know what "post"processor Motion uses. :::
Pre and post-processor are used somewhat interchangeably.
In this case, the situation, as I understand it is this:
- the CAM application has some internal representation of the paths which it wants the cutting tool to make
- there exists some library of pre/post-processors which define how given machines/controllers expect G-code to be provided — what preamble should be used, what code should be placed at the end of a file, what commands are legal, what forms of legal commands should be used
- when one writes out the G-code file, one selects a pre/post-processor which is then applied to the internal representation so as to instantiate it as a compleat G-code file, appropriate to, and compliant with the expectations of a particular machine / controller, for a particular setting (here I’m think in particular of the inch/metric dichotomy
It may well be that multiple post-processors will work well enough for a given machine, while it might be that another will only accept one.
Carbide Motion would like to see G-code written out with a post-processor which is:
- appropriate to Grbl
- limits G-code to that which Grbl understands, or which Carbide Motion implements support for, in a format which Carbide Motion will allow (here I’m thinking of the need to have a Feed rate on each line)
- will provide tool commands where appropriate and have suitable comments which Carbide Motion may then use to inform the user as to which endmill should be inserted
- limits line lengths to the 70 characters which Grbl supports (if nothing else, providing files so formatted will remove the need for Carbide Motion to trim them)