Hello Guest it is May 07, 2021, 06:14:22 AM

Author Topic: Parts are not correct size!  (Read 11284 times)

0 Members and 1 Guest are viewing this topic.

Offline Graham Waterworth

  • *
  •  2,322 2,322
  • Yorkshire Dales, England
    • View Profile
Re: Parts are not correct size!
« Reply #10 on: April 06, 2009, 09:54:41 AM »
You don't have a g41/42 in your start up string in config do you?

Without engineers the world stops
Re: Parts are not correct size!
« Reply #11 on: April 06, 2009, 09:58:37 AM »
I've done some more testing...

I cut a square via MDI commands and also via g-code.

Using a 10mm cutter I manually drove the tool about to make a 40.5mm square profile then took 0.5mm off as a finishing cut leaving 40x40mm. I then made the same path as a g-code file that did the process twice - once with 'square' corners and again but with 2mm radius corners.

This was run both in Mach3 and TurboCNC3... same machine, same controller, same wiring etc etc ... simply booted to XP (for Mach3) or DOS (for TurboCNC) then picked up the same g-code file.

Finished part sizing from Mach3 (MDI & g-code)

MDI       - X40.02 Y39.95
Sqr Cnr  - X40.10 Y40.05
Rnd Cnr - X40.07 Y40.11

Same three parts done under TurboCNC3

MDI       - X40.00 Y39.99
Sqr Cnr  - X40.02 Y40.01
Rnd Cnr - X40.02 Y40.02

Given that I haven't used TurboCNC for some time now the discrepency from it's cuts may well be just backlash - I haven't checked/set it for a long time. Mach3 on the other hand is used regularly and I check/set backlash whenever appropriate (was done again yesterday using digital calipers clamped to the table/head).  

To try to eliminate any leadscrew variances both jobs were done with the stock held in a jig so that both Mach3 and TurbCNC ran the jobs in the same physical locations. Gibbs are set nicely - no slop throughout travel range.

Biggest issue though is that none of this can explain why my actual jobs are so far out of alignment ... to recap - under Mach3 a 70mm outer profile comes out at 70.24mm and an inner circular pocket that should be 26.25mm is 25.99. Backlash on the system is 0.03mm on X and 0.04mm on Y (so around a thou on each) - not enough to cause a 0.25mm error even if compensation was turned off.

I rechecked the toolpath again last night and it is telling Mach3 the correct thing ... I'm just not getting the results when the job is run and can't for the life of me work out why!!

Here's a couple of snippets from the g-code....

G1 Z-9. F150
G3 X31.925 Y37.914 I0. J-0.625 F900
G1 Y41.414
G3 X31.925 Y41.414 I0. J-4.125
G1 Y44.914
G3 X31.925 Y44.914 I0. J-7.625
G1 Y45.414 F600
G3 X31.925 Y45.414 I0. J-8.125
G0 Z5.

.... so by my calculation 8.125 (radius) times 2 is 16.25 ...plus 10mm for the cutter = 26.25mm (getting 25.99)

G1 Z-15. F150
   X50.899 Y8.445 F600
G2 X49.439 Y5.225 R7.
G1 X44.068 Y-1.406
G2 X38.629 Y-4. R7.
G1 X3.
G2 X-4. Y3. R7.
G1 Y69.005
G2 X3. Y76. R7.
G1 X44.
G2 X51. Y69.005 R7.
G1 Y9.631
G2 X50.899 Y8.445 R7.
G1 X51.392 Y8.361
G0 Z5.

.... extremes in Y are Y-4 & Y76 ... totals 80mm minus 10mm cutter = 70mm finish (getting 70.24)

There are NO tool offsets in the table (all are 0.000) plus there are no G commands in the code for tool offsets, exact stop is turned ON, have tried my 'usual' and super slow accel on the motors, have tried backlash both on and off .... and have done all of that with Quantum, Mach3 2.63 & 3.42.020 with the same results on all ... this is driving me stupid !!

Tomorrow I'm going to try another parallel cable, recheck BIOS, double check XP optomisation and any other straws I can clutch at !! I'm still hoping for one of those 'slap in the forehead' moments ... otherwise it's either back to TurboCNC (ultra reliable but old) or possibly EMC2.

Melbourne Australia
Re: Parts are not correct size!
« Reply #12 on: April 06, 2009, 10:14:00 AM »
Hi Graham,

No .. init string is G80 G52 X0 Y0.

Every one of my toolpaths has this in the header ..

G61           (Set exact stop mode)
G49           (Cancel tool offsets)
G17           (Set X-Y plane)
G40           (Cancel cutter radius compensation)
G21           (Set units to metric)
G80           (Cancel motion and canned cycle mode)
G90           (Absolute mode)
G52 X0 Y0     (Remove any offsets applied to X & Y)

The G49 is the only possible relevant command and it's supposed to cancel tool offsets - plus as I've mentioned the entire tool offset table is 0.000 so even if one was being called it would (or should) have no effect anyway.

I've also attached my Mach3Mill.xml file ...


Melbourne Australia


