File cutting to small

[joeporter]

Bill, you mention you have cut this pocket several times, can your bit be starting to get a little dull? This could cause deflection. Have you tried running the same cut again in the same pocket? I was having similar problems with pocket cuts for dadoes and did some studies and ran the file again and the pocket cut to the exact dimension and all was well. Hope this is of some help...joe

[BrianM]

Hi,

Looking at the file you posted from VCarve, for the pocket toolpath ..

Minimum X Value

• Line: N490G1X1.1875Y1.5000Z-0.5000
  XValue = X1.1875

Maximum X Value

• Line: N510G1X24.8125Y2.5000Z-0.5000
  XValue = X24.8125

Difference = 24.8125 - 1.1875 = 23.625

These are the positions for the center of the cutter so at each end we will have the radius of the cutter (0.1875)

Overall Cut Width = 0.1875 + 23.625 + 0.1875 = 24.0

So if the machine is cutting more or less than this value, the problem is occurring between the interpretation of the G-Code and the physical cutting process.

Incidentally, the other G-Code posted is for a 26" x 2.375" Stair tread in a different position so it is difficult to compare the g-code output directly.

Brian

[Bill I]

[quote="BrianM"]So if the machine is cutting more or less than this value, the problem is occurring between the interpretation of the G-Code and the physical cutting process.

So how do you determine if it's the interpretation of the G-Code and the physical cutting process?

[Leo]

Overall Cut Width = 0.1875 + 23.625 + 0.1875 = 24.0Brian

The numbers add up to what they "should" be.

This is how Brian is determining exactly what the program is telling the machine what to do.

If the machine is not producing what the programming is telling it what to do, the problem cannot be the program.

This makes sense.

There are a number of things that "could" be wrong between the machine, Mach3, tooling, fixturing.

BUT

You have said that everything was working well before.

It's still a mystery - but it's not programming.

[Bill I]

Not only was it working well before. It also cut perfectly with the file produced by Enroute.
This is what has me confused what is done differently in Enroute and V-Carve?

[Bill I]

I cut the file again today and after using the latest post processor the cut has improved but it still is cutting.023 smaller.

[mtylerfl]

It's a shame you didn't provide the GCode from the Enroute file with EXACTLY the same dimensions as the Vectric file.

Made it impossible to allow an apples-to-apples comparison for Tech Support to analyze. (Not to mention invalidating your own test due to the dimension differences.)

You've never responded whether you tried changing cutting direction as Gary suggested early on either. Did you try that? If so, what was the result?

Maybe start over...use the same dimensioned file for both your Enroute file and your Vectric file. Test cut both (but be sure the same bit, feed, rpm, cut depth, cut direction, EVERYTHING so the same exact settings are used for each) and report.

[Bill I]

The dimensions are the same for both files.
I did post the files created in Enroute and provided the file to Vectric support.
File titled stair tread pocket PAGE 2 second up from bottom
I did cut the file in the opposite direction with no change.

[Adrian]

The enroute file is nothing like the VCarve file you posted though. They are for two completely different pieces. As Brian says the code shows that the values add up so the problem is from that stage onwards.

Also look at it this way, there are thousands of users of VCarve software around the world who have been using it for 15 years. If there was a dimension error like that in the software the forum would be flooded with people having the same issue.

Are you sure the enroute file is identical? Same speeds, feeds, ramp type/percentages, lead ins, etc etc? It only needs for there to be a slightly different way for the tool to be feeding into the material for the loads it takes to be completely different which would show up any issues with the hardware.

[LittleGreyMan]

Bill,

You may think Vcarve is the culprit and all posters are big Vectric fans who can't imagine the software fails. Actually, Vectric software is very reliable and the Vectric staff quickly fixes the few bugs users report.

Which doesn't mean the software can't fail in some specific cases.

But Brian demonstrated the generated code was not the culprit. So the problem is somewhere else. Pretending Enroute code is good and Vcarve code bad won't help you solving the issue.

CNC machining is not only a CAM process. Read Adrian's post. And if you still think it's a CAM problem, you'll have to compare apples to apples as Michael said: generate the same pocket, with the same parameters. And cut the same material, with the same tool.

[wmgeorge]

I cut the file again today and after using the latest post processor the cut has improved but it still is cutting.023 smaller.

How are you measuring the narrow or long side and with what to get .023 of an Inch difference? This is in some type of wood or what other material? That could be flex in your machine, is the feed rate the same on both gcode files?

[Bill I]

I have been using V-Carve since the beginning and have had an issue in the past which the quickly resolved and have a great respect for them.
The first thing I did was contact PMDX and after several tests it was determined it was not a hardware issue I did several tests in MACH an found nothing
but when I have a problem that only showed up when using V-Carve and they did find a small issue that was corrected the cut did improve but it is still cutting .023 smaller.
When I first found the problem I checked the motors the belt reduction even all electrical connections with no issues found I even purchase a new spindle collet but that made no difference. that was when I looked at V-Carve and after their assistance the problem still exists only when I use V-Carve the files created in Mozak Cabinet Program cut perfectly.
WHERE ELSE DO I LOOK??

[wmgeorge]

How are you measuring the narrow or long side and with what to get .023 of an Inch difference?

You need to post the gcode files for exactly the same project made with your other software and VCP. That way your comparing apples to apples.

VCarve / Vectric software is the design software for thousands of router users. Its possible perhaps you have a faulty install?

[LittleGreyMan]

Bill, pretending V-Carve is the origin of your problem when V-Carve outputs a correct G-code is a dead end.

The question is not "why is the cut too small with V-Carve" but "why is the size not correct while the G-Code is"

You are satisfied with other programs. So generate *exactly* the same cut with these programs. Cut the same material, with the same tool and measure immediately after cut. Perform all the tests (including V-Carve) as quickly as possible to be sure you have the same conditions (humidity, temperature, …).

And when I say the same material and the same tool, I mean exactly the same. Not another board of the same wood, which may react differently. Not another tool with the same reference: physically the same tool.

2 possibilities:
-the cuts are identical, which demonstrates it's not a software problem
-the cuts are different, and a g-code comparison will enlighten you

It's curious you had the same error in X and Y sizes. That's why several posters thought of a tool diameter issue or allowance.

You say you have now a 0.023 error. I generally wouldn't expect such precision with a 24 long cut. Wood moves, cut may be fuzzy. I already saw perfect and fuzzy cuts within the same toolpath on a 10x5 piece of hard wood carefully selected by a luthier.

BTW, with which tool do you measure your 24 long slot?

Edit: you were faster than me, wmgeorge. So same questions.

[mtylerfl]

...

VCarve / Vectric software is the design software for thousands of router users. Its possible perhaps you have a faulty install?

No. Not a "faulty install" of course. Either the software runs or it doesn't. We can easily eliminate that one!

I strongly believe the "problem" is not Vectric software related at all. Machine flex, bit deflection, controller settings, feed too fast, are a few possibilities.

Now, as far as a discrepancy of just 0.023" (0.0115" at each end), heck - material movement alone could account for that teeny amount!

I'm starting to think we may be chasing a dead horse now.