clipped corner opti rough

[HEAVY METAL]

I was using  high speed surface (opti-rough) and it clipped the corner of my part.  It did not show this in verify . The tool path looks good . I have cimco editor pro and it does not show the toolpath   crossing that corner either. Anyone have a suggestion of what to check next . I reposted and it does repeat . Scary thing is that it looks fine  before  it goes out to machine .

2018-02-01 13.16.25.tif  

[gcode]

what kind of retract strategy are you using?

does your machine dogleg rapid?

[Matthew Hajicek - Singularity]

Can you put up the gcode?

[HEAVY METAL]

yea I try to isolate that area of gcode

 

[HEAVY METAL]

It really wasn't a retract maybe backfeed move

 

[HEAVY METAL]

1st 3 depths of cuts were fine

 

[Leon82]

What's your tolerance set at

[nickbe10]

 

On ‎2‎/‎1‎/‎2018 at 1:28 PM, HEAVY METAL said:

It really wasn't a retract maybe backfeed move

This thread seems to be running in two places.

Your step-over is .6 and your Min. Arc is .075. Rule of thumb is Min Arc should be 2 times step-over. This controls the arc on the backfeed, with such a small arc there are so many possible intersections and the length  is so short, I think the algorithm has difficulty determining which one to choose and which direction to travel on it. I have seen clipped corners and parts violated by a "wrong way" arc because of this. It does NOT show in verify or backplot.

[crazy^millman]

2 hours ago, nickbe10 said:

 

This thread seems to be running in two places.

Your step-over is .6 and your Min. Arc is .075. Rule of thumb is Min Arc should be 2 times step-over. This controls the arc on the backfeed, with such a small arc there are so many possible intersections and the length  is so short, I think the algorithm has difficulty determining which one to choose and which direction to travel on it. I have seen clipped corners and parts violated by a "wrong way" arc because of this. It does NOT show in verify or backplot.

But it will in a true Gcode verification program.

[nickbe10]

57 minutes ago, C^Millman said:

But it will in a true Gcode verification program.

I'm sure it will, the Gcode is there, but for some reason it is not reflected in the .NCI.........I got bit a couple of times, interestingly, once with a clipped corner (and not on all depths, just as Heavy Metals example) and once with a wrong way arc violating the part.......I've never tried it against a Gcode CAV, the company didn't have one......and since following the rule of thumb, it hasn't reared it's ugly head again.....so far.....

[HEAVY METAL]

Yes ,

I talked to my re-seller and he had mill loosen up the  min arc length and radius in the machine def /control def   to .002  . also  make  sure my look ahead is activated .

 

2x the step over seems like a lot ?

 

 

[nickbe10]

1 hour ago, HEAVY METAL said:

2x the step over seems like a lot ?

Yes that's what I thought, but if you make a copy of the toolpath and run different settings what you will find is that increasing the Min. Arc setting will only affect the loops for the rapid feed, not how much it cleans up on the inside of the feature. If it is not retracting enough and fast feeding too far you can use your gap setting to get what you want. Kinda counter intuitive to the old "legacy" approach to Gap Settings.

I think it is something to do with laying the entry arcs over the actual toolpath, the algorithm is looking for tangencies and intersects. With a small arc relative to the step over the entry "segments" are going to get smaller and smaller as you reduce the arc size and there are more of them, and this is what causes the problem, the algorithm just loses its way. Now why the motion is not reflected in the .NCI file and therefore does not show up in MC verification, I have no theory.

Since sticking with the rule of thumb I have never had a problem......I originally had the problem, once clipping a corner and once violating a boundary going the wrong way in the space of about 2 weeks. After the second one I gave Mr. C. Gilchrist a call and he informed me of the rule of thumb....that was about 5 years ago now I think, and as I said never a problem since.

Can you ignore the rule of thumb? Probably.....probably even the majority of the time. And if you have G-code CAV you will catch it. But if you rely on MC verify it is always a risk...

[So not a Guru]

On 2/5/2018 at 8:25 AM, nickbe10 said:

Rule of thumb is Min Arc should be 2 times step-over

Good tip, thanks

[GF8er]

