G-code created for Mach 3 has numerous G3's

[mwloyd]

I changed my toolpath to a smaller diameter and the g-code it created has numerous G3 blocks with extra info added to the line in Mach 3. I saved as Mach 2/3 Arcs inch .txt. I edited the code and changed all the G3 to G2 and deleted all the extra characters but it took me 3 hours. Though I really don't know what I was doing, it worked great. I want to experiment with profile settings, but am not looking forward to editing the G-code again. Is there a better way to create the file and save to Mach3

[PaulRowntree]

I don't follow what you are saying. Both G3 and G2 move the tool in arcs, but in opposite directions, so I have no idea why you would do this, nor how it could possibly work well. Could you please post the before and after gcode, and perhaps the crv file that created the code?

Did the original G-code work? What prompted you to manually edit it?

[mwloyd]

Excuse me, I changed the G3 to G1. The G3 blocks didn't look like they belong in the sequence. I thought it might confuse my machine. I read that G3 is not used generally. Mach was telling me there were G3's in the code so I didn't try to run it. I am just learning and playing. I did notice a spike in the toolpath display where one line jumped a couple of inches off the path and I was able to edit it. Some other lines weren't complete, so I filled in the gaps. The path I am profiling is a tree with lots of branches so it has alot of back and forth with sharp turns. I just don't trust that V-Carve Pro is processing the code properly to Mach 3. There are 27000 lines so I can expect some glitches?

[dealguy11]

I've sent projects with millions of lines of code to Mach3 from Vectric products with no problem, including G3's. A G3 is just a counterclockwise arc. Why Mach3 would warn you about this is beyond me. If your software handles arcs (and Mach3 does) it is actually BETTER to have the G3's because the alternative is to not use one of the "arc" post-processors and get curves as hundreds of short lines instead (all G1 commands). I also have to say the the only time I ever look at the gcode produced by Vectric is to make sure I got the tools and speeds right. I've never had an issue where the code produces different results from what's in the preview (except for machine or operator errors).

Are you sure the jump in the code wasn't just a move to another part of the job?

[Adrian]

You should just trust that VCarve will produce the correct code. I'm confused as to why you say you don't trust VCarve to produce the correct code but you trust yourself, when you say you don't know what you're doing, to change the code correctly.

[PaulRowntree]

I think that the only time I have looked into the details of Vectric's gcode was to learn how to do things correctly ...

Mach3 can sometimes complain if it is using absolute arc conventions and the code is using incremental (inc is better) or vice versa. Vectric uses incremental , so set this into Mach3 (Config -> General Config menu item brings up the dialog box)

[mwloyd]

Thanks for the bashing. Basically my question was...when I changed my tool diameter smaller and recalculate, why would I now have G3 added throughout the code? I have mounted a hotwire arm to my spindle plate and am experimenting with pretty good results. So we are talking about very small diameter. I have no need for Z movement for this process. Thanks for the constructive information also.

[Adrian]

Most likely the smaller bit could fit into areas defined by arcs in the vector that the large tool couldn't.

Have a look at the attached example. The 0.25" toolpath won't generate any G3's but the 0.125" one will.

If you check the Solid option next to the toolpath preview you will be able to see where the bit reaches in the preview.

[mwloyd]

I am on Mac and can't view or open crv file right now, but sounds like a good answer. I have a small negative offset to try to get into some even tighter places. I will try the on path option and see how that does.