Re: Parts are not correct size!
« Reply #13 on: April 06, 2009, 10:26:50 AM »
How much backlash correction are you applying? Try adding 1/2 of the amount the part is off to the backlash correction you already have. AS A TEST.

(;-) TP
Re: Parts are not correct size!
« Reply #14 on: April 06, 2009, 10:49:04 AM »
Backlash settings at the moment are exactly equal to the real backlash ... 0.03mm on X and 0.04mm on Y. With these backlash figures set and digital calipers fitted to the machine I can MDI in any direction and the calipers read exactly as they should.

It would be hard to try adding 1/2 of the error to the backlash and it again - mainly because the part is made from a particular size stock and held in a jig ... problem now is that the system has buggered up all of the stock I had ... then again I could try to put one of the 'ruined' ones back in and run the code again.

I'll try that in the morning - currently it's 12:45AM and the neighbours would hit the roof if I tried machining now ... as tempting as it is :)

Melbourne Australia
Re: Parts are not correct size!
« Reply #15 on: April 07, 2009, 12:16:47 AM »
Success finally !!

I'm happy in a way and sad in another to report that this is a bug in Mach3 !! Well ...to be fair it may be the way I'm doing stuff but ... here's what I found.

My toolpaths are mostly set up to machine 3 of a particular part (a couple only do 2).

The way I do these (and this is a recent change) is I first create a 'header' or master job. It contains all of the setup routines including a G28.1 X10 Y10 to always reference the machine between each part being made.

So the header sets up the machine and does the first G28.1. It then applies a work offset from the table and reads in a seperate subroutine file which is the actual 'movements' to create the part.

It then lifts Z up out of harms way and does another G28.1 to ref the machine again. Then it applies the next work offset and reads in the same subroutine file again ... so the part gets made again at the new offset location.

For the third cycle the process is simply repeated again - lift Z, G28.1, apply offsets, machine part.

The cycle runs through perfectly but the parts have the problem that I have been trying to rectify here ... outer perimeter is too big by 0.25mm and inner bearing pocket is too small by the same amount.

So in working backwards ... I recreated the header file to make only one part - but this time the full code was contained in the same file ..so NO subroutine file - BINGO!!! Finished parts end up being to size +/- 0.01mm (~1/4 thou off).

I did this three times in a row ... made the parts with the original header and sub file - all were out by the 0.25mm ... without changing anything I ran the job again but this time with 'full' g-code in the one file ... the finish cut on each pass took off a smidgeon ...

I have not yet tried the process with the one file containing a sub for the part (running the sub three times over) ... but certainly as a 'no sub' code it does what it's supposed to do.

During the battle to find out what was causing this issue I tried Quantum, Mach3 2.63, Mach3 3.042.020 and Mach3 3.043.026 (which is the current installed version) - so I don't know how many renditions this apples to but it seems to go a way back considering that all versions made the part over/under sized by the same amount.

I have some more parts still to be made - so I will try various combinations of subs/full code and see what happens - but to me it looks like this is a confirmed bug (unless my process is wrong!!)

Thanks to all who offered various input!!


Melbourne Australia
Re: Parts are not correct size!
« Reply #16 on: April 07, 2009, 12:27:50 AM »
I might just add one other point ...

The bearing pocket in this particular part is to hold a bearing that is 26.00mm diameter.

For some reason I have had to draw the part with a 26.25mm pocket ... and now even with the sub routine issue listed above the pocket still only comes out at 26.01mm ... makes for a very nice fit ... but why do I need to draw it as 26.25mm - again 0.25 oversize????

Thought I'd mention that here as it somehow may be related...

Melbourne Australia


Re: Parts are not correct size!
« Reply #17 on: April 07, 2009, 05:23:23 AM »
Very good! Now then, you must admit that Mach 3 is a bargain over any commercial machine operating system. Fanuc or Fagor or any other systems would cost 100's of times more and have the same issues. Thanks for all that good R&D with Mach 3, you're helping to make it even better. Many of us just 'play' with it; you're serious business.

Bill C.
Re: Parts are not correct size!
« Reply #18 on: April 07, 2009, 05:47:37 AM »
OK ... an update.

I've run the second part of that same job which is to machine a 27mm dia recess on the back and finish of 'shaping' the piece.

I had exactly the same issue again ... running each job utilising the sub file would result in an incorrect part size. Ran the same jobs a second time and the parts were finished off correctly ... again the only difference being that the second time around they had the entire g-code in the one file.

Still haven't tried doing multiple parts from the one file with a sub IN it ... should be able to do that tomorrow ...but I reckon I know what the result will be :)

Melbourne Australia

Offline Sage

  •  365 365
    • View Profile
Re: Parts are not correct size!
« Reply #19 on: April 07, 2009, 01:08:07 PM »
Well. You've managed to get me totally confused. Seems you had it fixed then you said it still wasn't right becasue you had it drawn wrong.
 You might save us all some frustration and upload the code - or a small representative piece that demonstrates the problem - so someone else can try it on their machine and report back. That will eliminate the hardware questions. I think Graham suggested you do that  a ways back.
 If he can't figure it out noboy will.