Etching Problems

[Brtdead]

I've been trying to etch the same small circuit many times. The pcb etching is not level, with air cuts in some places. It is a cheap cnc machine, but have made a sacrificial pocket and used double sided tape, as many have recommended. But the amount of depth difference for such a small board did seem excessive. Looking at the RPF modified code, there seemed to be some inconsistencies, so I made a test case with all probe values at zero. The depth cut was set at -0.25mm.

Code: Select all

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

(1  | X = -5,000000    Y = -5,000000    Z = -0,000000)
(2  | X = 8,527500     Y = -5,000000    Z = -0,000000)
(3  | X = 22,055000    Y = -5,000000    Z = -0,000000)
(4  | X = 22,055000    Y = 5,447500     Z = -0,000000)
(5  | X = 8,527500     Y = 5,447500     Z = 0,000000)
(6  | X = -5,000000    Y = 5,447500     Z = 0,000000)
(7  | X = -5,000000    Y = 15,892500    Z = 0,000000)
(8  | X = 8,527500     Y = 15,892500    Z = 0,000000)
(9  | X = 22,055000    Y = 15,892500    Z = 0,000000)
(10 | X = 22,055000    Y = 26,340000    Z = 0,000000)
(11 | X = 8,527500     Y = 26,340000    Z = 0,000000)
(12 | X = -5,000000    Y = 26,340000    Z = 0,000000)
(13 | X = -5,000000    Y = 36,785000    Z = 0,000000)
(14 | X = 8,527500     Y = 36,785000    Z = 0,000000)
(15 | X = 22,055000    Y = 36,785000    Z = 0,000000)

All the Z values before the first line were the same (Z-0.25), and all the values after the last line were Z0. I did wonder what happened here, if anyone can help? Thanks.

Code: Select all

G1 X1.0181Y7.5907 Z-0.25
G1 X0.9938Y7.5403 Z-0.25
G1 X0.975Y7.4869 Z-0.25
G1 X0.9641Y7.443 Z-0.25
G1 X0.9572Y7.3976 Z-0.25
G1 X0.954Y7.3414 Z-0.25
G0 Z2
G0 X6.6249Y8.6248
G1 Z0
G1 X7.1283Y8.1213 Z0
G1 X7.1394Y8.1117 Z0
G1 X7.1476Y8.1062 Z0
G1 X7.1653Y8.0978 Z0
G1 X7.1843Y8.0931 Z0
G1 X7.199Y8.092 Z0
G1 X8.199Y8.092 Z0

[daedelus]

I have some thoughts and theories on this but could you send me your original gcode and raw probe files to test before I start speculating.

daedelus@autoleveller.co.uk

[Brtdead]

Ok, sure.

GTestEtchTopLayer_0.25mmdepth.nc -is the original GCode
Mach3ALProbeGTestEtchTopLayer_0.nc - is the RPF created by Mach3
Zeroed_Mach3ALProbeGTestEtchTopLayer_0.nc - is the RPF created by Mach3 with probe values zeroed.

The original GCode was created by FlatCam v8.4.

[daedelus]

Thanks for attaching these files, it makes it much easier to spot problems.

Looking at the original gcode, Z is set to 0 there as well...

Code: Select all

...
G01 X0.9572Y7.3976
G01 X0.9540Y7.3414
G00 Z2.0000
G00 X6.6249Y8.6248
G01 Z0.0000 (Z = 0)
G01 X7.1283Y8.1213 (equivalent to G01 X7.1283Y8.1213 Z0)
G01 X7.1394Y8.1117
G01 X7.1476Y8.1062
...

It should be...

Code: Select all

...
G01 X0.9572Y7.3976
G01 X0.9540Y7.3414
G00 Z2.0000
G00 X6.6249Y8.6248
G01 Z-0.25 (Z = -0.25)
G01 X7.1283Y8.1213 (G01 X7.1283Y8.1213 Z-0.25)
G01 X7.1394Y8.1117
G01 X7.1476Y8.1062
...

I have added some comments to help explain. So, for some reason, flatcam has added the Z0.0000 lines when it should be Z-0.25.

I did a search and replace in my text editor to turn all the Z0.0000 lines into Z-0.25 then ran this in AL using your zeroed RPF file and all was fine then (no Z0's, just lots of Z-0.25's). I would suggest looking at why flatcam added the Z0.0000 lines in the first place

This would be a major cause of your air cuts.

[Brtdead]

Sorry about the delay in replying.

Thanks for that, I clearly should've looked at the FlatCam code first. I cannot explain how the Z0.0000's got there, and even worse can't replicate it. But if this is something that can happen (weird race condition in FC?), maybe it could be useful if AL could log an error/warning if it comes across a cut at 0mm?

Anyway, at least there are no major problems now, however on comparing subsequent Mach probe values I'm getting an average variation of around 4 microns with a worst case 10 micron difference. The feedrate had to be lowered to 30mm/min to get such 'good' results (at 100mm/min was getting 30 micron average with highest around 70). Would this be considered ok on a generic chinese built cnc, or are the figures way off? Thanks again for the help.

[daedelus]

This is interesting, looking at one of my old probe files, I am getting a variation of Z of ~0.26mm. Which is ~260 microns. This would have been using a Z feed of 100mm/per min but I dont know much else about the context. I might have used some bits of wire beneath to bend the copper for stress testing purposes for example.

Assuming this is not the case then think you are fine with the default feed of 100mm/pm.

[Brtdead]

Actually the comparison was done between matching coordinates on two distinct probe files, rather than min/max values on the same probe file. Am assuming min to max is what you used given the large variations (0.26mm).
The idea was to keep comparing probe files until the differences were 'negligible' - for example the two test files here have variations of 15um at one point and 10um on the next two positions. Had just thought that 10, or even 5um differences are a bit much?

ALPrbComp2.jpg (55.46 KiB) Viewed 10080 times

On edit: looking through a few of these, the smallest non-zero difference is always 2.5micron. I guess this is also the resolution of the machine.

[daedelus]

Actually the comparison was done between matching coordinates on two distinct probe files, rather than min/max values on the same probe file. Am assuming min to max is what you used given the large variations (0.26mm).
The idea was to keep comparing probe files until the differences were 'negligible'

That makes a lot more sense than comparing min/max in the same file as I was doing I hope to do similar experiments at some time, right now I do not have this information from my machine to hand.

I was thinking before about writing a quick program to compare RPF's like the one in your screenshot, or building it into AE in a separate 'RPF' tab sometime.
Did you make that comparison program?

It would be good if it showed the min and max Z values for individual files next to the average so the spikes I previously mentioned could easily be detected.
Just a thought.

[Brtdead]

Apologies again for the long delay - was waiting for an isolation bit that took a bit longer than it should.

I did make the compare WPF app - and have added statistics for the individual files as suggested. Although trivial, the program has really helped me get a decent result now:-). Often have to probe 3-4 times in order to get the average down to <0.005mm. I would consider the code open source.

I think a lot of the problems were due to poor quality isolation bits - have now got a 2-flute bit from precisebits, and the results are imho brilliant. Thanks especially to AL of course.

Thanks again for your help -even when I was way off the mark!

[daedelus]

The app looks very useful indeed. I can see how this could help massively for diagnosing probe problems and I have been looking in to doing something similar for AE. My ideas are focused on getting stats for individual probe files so maybe I could link to your program if someone needs to compare files side by side?

I noticed from the screenshot that you are comparing a Mach 3 probe file with a Mach 4 one. If the Mach 4 gcodes are the same as Mach 3 then I dont see any reason why AL is not fully compatible with both? Did you need to make any changes to the gcode to make it work in Mach 4?