topic Re: 2d Chamfer unexpected results in Fusion Support Forum

2d Chamfer unexpected results

gtprototype — Wed, 20 Mar 2019 05:32:59 GMT

2D Chamfer sometimes produces unexpected results. When chamfering several items, sometimes a hole with not complete the circumference. I've ran into this once before where the first hole completes fine and the second one is incomplete. Comparing the g-code of the first and second hole, it appears the lead in is causing the problem. I've attached the fusion file, a reference sketch and the g-code for review.incomplete hole chamfer on rh side.

Re: 2d Chamfer unexpected results

karina.harper — Wed, 20 Mar 2019 16:27:57 GMT

Hi @gtprototype

Everything in the CAM looks correct to me. It seems like something may have gone wrong at the machine side - personally it looks like the part may have moved but it's hard to say.

Also, if you post this over in the CAM forum you'll get some good answers as well - there are some great experts there! @seth.madore might be able to help here.

Cheers,

Karina

Re: 2d Chamfer unexpected results

seth.madore — Wed, 20 Mar 2019 16:35:49 GMT

Thanks for tagging me @karina.harper 🙂

@gtprototype what is your machine and controller and what are you using for a post processor?

Re: 2d Chamfer unexpected results

gtprototype — Wed, 20 Mar 2019 19:32:10 GMT

Karina,

Thank you for having a look and enlisting Seth's help. FYI, The work around was to post only that chamfer and re-machine; the concentric results confirmed that the part didn't move.

Seth,

Looking at the g-code you can see the lead-in is different from the previous hole, specifically on the previous hole the lead-in ends at the start of the interpolated arc; with the problem hole, the lead in doesn't end at the start of the interpolated arc. This I believe is a problem within fusion; and is perhaps related to the random problem you eluded to in this post here. An additional observation although, not problem some, is that the lead in on the previous hole is directly along the x axis and the second one is not.

My machine, a vintage Hurco (circa 1985), uses the Hurco BX control. You can download my post here.

Studying the documentation for the Hurco BX control, I found why my control doesn't overcome the problem: the line preceding the G2/3 sets the start point for the interpolated arc. As you can see from the g-code snip-it below there is a discrepancy with what my control sees as the arc start. A more modern control would probably not hiccup with this minor discrepancy since the arc start is repeated after the G3.

N200 X3.8275 Y-0.5614 F12.
N205 G3 X3.8275 Y-0.5625 I3.7825 J-0.5625

I believe the problem is within fusion; correct me if I'm wrong, the post doesn't alter the coordinates just presents them in a manner that the control can use, right?

Re: 2d Chamfer unexpected results

gtprototype — Thu, 21 Mar 2019 01:52:19 GMT

I've been using other posts and comparing the g-code. My previous understanding of what's going on is clearly flawed. Please accept my apology for speaking authoritatively on something that I only thought I understood. It wasn't until I saw the interpolation limited to 180° arcs that I started to understand how the control may actually process the g-code. When I plotted the movement I found that, what I would imagine is obvious to someone who routinely examines g-code, the line before the G2/3 defines the start point and the G2/3 is followed by the endpoint before the arc center I&J. With this new understanding I can see that the start and end points are not the same and when I plot the values the arc is only 358.59° I found similar results with the output from other posts; which I believe supports my previous conclusion there is a problem within Fusion however, not likely the source of my problem.

The question remains why doesn't my control process the 358.59° arc? The only discrepancy I can find, which should be of no consequence since my control rounds to 4 decimal places, is that the radius length of the start point is .0000135 different from the radius of the end point.

Re: 2d Chamfer unexpected results

seth.madore — Thu, 21 Mar 2019 11:23:47 GMT

Controls process code differently. Most modern machines will accept arcs up to 360 degrees, whereas many older machines are limited to 90 or 180 degrees max arc.

One other thought/comment: my Mori would accept code for threadmilling just fine, but my Kitamura would flake out on that same code. It would skip one whole revolution and just move up in the Z. It was traced back to a rounding error where the post was rounding off at 5 decimal places. Logic was inserted my Kitamura post to produce exact numbers. This cured it, but it's worth mentioning that swapping to 180 degree max arcs also would have cured it.