Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: PROMiCA on April 05, 2009, 02:39:11 AM
-
Hello All,
I've got a slight issue at the moment...
I'll use one of my parts as an example but I get the same results from all toolpaths.
Basically everything is machining beautifully with the exception that nothing is 'spot on' for size ... sounds like a bit of a contradiction I know - but what I mean is that the same part can be made over and over again and each time the job completes without issue .. no missed steps, no chattering, beautifull straight cuts with a mirror like finish, internal circular pockets are also mirror like and shaped correctly (and a I said above this is the same for multiple toolpaths).
I can make the same part 3 times over out of one piece of stock ... my toolpaths use offsets - so I just re-home and apply new offsets then pick up the sub file and begin the next part.
PC is a dedicated dual core AMD, 2gb RAM, etc etc - it is a dedicated PC with NOTHING except XP and CAM software on it.
The issue is that all outer edges (ie profiles) are approx 0.3mm too big and circular pockets are approx 0.3mm too small - so a part that has an external dimension of 70mm comes off the machine as 70.3mm ... the 26.25mm dia pocket comes out as 25.95mm.
Toolpaths are all fine - I've checked the positional data and allowing for tool diameter the toolpaths are spot on. I should mention that the same toolpaths run under TurboCNC3 cut the part exactly as it should be (ie correct sizing).
Tools are high quality TiCN and Zirconium bits (approx $50 & $70 each!!)
I have Mach3 set to Exact Stop mode. There are no tool offsets in the system at all - I never use them. Every toolpath has the same header info in it:
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)
Backlash compensation is used but the system has very little backlash anyway (.04mm on Y and .03mm on X ... so lets say 1 thou" on each). Having backlash compensation on or off makes no difference to this issue anyway.
With digital calipers fixed to the table and head the measured movement is spot on ... tell it to move 100mm and it moves to 100.00 on the calipers - so motor setup/ratios are correct.
Have tried various cutting speeds, acceleration, top speed (rapids) etc - again no effect on the outcome.
I've had the CRO's on both step and direction outputs for each axis card - again they are all good.
It seems to me that Mach3 is applying a 0.15mm cutter compenstion on every toolpath or is somehow rounding off all movements.
I don't know if I'm missing something - or if there's a bug in 3.042.020.
Sorry if the answer to this is elsewhere on the forum ... searching for it came up with either no or unrelated results (everybody terms things differently).
Can anyone shed any light ?? ???
Thanks
Marc
-
Hi,
is the error proportional to the size of the part, i.e. is it getting larger on a bigger part?
Have you checked to see if the sides of the part are square not tapered.
Are the scaling DRO's set to 1
Have you a stray G41/42 in your code and a offset in the tool table.
If you milled a hexagon or octagon would all sides be to big?
Graham
-
Thanks for the reply!
The error does not appear to be proportional at all .. as mentioned an 'outer' profile that should be 70mm is actually 70.24mm (rounded off in earlier post for simplicity) ... on the same job a circluar pocket that should have been 26.25mm is actually 26.00. On a completely different job a circular pocket that should be 22.0mm is 21.73, and outer edge that should be 47.0 is 47.18mm.
Outer edges are always slightly oversize and inner are always slightly undersize.
Sides are square and parallel. The machine is also trammed correclty.
There are no G41/42's in the toolpaths at all - but as listed in my first post there is a G40 in each header.
A tool offset was the first htis I suspected - but as I've never used them I was pretty confident that there was nothing set in the table - and there isn't (scrolled right through the table to double check). I do use work offsets on pretty much the bulk of my jobs but that should have no bearing on this issue.
I haven't tried a hexagon or octagon but going by all the parts I have made I would virtually guarantee that they will be equally to big on all sides - or if done as a pocket they would be all too small.
I should also mention too that I use 'climb' milling on all toolpaths ... so outer profiles are machined clockwise around the part and all pockets are machine anti-clockwise. Again that is what makes the issue look like a tool offset - but all are 0. These parts are also cut with a 10mm bit ... even on a crappy Chinese bit there's not going to be THAT much flex! - but the tools I use are very high quality - they aren't going to be the cause of this issue...
Scaling on XY & Z are all 1.0000.
I've just rechecked all axis with the digitial caliper attached and all of them move the correct amount using MDI commands - all are spot on ....from X0 a G0X50 will move to read 50.00 on the calipers - resollution is only to two decimal places however that is fine (basically within 1/4 thou).
I'm hoping it will be one of those 'slap myself on the forehead' events .... but so far I think I've checked pretty much all I can as far as the physical hardware and electronics go.
Regards
Marc
(PS - might try a hexagon tomorrow if I get the chance ... would be interesting to see what comes out!!)
-
Just a thought.... but have you certified your tooling for size? For close work we usually run the tool through a piece of similar material, then measure the slot. Maybe the offsets are not dead-on?
Again, just a thought,
Bill C.
-
Thanks for the idea ..but yes I have checked the tool bits ... all the jobs I've run with 2 different bits and both are as close to 10.00mm as I can measure - certainly they aren't anything like 0.1mm (0.004") out that would be needed to make this magnitude of error.
All the toolpaths have a roughing sequence that cuts to 0.5mm and then do a light finishing cut.
The work offsets that I use would simply perform the job in the wrong position if they weren't right ...not make the part an incorrect size.
I have also checked the tool offsets yet again - there are absolutely no offsets entered into Mach3 for tooling.
Marc
-
I don't think you said what machine you're running this on. It could well be flex in the machine itself. If you repeat the finish cut several times, does the dimension improve?
Regards,
Ray L.
-
This is running on one of my X3 kits (see http://www.cnckits.com.au).
It's not machine flex ... the X3 is definately sturdy enough plus as mentioned in the first post the same toolpath will cut correctly if run under TurboCNC3.
Marc
-
HOw was the machine configured Imperial(") or metric.
I just finished some bearing pockets here and a 1.374" hole came out at 1.374"
(;-) TP
-
Hi
Machine is configured metric and all part/toolpaths are metric.
-
can you post the code that is giving the size error?
Graham
-
You don't have a g41/42 in your start up string in config do you?
Graham
-
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....
FINISHING CUT FOR THE 26.25mm POCKET
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)
FINISHING CUT FOR THE 70mm PROFILE
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.
Marc
-
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 ...
Marc
-
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
-
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 :)
Marc
-
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!!
Marc
;D
-
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...
Marc
-
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.
-
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 :)
Marc
-
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.
Sage
-
Hi Sage
I cant upload the toolpaths as they are proprietry .. however they have been run on this machine under TurboCNC and work fine - hardware is not an issue. I have also sent them to Graham via email and he is looking into it.
Yes you are right - I should have kept the second problem for another post... I'll elaborate further on that particular issue once this one is sorted. Pls ignore post #16
-
It would help IF you created a test file that duplicated the results you see so we could see and run the file and test for the same results as you.
(;-) TP
-
Well, all I can say is your examples have been confusing, such as this one from above (edited for brevity):
Using a 10mm cutter I manually drove the tool about to make a 40.5mm square
Finished part sizing from Mach3 (MDI & g-code)
MDI - X40.02 Y39.95
Same three parts done under TurboCNC3
MDI - X40.00 Y39.99
Looks to me like neither of these (including TurboCNC) is making the square to the propoer size of 40.5mm so I remain confused how you figure TurboCNC is doing any better than MACH3.
Sorry I can't help you more. I still recommend (as others) making a simple program to demonstrate the problem that others can use to help you out.
Sage
-
Hi again Sage.
At the risk of sounding a bit defensive you need to read and comprehend ... the text you edited out of my post said that I then took 0.5mm OFF as a FINISHING cut which would make it 40.0mm !!
The purpose of the exercise was to see what differences there were between TCNC3 and Mach3. Each test consisted of three actions - manually driving the tool by MDI, then doing the same but from a gcode file and finaly one was to see if radiusing the corners had any bearing on the outcome as the part I was working on when I found this issue has radiused corners. Pretty simple really and I'm sorry if it confusses you. :)
TCNC3 had the parts to within 0.02mm (0.0005") whereas Mach3 was up to 0.11mm (0.004") out - by my calculations that's 8 times 'worse'. You need to remember that I usually work in metric and 0.01mm is roughly 0.00025". To people who usually work in imperial 0.02 looks like allot - but it's not!!
And again as already stated Graham has the code and is doing his own testing.
If I get the chance later today I will make some test files and post them here.
-
Sorry, I stand corrected. I missed that additional action of taking off the extra 0.5mm.
Sage
-
Sorry for the delay in updating this ...been busy !!
From what I have been told this is a bug that they have been trying to find for a while now ... apparently it only ‘pops up’ now and then and may involve code which utilises G28.1, G92, subroutines and offsets (all in the same code file).
A couple of days after starting that post I ran another job which uses all of the codes in the one file – it ran perfectly... as have others since. There seems to be no logic to which code it will effect which makes it very difficult to work around ... at least if it always did the same thing to each and every file you could code around it or take it into consideration when first designing your part.
Apparently the driver section of the new Version 4 is totally re-written and should have no issues.