Broke the cutter with Line/Arc filtering

[Shiva.aero]

Hello all!

I introduced Line/Arc filtering for the program which we were cutting regularly, after watching this video:

I just activated Line/Arc filtering & smoothing (5%)  without altering any other parameter. Impressively it reduced the no. of code line from 215000 to mere 85000. However when I ran on the machine, the cutter broke! Once again I tried with another cutter & once again it broke!

I understand many other parameter like tool runout, coolant, etc., could have caused it, but I like to understand the influence of line/Arc filtering on the tool wear & tool load. 

1. It's a roughing program and I activated smoothing option (just 5%). Could it be the problem?

2. Is it possible that, with the G2 & G3 the machine tool could accelerate really faster compared with the normal G1 codes, which caused increased chip load?

3. Is there anything else I should take care while using line/Arc filtering?

Thank you!

[crazy^millman]

50 minutes ago, Shiva.aero said:

Hello all!

I introduced Line/Arc filtering for the program which we were cutting regularly, after watching this video:

I just activated Line/Arc filtering & smoothing (5%)  without altering any other parameter. Impressively it reduced the no. of code line from 215000 to mere 85000. However when I ran on the machine, the cutter broke! Once again I tried with another cutter & once again it broke!

I understand many other parameter like tool runout, coolant, etc., could have caused it, but I like to understand the influence of line/Arc filtering on the tool wear & tool load. 

1. It's a roughing program and I activated smoothing option (just 5%). Could it be the problem?

2. Is it possible that, with the G2 & G3 the machine tool could accelerate really faster compared with the normal G1 codes, which caused increased chip load?

3. Is there anything else I should take care while using line/Arc filtering?

Thank you!

Without seeing the program and exact parameters no way to really know.

#1 I never use smoothing on any program so I cannot comment on what it could or could not do to the program.

#2 Very possible is you were not using accel and deaccel on the machine.

#3 None i can think of and repeat what I opened with. Many times we don't see the linking moves before doing something like this and with the linking parameter not set correctly they were not creating the issue before you filtered the toolpath, but after the just little difference in line segments to arcs is enough to overload the tool in or out of an area. Try increasing them and see if that is the culprit here.

Did it break in the same exact spot or somewhere different? What is the material? Speed and feeds? Other cutting parameters? Taper of the machine? Type of holder?

[Chally72]

2 hours ago, Shiva.aero said:

Hello all!

I introduced Line/Arc filtering for the program which we were cutting regularly, after watching this video:

I just activated Line/Arc filtering & smoothing (5%)  without altering any other parameter. Impressively it reduced the no. of code line from 215000 to mere 85000. However when I ran on the machine, the cutter broke! Once again I tried with another cutter & once again it broke!

I understand many other parameter like tool runout, coolant, etc., could have caused it, but I like to understand the influence of line/Arc filtering on the tool wear & tool load. 

1. It's a roughing program and I activated smoothing option (just 5%). Could it be the problem?

2. Is it possible that, with the G2 & G3 the machine tool could accelerate really faster compared with the normal G1 codes, which caused increased chip load?

3. Is there anything else I should take care while using line/Arc filtering?

Thank you!

It's not just acceleration, but stuttering/lag- especially if you were on the limits of what the tool can do. Your specific machine behavior with G2/G3 and G1, and transitioning between them, should guide if you use these settings- not just the reduced line count factor. Some machines will stutter badly when transitioning through arc moves, and this can really hammer the tool with all the stop/go changes rather than staying properly in the cut. 

 The next question- what was your goal with the filtering to begin with? Was it just to reduce program size? Why- to avoid drip feeding? If the program fit on the control, adding in filtering is basically trying to fix a problem that doesn't exist.

Was the machine already stuttering with the current code before you added filtering, and this is what you were trying to address? 

Knowing your goals with these options, and knowing what your machine likes to see (linearized code or arcs, more point density or less) is critical to seeing beneficial results when making changes in these options. 

[Shiva.aero]

23 hours ago, crazy^millman said:

Without seeing the program and exact parameters no way to really know.

#1 I never use smoothing on any program so I cannot comment on what it could or could not do to the program.

#2 Very possible is you were not using accel and deaccel on the machine.

#3 None i can think of and repeat what I opened with. Many times we don't see the linking moves before doing something like this and with the linking parameter not set correctly they were not creating the issue before you filtered the toolpath, but after the just little difference in line segments to arcs is enough to overload the tool in or out of an area. Try increasing them and see if that is the culprit here.

Did it break in the same exact spot or somewhere different? What is the material? Speed and feeds? Other cutting parameters? Taper of the machine? Type of holder?

Thank you! 

# none of the linking parameter & toolpath changed before and after filtering.

# No it did not break at the same spot!. All the things like material, speed, feed, etc., remained same.

[Shiva.aero]

22 hours ago, Chally72 said:

It's not just acceleration, but stuttering/lag- especially if you were on the limits of what the tool can do. Your specific machine behavior with G2/G3 and G1, and transitioning between them, should guide if you use these settings- not just the reduced line count factor. Some machines will stutter badly when transitioning through arc moves, and this can really hammer the tool with all the stop/go changes rather than staying properly in the cut. 

 The next question- what was your goal with the filtering to begin with? Was it just to reduce program size? Why- to avoid drip feeding? If the program fit on the control, adding in filtering is basically trying to fix a problem that doesn't exist.

Was the machine already stuttering with the current code before you added filtering, and this is what you were trying to address? 

Knowing your goals with these options, and knowing what your machine likes to see (linearized code or arcs, more point density or less) is critical to seeing beneficial results when making changes in these options. 

