out of ideas

[electrictermite]

So, You can keep guessing at it - maybe you will get lucky - maybe not

You need to isolate the problem. How? Through a process of elimination.

1) Is it in the post processor?
2) Is it a machine issue?
3) Is it the G-Code?
4) Is it feeds and speeds?
5) Is it in V-Carve?
6) Is is a control issue?
7) Is it loosing steps?
Is it in program transfer?

How do you figure it out? By guessing?

I asked you to run a test. That test would help to isolate the issue by eliminating some of the guesses.
NOT by guessing.
We can ELIMINATE some guesses by performing some tests.

You are currently running around in circles, and that is because of "guessing".

Do you want to solve this?

this afternoon when i get back from work i will run only clearance tool on 3 wood scraps and post pictures.

[Leo]

Thank you

[electrictermite]

here is 3 scraps of wood running only clearing tool. the only thing reset is the Z so i could change out wood scraps. Z was reset with probe.

[Leo]

AWESOME

That eliminates a few things

1) It is NOT the piece moving under the hold down
2) It is NOT the machine
3) It is NOT losing steps

Because it is so CONSISTENT - it MUST be in the G-Code program.
So we can isolate THAT and concentrate on HOW that happened.
Now we can narrow down to the issue at hand without guessing.

Post the same exact tool path - do NOT change anything at all. Don't trim it down, don't do anything to it - just post it.

I know you posted already - but I want that exact one.
The CRV file - not the G-code

[Adrian]

2) It is NOT the machine
3) It is NOT losing steps

Because it is so CONSISTENT - it MUST be in the G-Code program.
So we can isolate THAT and concentrate on HOW that happened.
Now we can narrow down to the issue at hand without guessing.

I'm far from convinced that it's cannot be the machine be it physical or the way it's configured. To eliminate the machine the job would need to be run at a different angle to see if the different direction of cut changes were the error is. At the moment vertical cuts and constant curves seem to be fine. It's the angled move where it goes out of whack. Those results are identical to the previous ones posted.

I don't see how it can be the code. I've generated the code from the job using multiple different post processors and they all come out perfectly. If it was the code surely there would be more than one person having this issue?

[electrictermite]

here is the file

[Adrian]

Which post processor are you using when saving the code? It's been asked a couple of times but I haven't seen a reply.

[electrictermite]

2) It is NOT the machine
3) It is NOT losing steps

Because it is so CONSISTENT - it MUST be in the G-Code program.
So we can isolate THAT and concentrate on HOW that happened.
Now we can narrow down to the issue at hand without guessing.

I'm far from convinced that it's cannot be the machine be it physical or the way it's configured. To eliminate the machine the job would need to be run at a different angle to see if the different direction of cut changes were the error is. At the moment vertical cuts and constant curves seem to be fine. It's the angled move where it goes out of whack. Those results are identical to the previous ones posted.

I don't see how it can be the code. I've generated the code from the job using multiple different post processors and they all come out perfectly. If it was the code surely there would be more than one person having this issue?

i need to leave for work but when i get home i will create a new layer and turn the text by 90 degrees and create a tool path to run on new scrap of wood to see if mistakes show up in same place and will post pic.

[Adrian]

i need to leave for work but when i get home i will create a new layer and turn the text by 90 degrees and create a tool path to run on new scrap of wood to see if mistakes show up in same place and will post pic.

Do one at 45 degrees as well if you can.

[electrictermite]

Which post processor are you using when saving the code? It's been asked a couple of times but I haven't seen a reply.

Grbl (inch) to save using Vcarve Desktop 10.5

Source Rabbit to run it.

[Leo]

2) It is NOT the machine
3) It is NOT losing steps

Because it is so CONSISTENT - it MUST be in the G-Code program.
So we can isolate THAT and concentrate on HOW that happened.
Now we can narrow down to the issue at hand without guessing.

I'm far from convinced that it's cannot be the machine be it physical or the way it's configured. To eliminate the machine the job would need to be run at a different angle to see if the different direction of cut changes were the error is. At the moment vertical cuts and constant curves seem to be fine. It's the angled move where it goes out of whack. Those results are identical to the previous ones posted.

I don't see how it can be the code. I've generated the code from the job using multiple different post processors and they all come out perfectly. If it was the code surely there would be more than one person having this issue?

Adrian, in my experience when something like this is as consistent as it is - then it is in the program.
If it was machine related it would generally be a lot more erratic.

Now - HOW - did the program get corrupted?
Maybe it's the post processor
Maybe it's how he selected the toolpaths
Maybe he is using a USB
Maybe the "sender" is corrupting it.
Maybe something else causing the g-code to be what it is, but I am convinced it is in the g-code.
How it got to be that way - I don't know. That is what we all need to figure out.

[Adrian]

It's 100% not the g-code itself IMO, the code for that toolpath generated using the Grbl post processor in 10.515 produces correct code.

If it's getting corrupted during the transfer then it's a very specific corruption to be identical every time and to allow the toolpath to return to the correct position afterwards.

Everything after that is at the machine/controller end which is why I'm sure it's at that end of things rather than anything with the code.

[Leo]

Looking at the toolpath on the PLUG pocket Base

20,000 RPM may be a TAD high, but it is acceptable
25 IMP is way too low - because you only have a 6 ten thousandths of an inch chipload
Either lower the RPM - OR - raise the IPM

At 18000 RPM and 75 IMP the chip load becomes .0021 which is WAY better.
I set the plunge to 25 IPM

You CAN change your stepover to 50%
Your Pass depth can safety be set to .062 -- half the cutter diameter

Speed and feed and stepover and plunge will not fix the problem but these are better settings.

I don't see anything in the toolpath settings to change.

DO try what Adrian is suggesting.

[Leo]

Adrian, I highly respect you and your advice, but, I am not convinced the same as you are not convinced in my line of thought.

Either way, it is ok to disagree.

Perhaps you are correct and I am wrong - I am ok with that.

Still in my experience in the industrial machining world, consistency is in the G-Code.
It could happen in many different ways.

So, lets find the problem - together - and remain friends.

[Leo]

It looks on the N and on the W - the perimeter seems to be cut OK, but the inside is not cleared.

With the LOW chipload and a downcut cutter --- Is the cut area getting packed up with chips?. That may ne produce the consistency I see, but it could be a problem. Maybe the cutter rides up in Z? Weird - just thinking out loud. Maybe not with S because of the shape of the slot.