accuracy vs. speed - G64P?????

Discussion/questions about software used with your CNC Shark and programming issues

Moderators: sbk, al wolford

accuracy vs. speed - G64P?????

Postby albers » Thu Aug 10, 2017 9:39 am

as the topic indicates, I am after the best accuracy possible, both for profiles and hole patterns..
What is the significance of the G64Pvalue that is contained in the .tap file?
And can I control that value somewhere in the Vcarve program?
Posts: 13
Joined: Sat Jun 10, 2017 10:39 am

Re: accuracy vs. speed - G64P?????

Postby Rando » Thu Aug 10, 2017 2:52 pm


The G64 P value is the linear measurement that the tool's actual path centerline is allowed to deviate from the programmed path, in order to achieve closer-to-constant movement velocity. Use G61 to cancel this mode. When G64 is cancelled, all moves are completed with a full-stop at the exact location specified in the GCode. This can lead to very jerky movement as a full decelerate/accelerate cycle happens between each movement.

To overcome that jerkiness, the movement algorithms can be tuned so they "look ahead" to know whether a smooth arc can be made from one GCode movement block to the next. To get the smoothest movements, values on the order of 1/10 to 1/4 of the bit diameter are not uncommon. So, a 1/4" endmill might get a G64 P0.025, or 10%. That way you can be pretty well assured that the part will be within that 0.025".

When I do aluminum machining, I almost always use G64 P0.001. But, that has a downside as well, in that when doing High Speed Machining (HSM) toolpaths that have a lot of back-and-forth arcs, that required accuracy (0.001") means the bit does more of the stop/start, which gives bad bottom surface finish because of the flex and dive. But, with a finish pass added, I've been able to pretty much get rid of those back-and-forth machining marks. Sometimes, if the jerkiness is an issue I'll go up to G64 P0.003 - 0.005, but only if that toolpath can handle the increased tolerance.

I have to admit, however, that although G64 and G61 are modal, I've never tried having two different values within a single toolpath file. That would be useful if only some features had to have that extra accuracy. But, if the controller balks at the change, then obviously it won't work :).

The proper place to change the value, with the Vectric software, is in the Post Processor Files. You'll find them buried inside the software installation folder, with the G64 value near the top of the file. Yes, in some of the older Shark files it had an oddly high value (0.1"?). Copy the file to something you'll recognize, and then make the change. Avoid changing the original Post files, as your changes could be overwritten in a later software upgrade. Be sure to change the strings in the Post file at the top, so that your toolpath files will correctly show which Post produced which TAP files. If you make a MyPosts folder inside the main installation folder, and put the original Shark files along with your modified Post Processor files in there, just those will show up in the Vectric drop-down menus, simplifying life.

IMPORTANT: Using larger values on G64, combined with small clearance-plane heights can lead to gouges in the part surface. Because the controller "rounds" the corners of rectangular movements, I've noted that when the bit retracts to "safe height" and then moves horizontally, and it's trying to move up and over a "tall" vertical wall, the rounding will sometimes cause a gouge. What's important to remember here is that the Vectric and other simulators and backplotters do NOT correctly simulate the moving bit in an overly-loose value, like say G64 P0.1, and so won't know the gouge is going to happen. When this happens, you can either raise the safe height and eat the air-cutting time, or lower the P value to something more accurate (0.010" or less). Just something to watch for; if you're actually watching (or filming) the action, you'll see it. And it will absolutely drive you nuts, 'cause often it happens right on the last movement in the file. D'oh!

"Constant velocity" is the newest form of this, and I think the LinuxCNC (and thus Repetier, RepRap, and other derived motion control systems) does some form of it. The Shark controllers do not. In CV, instead of going for a circular arc at the joint, it figures out how to keep the linear velocity constant through the movement.

For reference, the most detailed explanation I could find is with the LinuxCNC description: ... ml#sec:G64
Note that as far as I've been able to tell, the Q axis is not supported on the G64 code in the NWA (ncPod and other) controllers.

Hope that helps.


===================================================== Creative tools and photographic art
A proud member of the Pacific Northwest CNC Club (now on Facebook)
Posts: 533
Joined: Tue Jan 06, 2015 3:24 pm
Location: Hoquiam, WA

Re: accuracy vs. speed - G64P?????

Postby albers » Thu Aug 10, 2017 4:28 pm

thanks, that helps me understand the function a bit more....since I am after accuracy on some very small parts
Posts: 13
Joined: Sat Jun 10, 2017 10:39 am

Re: accuracy vs. speed - G64P?????

Postby bill z » Thu Aug 10, 2017 6:05 pm

I had a pretty gud cut going but I thought it took too long, so I increased the cut speed and all of the corners that use to be square started rounding off. Really frustrating. The wood cost way more than the time I gained by increasing the speed.

Problem with the software V carve or Aspire, the result image they give does not show that the corners will change.

Thanks again Rando for the information.
User avatar
bill z
Posts: 257
Joined: Fri Sep 25, 2015 9:09 am
Location: Spring, Texas USA

Return to Software. Programming

Who is online

Users browsing this forum: No registered users and 2 guests