Help taming G64 (exact stop). Wildly inaccurate parts right now

More
24 Oct 2020 11:55 #187099 by the_wildgoose
Hi linuxcnc gurus. I wonder if someone can lend me their experience understanding how to set G64.

My problem right now is with slotting type moves that change height. I had a 2mm endmill and a toolpath programmed in Fusion which literally just slots back and forward some 10mm or so, ramping down 0.5mm on each pass. Nothing crazy, backplot shows it's the right toolpath. Crazy thing is that when I ran it the slot was several mm too short and there was some part cut tabs for the rest of the slot.

I turned the backplot to look at it in the side on plane and the problem is clear. Fusion has programmed the ramp down to coincide with a direction change. So something like it ramps down into the left most corner of the slot, then it should come to a stop there at the new level and reverse direction and do a complete traverse of the slot at that level. Re-stated, it's ramping down to the right to the new level, once it's at level it traverses to the left at that level. So there is a sharp V shaped corner in the toolpath

However, linuxcnc wants to cut the corner... So some few mm before the ramp down finishes it's horizontal move, linuxcnc starts the acceleration in the opposite direction (completing the vertical ramp in the wrong direction effectively, and missing a few mm of my slot)

I've attached a photo of the path vs the backplot

OK, now adding a G61 obviously cuts the correct toolpath, but then the rest of my program runs very roughly...

I have no idea how to insert G61/G64 into the middle of a fusion360 program (other than opening it up and editing). However, would be interested if anyone has pointers?

I feel it should be possible to set the parameters of G64 to prioritise velocity over path error? Is this as simple as "G64 P0.01"? What are sensible values for Q in that param? Any other tips or pointers with regards to trying to find a single number which will work for "most" of my programs?

With the default settings my paths are several mm incorrect on what feel like pretty slow feed rates (200mm/min or less). Are there any other params that feed into the path planner other than the individual axis accelerations which could be causing this excess rounding?

For reference the machine is a little 6040 alike from Omiocnc. I have my units set in mm and current accelerations are 1000 in x/y and 750 in Z. I've not tried to tune these yet. (are they in the right order of magnitude?)

Wisdom from the experts gratefully received!

Attachments:

Please Log in or Create an account to join the conversation.

More
24 Oct 2020 12:35 - 24 Oct 2020 12:37 #187100 by Aciera
Hm, this looks odd to me. My machine has a max acceleration of 300 and I never had a problem like that running at 200mm/min. Can you post your HAL and INI files?

Also what kind of motors? Is there a feedback coming in like from encoders?
Last edit: 24 Oct 2020 12:37 by Aciera.

Please Log in or Create an account to join the conversation.

More
24 Oct 2020 17:01 #187116 by Todd Zuercher
You may be better off just using G61 in that situation

Please Log in or Create an account to join the conversation.

More
24 Oct 2020 19:49 - 24 Oct 2020 19:53 #187124 by the_wildgoose
Hi, thanks for your response. Yes, it's such a large error that I suspect a config issue. You can definitely see from the shape of what it actually did (and that it's perfect with G61) that it's a trajectory optimisation thing, but it feels like it's gone wrong or needs a better G64 config to me?

The machine is using some simple steppers. Here's a link to the manufacturer (it's an above average 6040 type machine)
www.omiocnc.com/products/x6-2200l-usb.html

Main conf files:

Warning: Spoiler!



Warning: Spoiler!
Last edit: 24 Oct 2020 19:53 by the_wildgoose.

Please Log in or Create an account to join the conversation.

More
25 Oct 2020 02:00 #187155 by Todd Zuercher
Is Fusion using G64 with no P tolerance? If so that equals maximum path blending with no tolerance. Using A G64 P0.01 or an even smaller P value will help immensely.

There is no reason you can't insert G61 and G64Pnn commands anywhere within a g-code file. Changing from one to another is allowed and will not cause any problems. But you would likely have to insert them by hand with a text editor. I've not run into any CAM program that could do it automatically.

It is often a big enough challenge just to get them to insert the right one at the start of the file once.

Please Log in or Create an account to join the conversation.

More
25 Oct 2020 13:44 #187189 by the_wildgoose
Actually the default output from the CAM doesn't include any G64/G61 at all, so it's whatever I have at that moment on my machine. Temporarily I have been splitting my program up into 2 parts and running each with different settings (or hand editing the pre-amble at the top of the file.

So yes, it's definitely using a straight G64 no P tolerance. Can you guide me on setting a reasonable P value (and Q?) though? Why is the error quite so far out without any P tolerance??

It seems like I should be able to accelerate this machine more closely within the tolerances than showed up in the backplot vs actual here? I feel that the machine has done something like connecting the Z and X velocities and it's trying to get the X direction reversal done within the Z travel remaining, hence it's got to abort the move early. However, even then it feels like it's also got some large tolerance that it's working in, since surely it could get that move done closer to the end of the point??

If I use G64 P0.01, does that mean that it will track to within 0.01 of the pointy end of that toolpath? Presumably then compromising on velocity if needed in order to hit the required toolpath? Are there any obvious negatives to this (on soft materials such as aluminium)? ie is it sensible to set a default machine pre-amble to G64 P0.01?

As an aside, it took me until this error to realise what was wrong with all my engraving toolpaths... They all looked a bit wobbly before and the ends of letters like capital L were very slightly truncated. G61 and they are now perfect. I guess because I was rapiding out of the stroke, linuxcnc was trying to blend that move into the toolpath move and hence rounding the ends of the stroke. Simple once you realise what is going on...

Please Log in or Create an account to join the conversation.

More
25 Oct 2020 15:36 #187200 by Todd Zuercher
Without a p tolerance the rounding can consume up to half of the shorter of the 2 segments or whatever allows the machine to maintain the programed federate with your acceleration setting.
I'm not sure exactly how the tolerance works but I believe it is the distance from the end point where the blending arc begins. So the measured deviation will be a bit less.

Please Log in or Create an account to join the conversation.

More
26 Oct 2020 12:56 #187303 by Todd Zuercher
Also the default setting in Linuxcnc when you first turn it on is G64 with no P. It is an extremely good idea to include a G64 command with an appropriate P tolerance in the preamble of all of your g-code files.

On our wood carving routers running in inches mode I use G64P0.005. For a metal milling machine P=0.0001 might be more appropriate (or P=0.0025 on a metric machine.) It is often a good idea to experiment a bit to find the right balance of speed and accuracy. You might find a large P value is best for roughing passes (to maintain a more constant feed rate), then use a small P for the finish pass to hold a tighter tolerance.

Also having low acceleration limits programmed in the machine configuration will exacerbate the problem. So don't be too conservative when choosing them.

Please Log in or Create an account to join the conversation.

Time to create page: 0.185 seconds
Powered by Kunena Forum