We have run into this numerous times on our old Haas's. If the back feed is set at anything faster then about 200IPM they will clip a corner of the part on back feed. what machine are you running the parts on?

[MrFish]

Sounds to me like it's your machine not keeping up with itself on the back feed or rapid. HAAS will round a corner in G0 rapid mode by 60 thou according to there tech and as GF8er has stated they can also clip square corners if you are pushing them fast.

[nickbe10]

15 hours ago, MrFish said:

HAAS will round a corner in G0 rapid mode by 60 thou according to there tech

 

On ‎3‎/‎3‎/‎2018 at 1:21 PM, GF8er said:

If the back feed is set at anything faster then about 200IPM

I have seen this too on older Haas machines.

However my problems occurred on a virtually new Mori HMC.....and they both (clipped corner and part profile violation) far exceeded .06. I also got the same as Heavy Metal on the clipped corner, it only happened on a couple of z depths out of four or five total.

It was definitely a code problem because you could see the bogus g code. I am still at a loss as to why it didn't show in the .NCI file.

[MrFish]

6 hours ago, nickbe10 said:

 

I have seen this too on older Haas machines.

However my problems occurred on a virtually new Mori HMC.....and they both (clipped corner and part profile violation) far exceeded .06. I also got the same as Heavy Metal on the clipped corner, it only happened on a couple of z depths out of four or five total.

It was definitely a code problem because you could see the bogus g code. I am still at a loss as to why it didn't show in the .NCI file.

As your probably aware there is a processing stage between NCI and NC code so there is potential for an error to come in at that stage but it is weird that Cimco pro didn't show the error if it is a bad code error.

If you manually override the feed rate at the machine and slow the feed down does it still clip the corner , this would prove if it is bad code or the machine not following the code correctly.

[nickbe10]

17 minutes ago, MrFish said:

As your probably aware there is a processing stage between NCI and NC code

Yes that's why I went and looked at the actual g code, which was definitely bogus. But it is a normal motion statement that caused the error. So why wasn't it reflected in the .NCI file and thus in MC verify/backplot?

Do the High Feed algorithms get processed in the same way? Or is there a difference in processing compared to say a simple contour?

The machine was doing exactly what it was being told to do, it was not a feed rate issue......pretty new Mori and I was only feeding at about 140 ipm. Same machine would feed at 300+ ipm with no problems as long as the g code was good, which it wasn't in this case.....

We have an old Haas here too and if I have to run a program on it I make a separate file and slow everything down to hold tolerance, so I am aware of that situation on older Haas machines (cheap in position sensors/encoders I suspect).

G-code CAV would definitely have caught it.......

[MrFish]

9 minutes ago, nickbe10 said:

Yes that's why I went and looked at the actual g code, which was definitely bogus. But it is a normal motion statement that caused the error. So why wasn't it reflected in the .NCI file and thus in MC verify/backplot?

Do the High Feed algorithms get processed in the same way? Or is there a difference in processing compared to say a simple contour?

The machine was doing exactly what it was being told to do, it was not a feed rate issue......pretty new Mori and I was only feeding at about 140 ipm. Same machine would feed at 300+ ipm with no problems as long as the g code was good, which it wasn't in this case.....

We have an old Haas here too and if I have to run a program on it I make a separate file and slow everything down to hold tolerance, so I am aware of that situation on older Haas machines (cheap in position sensors/encoders I suspect).

G-code CAV would definitely have caught it.......

Hmm definitely an odd one. Something I think CNC software will have to take a look at. 

[nickbe10]

1 hour ago, MrFish said:

Hmm definitely an odd one. Something I think CNC software will have to take a look at. 

When I called Colin about it his response was immediate. Don't know if he was still working at CNC Software at the time, but it would have been close.....so my feeling is they know. Just use the rule of thumb or g-code CAV and all is well......I have never had the rule of thumb cramp my style with regards to run time or getting the toolpath I require......

[JMahon]

On our Mazak VCUs, it will do the same if the back feed is over 200ipm.  Has to do with the smoothing parameters.

We can take the exact same code and run it on a Mazak Compact or a Robodrill and it wont happen.