Thank you!

#1 I don not understand what is stuttering & how to check it in the machine. I use Cycle832 which is the High speed settings for the siemens840d controller.

#2 I used filtering just to reduce the no. of codes, because with the 100s of transform operation, the length of program was too long (even after splitting the transform operations) &  it was difficult to perform GOTO or skip operations.

 

[Shiva.aero]

On 12/30/2021 at 7:30 PM, crazy^millman said:

Without seeing the program and exact parameters no way to really know.

#1 I never use smoothing on any program so I cannot comment on what it could or could not do to the program.

#2 Very possible is you were not using accel and deaccel on the machine.

#3 None i can think of and repeat what I opened with. Many times we don't see the linking moves before doing something like this and with the linking parameter not set correctly they were not creating the issue before you filtered the toolpath, but after the just little difference in line segments to arcs is enough to overload the tool in or out of an area. Try increasing them and see if that is the culprit here.

Did it break in the same exact spot or somewhere different? What is the material? Speed and feeds? Other cutting parameters? Taper of the machine? Type of holder?

Material is Wasploy. Dia 5mm tool with corner radius 0.3mm. Speed is 30 m/s and Feed per tooth is 0.025mm and I switched on the RCTF since I use dynamic toolpath (& it modifies the speed & feed). Depth of cut is 1.5 mm and engagement angle is 32.5 degree. Tool make is Walter. Tool overhang is 50mm. HSK taper and tool holder type is Shrink fit holder with length 80mm. Am I working on the verge of breaking the tool or is there enough margin?

Thank you!

[cncappsjames]

Waspalloy is VERY unforgiving material. . Plunging even 25μm and your tool is as good as cooked. You have to ramp in Z any transition from one depth to another.

On another note, it is VERY possible that an inside corner transition created by arc filtering caused a sudden increase in chip thickness thus blowing up your tool. Of all the materials I've cut, Waspalloy is in the top 3 or 4 most difficult to cut. By difficult I mean that I have to think about every motion in the path and it's potential effect on the tool. 

 

HTH 

[Leon82]

The machine was probably slowing down a lot with the linearized arcs.

[Shiva.aero]

8 hours ago, cncappsjames said:

Waspalloy is VERY unforgiving material. . Plunging even 25μm and your tool is as good as cooked. You have to ramp in Z any transition from one depth to another.

On another note, it is VERY possible that an inside corner transition created by arc filtering caused a sudden increase in chip thickness thus blowing up your tool. Of all the materials I've cut, Waspalloy is in the top 3 or 4 most difficult to cut. By difficult I mean that I have to think about every motion in the path and it's potential effect on the tool. 

 

HTH 

Thank you! It's a pocket machining. So I drilled a 5.5mm hole and the entry to next level is by plunging inside this hole (I put zero for vertical Arc entry & used only horizontal Arc entry). 

What do you mean by Corner transition?

I doubt increase in chip load when the toolpath radius goes small & that's why created another topic:

 

[cncappsjames]

13 hours ago, Shiva.aero said:

What do you mean by Corner transition?

So when you move into both interior and exterior corners, unless they have less material than the entry and exit areas you will get points along that corner where the chipload spikes. As I said previously, Waspalloy is unforgiving so even a 12µm spike in chipload in a short distance on an interior corner will snap an endmill easily. To lessen the effects you can pretreat the corners by either drillng or milling out interior corners to VERY near net finish dimension (within 10-15µm) or by using the corner pre-treatment option in the HST toolpaths for the exterior corners.

Constant, reliable engagement is your friend on the super-alloys and hardened tool steels.

[Bob W.]

I don't know about the Siemens controller but I do know that my Makinos run much better and smoother with linear code, NO arcs.  If looking for an amazing finish on a mold, 100% linear code, NO arcs.  My Haas machines were the opposite as is my Makino PS95 with the Fanuc 0i control.  They perform better and smoother with arcs and studder/ shudder with linear code because they can't process fast enough.  At the end of the day you need to figure out what the control and machine like.  Reach out to an AE for your machine maker and ask them what produces the fastest, smoothest machine motion and go with that.  We typically run linear code with .004-.01 max segment length if we want to really haul @ss.  Makes for huge programs though. For this application it isn't really about speed, it is more about smooth but the two are connected.  Speed=smooth.

 

[Leon82]

5 hours ago, Bob W. said:

I don't know about the Siemens controller but I do know that my Makinos run much better and smoother with linear code, NO arcs.  If looking for an amazing finish on a mold, 100% linear code, NO arcs.  My Haas machines were the opposite as is my Makino PS95 with the Fanuc 0i control.  They perform better and smoother with arcs and studder/ shudder with linear code because they can't process fast enough.  At the end of the day you need to figure out what the control and machine like.  Reach out to an AE for your machine maker and ask them what produces the fastest, smoothest machine motion and go with that.  We typically run linear code with .004-.01 max segment length if we want to really haul @ss.  Makes for huge programs though. For this application it isn't really about speed, it is more about smooth but the two are connected.  Speed=smooth.

 

I've noticed this on matsuuras also. Switching from splines to arks slows it down a little, even on rough settings.

[cam-eleon]

It would be interesting to run the linear vs the arc filter programs through Vericut Force. It may capture the spikes that break the cutter... 

[gcode]

4 hours ago, cam-eleon said:

It would be interesting to run the linear vs the arc filter programs through Vericut Force. It may capture the spikes that break the cutter... 

that would be interesting ! 

and CGTech is more than willing to work with potential Force customers 

[cncappsjames]

Can Vericut use the Machine Acc/Dec parameters to determine/predict actual machine performance?