No Levelled GCode file is created

Report problems here
GastonGagnon
Posts: 11
Joined: Wed Jul 16, 2014 5:21 pm

Re: No Levelled GCode file is created

Post by GastonGagnon »

Hi James,
I just want to tell that I did not fade away. I just did not get around to test the new version yet.
Get back to you soon.
Gaston
kvnrydberg
Posts: 19
Joined: Thu Jul 17, 2014 4:46 am

Re: No Levelled GCode file is created

Post by kvnrydberg »

OK. I did some more work with the g-code generated from a probe file (can we call this the PLF, for Probe Levelled File?), and I ran into some snags.

The first issue isn't so much of a bug, pre se, but it has me wondering. The PLF has a sub-routine that moves the spindle to a known point, probes down to the workpiece, then sets the z pos to the z value listed at this point in the probe file. Just as it should. But you have the spindle move to the second probed point in the RPF. Is there a reason you haven't programmed it to move to the first point? The reason why I ask, is that I always make sure the first probed point is not only clear of any traces, pockets, or drill holes, but is continuous with my probe circuit. That way I can always go to this point and re-reference if I have to. But usually the second probe point is "inside" my circuit. So if the x,y pos of the second point should happen to be over a trace that has been etched previously, there will be no circuit made when the tool touches the work. And this is what happened today, much to my dismay. So could we name the first point as our reference? As it is, I have to edit the g-code by hand. Which isn't so much of a nuisance, really, but lord knows I'll forget to do it and ruin my tool and probably my PCB, too.

Another thing that I noticed is that, with the PLF anyway, if there are any movements outside the probed area, things really go hay-wire. I haven't noticed anything odd at all with the g-code file created by AL in the usual way with no probe log. (can we call this ALF, for Auto-Levelled file?) Actually, I'm curious to know how AL handles these movements. It seems to me that just using the z height of the closest probed point would be the best way to go.

Besides these two issues, when I looked at my PLF with some attention I saw some unusual things that I didn't notice while watching my machine throughout the MOP. So I'll upload the relevant files for you to look at. Basically, I saw the following:

spurious "big" jumps (~.001") in the z-height for a few lines followed by a jump back to "normal"

spurious "gigantic" jumps (>.1" and clearly out of place) for a few lines followed by a jump back to "normal"

and general wierdness happening over the course of many lines, usually this amounts to no change at all in the z height for most of the time with a jump here and there for whatever reason.

(Curiously, pretty much every "big" jumps happen right at x = 2.5, which is precisely the halfway point of this particular board in the x-direction.)

The file I've uploaded is a pocketing procedure I use on the component side of my double sided boards to ensure that the component leads do not contact the copper. It's just a bunch of disks, some of them connected, routed .005" deep into the board where some of the leads go through to the bottom side. After every plunge (F13, in this case, since I'm plunging at 13 IPM), the only movements are done in a very local area. So it's easy to see where things go wrong. And I've marked where in various places of the PLF with asterisks, so you can search easily. Though I only scanned about half of the file before I called it quits. I also had to hack off a small part of the PLF so it would be uploadable.
Attachments
RPF.txt
(4 KiB) Downloaded 378 times
PLF.nc
(249.64 KiB) Downloaded 389 times
Original.nc
(195.54 KiB) Downloaded 398 times
daedelus
Site Admin
Posts: 387
Joined: Tue Oct 01, 2013 1:41 pm
Location: London, UK
Contact:

Re: No Levelled GCode file is created

Post by daedelus »

Thanks for the extensive information, it will and has given me a lot of help tracking down the source of the problems.

My initial analysis is that all or most of these problems stem from the previous fix with the RPF last week. Now that some tolerance has been added to the X and Y, it now sorts the points wrong.

Have a look at the top of your PLF:

Code: Select all

...
(146 | 149 | 152 | 154 | 145 | 147 | 148 | 150 | 151 | 153 | 155 | 156)
(144 | 142 | 140 | 138 | 136 | 134 | 143 | 141 | 139 | 137 | 135 | 133)
(122 | 124 | 126 | 128 | 130 | 132 | 121 | 123 | 125 | 127 | 129 | 131)
(120 | 118 | 117 | 115 | 113 | 112 | 110 | 109 | 119 | 116 | 114 | 111)
(97 | 98 | 99 | 101 | 102 | 103 | 105 | 106 | 107 | 100 | 104 | 108)
(95 | 94 | 92 | 91 | 90 | 88 | 87 | 86 | 96 | 93 | 89 | 85)
(74 | 75 | 76 | 77 | 78 | 79 | 81 | 82 | 83 | 84 | 73 | 80)
(72 | 71 | 70 | 69 | 68 | 67 | 66 | 65 | 64 | 63 | 62 | 61)
(49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60)
(41 | 48 | 47 | 46 | 45 | 44 | 43 | 42 | 40 | 39 | 38 | 37)
(25 | 30 | 34 | 26 | 27 | 28 | 29 | 31 | 32 | 33 | 35 | 36)
(20 | 15 | 24 | 23 | 22 | 21 | 19 | 18 | 17 | 16 | 14 | 13)
(2 | 5 | 8 | 11 | 1 | 3 | 4 | 6 | 7 | 9 | 10 | 12)

(Match the "point order" with the XYZ position here)

(1  | X = 0.400120     Y = 0.400080     Z = -0.000500)
(2  | X = 0.782790     Y = 0.399830     Z = 0.001500)
(3  | X = 1.164710     Y = 0.400080     Z = 0.002500)
(4  | X = 1.546390     Y = 0.400080     Z = 0.002750)
(5  | X = 1.928310     Y = 0.399830     Z = 0.003750)
(6  | X = 2.309980     Y = 0.400080     Z = 0.003250)
(7  | X = 2.691900     Y = 0.400080     Z = 0.003250)
(8  | X = 3.073820     Y = 0.399830     Z = 0.002750)
(9  | X = 3.455490     Y = 0.400080     Z = 0.001250)
(10 | X = 3.837420     Y = 0.400080     Z = -0.000250)
(11 | X = 4.219090     Y = 0.399830     Z = -0.002750)
(12 | X = 4.601010     Y = 0.400080     Z = -0.005490)
...
The bottom row of the 'point order table' should read (1 | 2 |3 |4 etc. but as you can see, it doesnt.

Because of the fix last week, it now thinks point 2 is the first point because it has a lower Y value than point 1. This incorrect ordering is also why you are seeing the 'jumps' in Z values and why you do not see the same problems in the normal ALF.

I will look into a solution shortly and get back to you.

P.S. This problem should only affect users where the points in the RPF differ slightly from those in the PFG file.
http://www.autoleveller.co.uk/. Software to probe and adjust a GCode file for PCB's or any probe-able surface.

http://www.autoleveller.co.uk/cnc-probe-guide/. A short guide to setting up the probe.

-James
daedelus
Site Admin
Posts: 387
Joined: Tue Oct 01, 2013 1:41 pm
Location: London, UK
Contact:

Re: No Levelled GCode file is created

Post by daedelus »

The latest changes should fix all those issues and I have just uploaded the fix. Please re-download the latest and try again.

It has gone through an extensive testing procedure but if I have missed anything please let me know.

have fun,
http://www.autoleveller.co.uk/. Software to probe and adjust a GCode file for PCB's or any probe-able surface.

http://www.autoleveller.co.uk/cnc-probe-guide/. A short guide to setting up the probe.

-James
GastonGagnon
Posts: 11
Joined: Wed Jul 16, 2014 5:21 pm

Re: No Levelled GCode file is created

Post by GastonGagnon »

Hi James,
I have tried the last version of AL and here are some observations:
1. The probe file generated by Mach3 does not seem to handle the backlash properly. It records the distance that Mach has to move instead of the compensated distance.
Example: I have a backlash compensation of 0.003 on X and no compensation of Y and Z.
For a GCode of X-0.4812, the probe value recorded is -0.48420
So is for X0.4812, the recorded value is recorded as 0.47820
Solutions:
a) Ask Artsoft to correct this bug (I doubt they would do it as they are desperately working on Mach4 at this time);
b) Enter backlash values in AL and do the correction there;
c) Turn backlash compensation off and restart Mach3 before probing.

2. If the values are not absolutely identical like -0.34039 instead of -0.34040 then a Confirm popup window complains that The milling area is not contained by the probing area...
Solutions:
a) Accept as is
b) AL could try rounding the values to four digits.
If edited the file and rounded the values to four digits, no popup ans the Levelled GCode file is created.
( I have not tried to etch the circuit at this time but I suppose it is correct)

3. When I first launch AL from an icon of the desktop, after some 15 seconds, AL shuts down and reopens with a new empty window. Whatever I did, like Browse and open a GCode is forgotten.
Thats not really a problem just very odd. I'm using Windows 7 64bit.
Gaston
kvnrydberg
Posts: 19
Joined: Thu Jul 17, 2014 4:46 am

Re: No Levelled GCode file is created

Post by kvnrydberg »

Just wanted to let you know that I have downloaded the latest fixes and have had no problems so far. Thanks again. As far as Gaston's observations, there was another user who was having the same problem loading AL with Windows 7. I am also using Windows 7, but I haven't seen this. It may be because my system is 32 bit. And, although the probe files are indeed incorrect with backlash enabled, even with a large amount of backlash compensation, the error will be tiny compared to the likely probe step size. The default step of .375" seems to give me perfectly good results, so for PCB's at least it shouldn't matter much if the actual point probed differs all that much from the point AL uses for its calculations. I guess, if you're probing something with a great deal of random variance, you'd run into problems...
Post Reply