this is how I programmed it
Cutter moves into corner and stops (bottom of cut)
Z raises (top of cut) (do not move this position)
X and Y Move (these are what I adjusted)
X Y Z move together downward to the same position as "bottom of cut"
program proceeds
Notes
My divit was tapered, it cut off to much at the top of cut but was ok at the bottom, so adjusting the x and y values was all I had to do
If the tool is off at the bottom that means it is not going back to the position it started from (mechanical problem?)
You could adjust both values( the same amount) but you would have to set them back to the original position before proceeding, I would want to why it did it in the first place.

Richard

After reading my own post I was wondering if someone changed the amount Z is raised when this was ported?
That would change the angle of descent and give you nothing but problems

Richard

Thx Richard! Makes sense, will ffrd your notes onto the manufacture, maybe he can check that out for us, thx again!

DOes it do this on EVERY small sharp corner?  IF so then LOOK to the servo tuning, too much overrun will do it every time. The servo will overun the position and then back up to correct.

Just a thought, (;-) TP

BR549, please explain overrun and how one would go about detecting whether it is in fact what's busy happening?

Just to clarify some things that Marius1975 missed in mentioning:

The machine uses ball screws on all axis, driven by servo motors.

All axis has been calibrated and are 100%

We have cut the exact same program (gcode) using the exact same cutter on a HAAS machine and it came out perfectly.

The problem only occurs when doing "corner sharpening" and affects all areas that requires corner sharpening.

The servos are tuneable as to how accurate they run. They are not like a stepper that just assumes it moves a certain amount of step pulses. The controller moves the motor a nd then CHECKS the encoder to make sure it is where it is suppose to be.  You tune the drive to HOW reactive the motion is. You can tune it to acutally overrun the position point then back up to correct itself OR trip out due to error limits. Same with underrunning where it may stop short on the position then try to correct.

It is best to tune the drive with a SCOPE so you can see the actual movement profile and make sure it is correct.

Just a thought, (;-)

Two More Things
make sure backlash comp is turned off
If You can post the section of code that is the problem, some one here may be able to see if there is a problem
I can also run it to see what I get

Thank you for the informative reply BR549. I will contact our manufacturer and ask how they've calibrated the motor to react when it comes to overrun/underrun. According to them the whole point of going ball screws/servo's/encoder was so that everything will always be in the right position since the encoder always keeps track of the movement, but I see where you going with this and it does make sense especially when you look at the sample cut results. They also assured us that the motors/servo's are 0.005mm accurate.

Richard, backlash comp is turned off. Like I mentioned previously we have run the exact same program using the exact same cutter on a HAAS machine and it cut perfectly, which leads me to believe that there is nothing wrong with the code itself?

Here is the gcode used for the problem area.

If anyone can cut this it would be great, then at least we'd know whether it's the machine or if mach3 is setup incorrectly.

Cutter being used is a 0.1mm d-bit with 30 degree angle.

Block size is 115mm x 70mm

Any help would be greatly appreciated

Here is the gcode back, I added spaces and line numbers. I annotated where you need to raise the Z axis.
Make sure you are satisfied with your XYZ settings and that the angle of your cutter is correct before making changes to the program.
There two pictures to show what the wrong angle will do.

Hope this helps

Richard

Thank you for your efforts Richard.

Looking at your annotations it seems like you wanting the z axis to move out of the material by say 0.1 - 0.3mm when doing corner sharpening.

Am I correct in making this assumption?

I know some cam packages do this by default and will look into adding this into my existing cam package if it's the case.

The 30 degree cutter is definitely right since I've used it on a different machine cutting the same gcode without any errors in corner sharpening,so it can't be that.

Unfortunately I can't see all that clearly how your 30 degree cut went in your picture. Is it cutting away the corners or not? If not, can you perhaps send me your xml file so that I can see what differences we have in mach3.