We use cookies to personalize content, interact with our analytics companies, advertising networks and cooperatives, and demographic companies, provide social media features, and to analyze our traffic. Our social media, advertising and analytics partners may combine it with other information that you’ve provided to them or that they’ve collected from your use of their services. Learn more.
I’m on a recent build of grbl 0.9i, and I’ve run into problems trying to cut circles. I made a simple test pattern of a 4" square around a 3" circle. However, when it goes to cut the circle, it just traverses to the four cardinal points instead.
Instead of cutting on the blue path, it follows the tan inner diamond path instead. If I run the simulator, it too follows the tan diamond path. Is there some trick that I don’t know about? Or possibly something in the post-processor? Here’s the gcode I’m trying to run:
Long version:
I was comparing post processors last night to see what the differences were in how they handled tool changes. I was using V-Carve with the included G-code processor, the grbl processor, and the X-Carve one that I added from somewhere on this site. I made three different files from the same small project, which just happened to have a few arcs in it.
I saw your question this morning and pulled up those three files. I just did a quick scan of all three to look for G2, and only the X-carve processor has it. The file I produced with the grbl post processor doesn’t do arcs. The two programs are fairly identical until they get to a point just before the first arc, and then while the X-Carve does this: G2 X1.4071 Y3.4200 I0.5921 J-0.3543 , the grbl file does this: G1X0.7910Y3.0969 (followed by a gazillion other little straight-line cuts. So it looks like maybe grbl doesn’t do arcs the same way or doesn’t support the G2/G3 commands.
If you’re bored enough, I can upload all three g-code files I produced and you can compare them to see what other surprises await.
Hmm, it’s good to know I can use the grbl post-processor to avoid the arcs. I’ve been converting my projects between standard and metric, and that seems to break up the circles into their gazillion-line counterparts.
The grbl FAQ states that they support G2/G3 commands, and I tried the TinyG version of Chilipeppr as well, and it did the diamond thing too. Maybe arcs are a relatively new part of grbl, and Chilipeppr hasn’t had enough time to catch up yet? Maybe @JohnLauer can weigh in on this when he gets a chance. I guess I should fire up Easel, add a circle, export the gcode, and see how it handles them.
For now I’ll switch to using the grbl post-processer, probably a more elegant work-around than my unit conversion hack.
I’m using Aspire, so it’s just a workspace setting for each project. I usually draw up my projects in imperial units, but after a mishap of running an imperial project in Chilipeppr and then issuing a G0x100y100 command (and then diving for the power switch), I now run all my projects as metric.
But while I was in the process of switching over to metric, I noticed that one of my test patterns that used to draw a diamond instead of a circle, suddenly started drawing as a circle after I did the conversion. I compared the gcode files and saw that it had switched from G2’s to G1’s, so I started using it as a circle-fix as well.
That’s a good one to remember - thanks! I’d never considered what would happen if I was running a file in one measurement, and then manualy input a command in another. That wouldn’t have been pretty.
At least with aspire it’s as simple as clicking a few buttons to save a new file.
Yep, I’ll do that as soon as I get home. Could you try saving the above gcode and drag/dropping it into Chilipepper if you get the chance? It should attempt to traverse 1 inch on both the +x and +y axes, and then make a 4" square, with a 3" circle inside (technically it does the circle first I believe).
I find it odd that the simulator in Chilipeppr both shows the circle it should be making, but then makes the straight line cuts that I’m seeing, but perhaps that’s just an artifact of the simulator vs a real machine. Thanks for looking into it!
Grbl supports G2/G3 arcs. Always has and reliably as well. So, no problems there.
I do know that Chilipeppr has some known issues with G2/3 arcs and displaying them in the visualizer. Historically, weird problems like this are usually caused by the GUI doing something weird to the gcode before it’s sent to Grbl. For example, UGS sometimes pre-filters and translates gcode as its being sent and when there is a bug, it cause really strange problems. Chilipeppr also does a lot of similar things, so it wouldn’t surprise me if something like this is happening.
To rule it out, I always recommend Grbl users to rule out the GUI by trying different GUIs for the same tool path. If you can, use the officially support Grbl streaming python script, available in the main Github page.
The ChiliPeppr simulator does NOT simulate the G2/G3 paths but rather just goes in a straight line from the start/end points, but that is NOT how your job will come out. Cut an air job and you’ll see your CNC controller does follow the arc correctly. CP does need to get an update to simulate these G2/G3 paths better, but there have been difficulties getting arcs to truly render correctly in all instances with some edge cases. However, I think things have stabilized in the last couple of months and that CP now has a 99.9% implementation of G2/G3 rendering such that it could be time to add the path following to the simulator now.
As for sonny’s comment, ChiliPeppr does not modify any gcode lines other than 1) it asks you to specify mm or inches if you didn’t have those in your gcode, and it then adds a line at the top with your answer and 2) it comments out any % lines because those mean kill cycle rather than what some CAM programs assume.
Thanks for the clarification John, but I still categorize adding G20/21 inches or mm mode or ignoring ‘%’ character as modifying the CAM generated g-code program. Or auto-leveling that changes the z-positions throughout the gcode program. Or allowing users to indicate a new start point in the middle of a g-code program.
If the g-code state isn’t carefully managed and returned to its original state after such a modification, there’s a chance that the g-code program could do something that the original didn’t intend. The g-code canon is so mode-dependent, you really have to know exact what you are doing and when you are doing it. This is usually the main cause of weird problems that I mentioned in my last post.
It turns out that $12 was set to 0 on my machine. The only changes I attempted to make to my grbl settings were for hard/soft limits, but it turns out that the address for the hard limit value is $21, so I’m sure I totally entered that one as $12 during my testing. I set it back to .002 and it’s making circles like nobody’s business
