I use Vectric’s VCarve Desktop and GRBL 1.1 on my XXL. Though the end results are accurate, I don’t understand why ARC Movements (G2/G3) are ignored and hundreds of G1 lines are used to cut a simple circle toolpath.
After looking at the two Post Processors available for the Shapeoko within VCarve, one for mm and one for inches, I notice that all code related to ARC movements have been commented out making them invisible to GRBL. Therefore, what could have taken maybe 3 or 4 ARC movements is replaced with several hundred G1 linear micro movements.
I contacted Vectric Support and asked why the ARC Movement entries in the PP were commented out. This was their reply…
Many thanks for your inquiry.
When we last looked, although Grbl supported the input of arc moves,
the Grbl software simply converted these moves to G1 straight lines within a tolerance of the original G2/G3 instructions.
So the effect was the same whether this was done by our software or by the Grbl software.
There is less processing for the controller card to do, if the file is already converted by our software.
Coordinate System Modes: G54, G55, G56, G57, G58, G59
Control Modes: G61
Program Flow: M0, M1, M2, M30*
Coolant Control: M7*, M8, M9
Spindle Control: M3, M4, M5
Valid Non-Command Words: F, I, J, K, L, N, P, R, S, T, X, Y, Z
I guess what I’m looking for is… is there a Post Processor that will work with the Shapeoko that will generate a GCode file that will recognize and utilize the G2/G3 ARC movements???
Hey Bill,
Grbl does break arcs into linear segments on board. It does so very efficiently though.
Are you noticing performance issues? Just want your gcode to look cleaner?
Probably not much to edit the PP to allow arcs.
EDIT: Just glanced at it. You can just uncomment those sections in the Post of your choice.
Let me preface this note by saying I’ve not run any tests on the machine. I’ve simply opened the GCode files to see if they were using the ARC Moves. I then loaded the GCode files into UGS Platform to see if they look proper in the Visualizer.
Having always used the “.gcode” type files in the past. I tried the G-Code arcs (inch) last night just to see if UGS would work with a “.tap” type file. I see that there are .txt, .tap, .nc, .cnc and other types I guess. I’m assuming they must all be acceptable to UGS.
Anyway… Phil, the GCode-arcs (inch) file appeared properly in code with the ARC moves replacing the many G1 steps. Thanks. However, the Visualizer showed the circles as maybe 20 or so line segments rather than the smooth circles usually displayed. Again, I haven’t tested any of these Posts on the machine itself, but the display was unusual. Do your’s appear that way???
Last night I tried removing the comment marks on all ARC related lines in the Shapeoko Inch.gcode file. For the life of me I don’t know how I screwed up, but after I received your replies, I tried it again and it worked perfectly. The whole file only required a total of 25 instructions to draw the two circles and a line. Last night the same file must have had over 400 lines between the two circles.
Neil, at the risk of embarrassing myself, I’m guessing that even though I have a nice tidy gcode file containing only 25 lines, GRBL is still going to generate the other 400 G1 segments for the circles onboard during execution anyway???
Anyway, thanks to you both for the quick replies and suggestions.
p.s. Neil thanks again for all your help on the Automatic Tool Changer macro. I haven’t forgotten to reply to your last post… I’m still trying to digest all the new stuff you’ve given me to ponder. I will get back to you.
Yes, but it does it “on the fly”. The segments you saw on the other post may have to do with an “arc tolerance” in V-Carve. By letting grbl handle it, the tolerance for arcs is pretty tight. You can adjust it, but there’s really no need.
So when you loaded the file created with the G-Code arcs PP, you got line segments in the visualizer. Then you edited the Shapeoko PP file to uncomment the ARC lines and created the same file and the visualizer didn’t show line segments?
What is in your Vectric file, are we talking about a circle of X diameter or something?
I would be interested in replicating what you’ve done, if possible.
So when you loaded the file created with the G-Code arcs PP, you got line segments in the visualizer. Then you edited the Shapeoko PP file to uncomment the ARC lines and created the same file and the visualizer didn’t show line segments?
The Vectric Source File (.crv) is not authorized for upload.
I’m including…
Vectric Source File screenshot and .GCode file. (I had to change .gcode to .tap in order to upload it as .gcode is not authorized. This is the PP that I “un-commented” the ARC related lines.
Vectric Screenshot of tool paths. Top circle profile outside line. Diagonal line profile on line. Bottom Circle profile inside line.
@Signdude Is that the same scale in UGS? Both inches? Gcode is essentially the same, but the “G-Code Arcs” doesn’t define a unit. Throw a G20 at the top of that one and see if you see the same.
That was it. Evidently, the Gcode Arc Inch is defaulting to millimeters. I inserted the G20 code at the top of the .tap file and opened it in UGS Platform. The circles looked normal in the Visualizer.
The following is from the top of the Gcode Arc Inch PP. There was no mention of a G20 in the PP file.
I added the G20 to the HEADER section, generated a new .tap file which placed the G20 at the top and it ran perfectly.
begin HEADER
“G20”
“T1M6”
“G17”
“G0[ZH]”
“G0[XH][YH][S]M3”
I guess since my job was setup in “Inch” mode, the PP “assumed” MM and generated larger G91 segments causing the distorted circles.
Problem solved.
HOWEVER… Just for kicks I thought I’d run my “inch” file through the GCode Arc MM PP.
I fully expected to see the Visualizer results that I got without the G20 code.
WRONG!!! The circles looked perfect, just like the circles from the GCode Arc Inch PP with the G20 code.
I’m tired. Think I’ll try to figure that one out another time.
It’s all just scale. Grbl, and probably UGS, default to mm. When your inch gcode was generated without the unit modal (G20), those fractional inches were interpreted as fractional mm. Everything is 25 times smaller and, therefore, not as smooth. The mm post processor made your unitless values 25 times bigger, so they looked smoother.
That said, I think @WillAdams is right and it’s probably a UGS rendering thing. I’d use the post that explicitly defines the unit (or add that).
