Cheap & simple height-probing

[casainho]

This works by probing the pcb surface in a grid over the PCB's area, and then, in the G-code, interpolating the Z coord accordingly.

In other words, you run the g-code from pcb-gcode through a program and run the G-code that comes out on your machine, and your machine will do all the necessary math to interpolate to the right height.

The data for that interpolation and the interpolation is done just one time at begin or is done continuous?

In theory, pcb-gcode could emit height-probing g-code directly, but I have no intention of trying to do that, because I still want the job sorted afterwards to speed it up.

I have no idea if it works on other software than EMC2, EMC2 is what I have.

I also use EMC2 but I use Kicad for schematic and PCB design and not Eagle, and after pcb2gcode for gerber to gcode conversion.

Will this tools also works with your code?

If you have not, see my original explanation at:

http://phk.freebsd.dk/CncPcb/

I already read you page, a few times to see if I understand.

Can you point me some links so I can learn about this height probing? -- I am new to CNC, maybe people are doing this height probing in some other ways, no? is there any ready tools for this on market? is there any specific gcode for this task?

[dhookings]

Could you share this code?

Thanks

Well - here it is:
Bear in mind it is very much tailored for my use. It opens using the mach3...operator...vb editor menu.
The paths have to be set to the code you wish to alter. After it has run you will have a file called 'matrix' which contains the height probe information and a file called 'temp' which contains the new gcode with the z heights added. As it uses G31 you have to have a feed back to mach3 for when the tool touches the pcb. (tool not turning).
The parsing relies on the gcode being produced by Target 3001. You can alter it as you like to conform to any other syntax.
If you can see any obvious errors, let us know, but I have used this in anger a few times now quite successfully.

USE AT YOUR OWN RISK Cut air first

Dave

[dhookings]

Let's see if I can upload this code now:

[casainho]

I guess I understand now better how this should work.

I am trying to compile "pcbopt.c" doing this:

cc -o pcbopt -lm emit_gcode.c pcbopt.c

But I get this error:

/tmp/cckmHpif.o: In function `emit_segment':
emit_gcode.c:(.text+0x3f0): undefined reference to `bit_width'
/tmp/cckmHpif.o: In function `emit_gcode':
emit_gcode.c:(.text+0xcc3): undefined reference to `bit_width'
collect2: ld returned 1 exit status

I would also like to know if this code can work with gerber files generated from KiCad...

[dhookings]

Let's see if I can upload this code now:

I just thought there might be some interest in the results of this height probing:


"http://www.youtube.com/watch?v=z2TzC4VU_os"]YouTube- PCB isolation routing - yet again


dave

[casainho]

I just thought there might be some interest in the results of this height probing:

What a luck do you have :-)

I am looking at this since a few time, also I was yesterday asking on EMC IRC Channel asking for help.

Could you please tell me what you did? like what files did you use, how to compile them and how to use them with the gerbers?

I have a Wolfgang enginiering spindle and I need to make a PCB for LQFP package which have 0.5mm pitch. The tracks need to be 2.5mm...

Thanks.

[dhookings]

What a luck do you have :-)

I am looking at this since a few time, also I was yesterday asking on EMC IRC Channel asking for help.

Could you please tell me what you did? like what files did you use, how to compile them and how to use them with the gerbers?

I have a Wolfgang enginiering spindle and I need to make a PCB for LQFP package which have 0.5mm pitch. The tracks need to be 2.5mm...

Thanks.

Unfortunately the answers to your questions are no, no, and no. The files produced by Target are straight G Code with an extension of .iso. If you get the free trial you can look at the way you produce these. Gerber or EMC do not come into the equation at all. The height probing is done in Mach3 using Visual Basic as described in my previous post.

I would not have considered .5mm until recently, but I think it could be possible using my new technique.

Dave

[casainho]

Unfortunately the answers to your questions are no, no, and no. The files produced by Target are straight G Code with an extension of .iso. If you get the free trial you can look at the way you produce these. Gerber or EMC do not come into the equation at all. The height probing is done in Mach3 using Visual Basic as described in my previous post.

I would not have considered .5mm until recently, but I think it could be possible using my new technique.

Dave

Thanks! I am just using Free Software, and then I need to learn how to do it using EMC2 and Linux Ubuntu :-)

I wish Poul-Henning could help...

[casainho]

I did build the files on Ubuntu 9.10 doing this: "cc -o plt2g -lm emit_gcode.c plt2g.c"

Then I did: "./plt2g testpcb.nc" and I got an "empty" gcode file with name "_.ngc":

(XXX: bla bla bla)

(Things you can change
#1=12 (Clearance height)
#2=1 (Traverse height)
#3=-.1 (Route depth)
#4=-1 (Probe depth)

(Things you should not change
G21 (mm)
G90 (Abs coords)

M05 (Stop Motor)
G00 Z[#1] (Safe height)
G00 X0 Y0 (.. on the ranch)

(probe grid)
(params: x y traverse_height probe_depth)
O100 sub
G00 X[#1] Y[#2] Z[#3]
G38.2 Z[#4] F25
G00 Z[#3]
O100 endsub
(PROBE[0,0] 0.000 0.000 -> 2000)
O100 call [0.000] [0.000] [#2] [#4]
#2000=#5063
(PROBE[0,1] 0.000 98322.465 -> 2001)
O100 call [0.000] [98322.465] [#2] [#4]
#2001=#5063
(PROBE[0,2] 0.000 196644.930 -> 2002)
O100 call [0.000] [196644.930] [#2] [#4]
#2002=#5063
(PROBE[0,3] 0.000 294967.395 -> 2003)
O100 call [0.000] [294967.395] [#2] [#4]
#2003=#5063
(PROBE[1,3] 98322.465 294967.395 -> 2004)
O100 call [98322.465] [294967.395] [#2] [#4]
#2004=#5063
(PROBE[1,2] 98322.465 196644.930 -> 2005)
O100 call [98322.465] [196644.930] [#2] [#4]
#2005=#5063
(PROBE[1,1] 98322.465 98322.465 -> 2006)
O100 call [98322.465] [98322.465] [#2] [#4]
#2006=#5063
(PROBE[1,0] 98322.465 0.000 -> 2007)
O100 call [98322.465] [0.000] [#2] [#4]
#2007=#5063
(PROBE[2,0] 196644.930 0.000 -> 2008)
O100 call [196644.930] [0.000] [#2] [#4]
#2008=#5063
(PROBE[2,1] 196644.930 98322.465 -> 2009)
O100 call [196644.930] [98322.465] [#2] [#4]
#2009=#5063
(PROBE[2,2] 196644.930 196644.930 -> 2010)
O100 call [196644.930] [196644.930] [#2] [#4]
#2010=#5063
(PROBE[2,3] 196644.930 294967.395 -> 2011)
O100 call [196644.930] [294967.395] [#2] [#4]
#2011=#5063
(PROBE[3,3] 294967.395 294967.395 -> 2012)
O100 call [294967.395] [294967.395] [#2] [#4]
#2012=#5063
(PROBE[3,2] 294967.395 196644.930 -> 2013)
O100 call [294967.395] [196644.930] [#2] [#4]
#2013=#5063
(PROBE[3,1] 294967.395 98322.465 -> 2014)
O100 call [294967.395] [98322.465] [#2] [#4]
#2014=#5063
(PROBE[3,0] 294967.395 0.000 -> 2015)
O100 call [294967.395] [0.000] [#2] [#4]
#2015=#5063

(Gentlemen, start your engines)
M03 S1000
G00 X0 Y0 Z[#2] (.. on the ranch)

M05 (Motor off)
G00 Z[#1] (Safe height)
M02

----

What I am doing wrong?

And if I try to build "pcbopt.c" like this" cc -o pcbopt -lm emit_gcode.c pcbopt.c" I get this error:

/tmp/cccTKnDR.o: In function `emit_segment':
emit_gcode.c.text+0x3f0): undefined reference to `bit_width'
/tmp/cccTKnDR.o: In function `emit_gcode':
emit_gcode.c.text+0xcc3): undefined reference to `bit_width'
collect2: ld returned 1 exit status

[Gunnar]

Hi!
Is there anyone that have the err.h and sys/queue.h that are used in this program. If somone have it could they post it here. I am trying to compile the software but i don't have this two files.

Best regards
Gunnar

[casainho]

Hi!
Is there anyone that have the err.h and sys/queue.h that are used in this program. If somone have it could they post it here. I am trying to compile the software but i don't have this two files.

Best regards
Gunnar

Use the files I shared on last message, and build them with the info I provided.

[bsdphk]

Hi!
Is there anyone that have the err.h and sys/queue.h that are used in this program.

Hi Gunnar,

You can pull them out of the FreeBSD source tree:

http://svn.freebsd.org/viewvc/base/h...06&view=markup

and

http://svn.freebsd.org/viewvc/base/h...64&view=markup

Poul-Henning

[Gunnar]

Hi Poul-Henning!
Thank you for the answer, that help alot. But i still have problem to find one file. That is machine/_types.h
I tried to move one i found http://svn.freebsd.org/viewvc/base/h...s/sys/_types.h to a machine directory but that didn't work.
I have search the FreeBSD source tree, but there are so many file and directories that i can't find it. Is there any way to search in this big amount of files?

Regards
Gunnar

[michael_m]

I can't do C, and I couldn't work out how to compile that beautiful piece of C code that was previously posted. And I use EMC in linux so visual basic didn't help!!!

So, I have written a little script in python (which I can do, albeit inexpertly) that re writes the original ngc file to include an introductory probe grid, configured so as the grid just surrounds the work, and replaces all the etch moves in the original ngc file with an etch subroutine call that makes use of the probe data. It writes its G code output to EMC.

It's not fancy - there is no path optimisation - but it does reject Z adjustments less than 0.02mm - and it isn't smart enough to reject outlier data.

It scans into EMC OK and looks OK on the simulator. I'll test it out on the weekend on some real PCBs and post it if it works...

[casainho]

I can't do C, and I couldn't work out how to compile that beautiful piece of C code that was previously posted. And I use EMC in linux so visual basic didn't help!!!

So, I have written a little script in python (which I can do, albeit inexpertly) that re writes the original ngc file to include an introductory probe grid, configured so as the grid just surrounds the work, and replaces all the etch moves in the original ngc file with an etch subroutine call that makes use of the probe data. It writes its G code output to EMC.

It's not fancy - there is no path optimisation - but it does reject Z adjustments less than 0.02mm - and it isn't smart enough to reject outlier data.

It scans into EMC OK and looks OK on the simulator. I'll test it out on the weekend on some real PCBs and post it if it works...

Great! I do not have my CNC assembled/working now, but I would love to test/use your python code! Thanks :-)

[chuck99z28]

Wow, you guys are moving right along on this. I thought it was a psdphk's original code.

I use Mach3 also, so I'm going to follow dhookings methods.

I'm confused on how to run the vb script from within Mach3.
Do you simput run it from the script editor or is there a plug in?

Could you point me in the right direction?

[dhookings]

Chuck,

I load the macro into the visual basic editor. There are two lines that have to be edited to point to the gcode file that you want to work from. The first line is for the probing extents and the second line is for producing the new gcode. Then, click on run(ensuring, of course, that you have the sensor set up so that G31 works).
After this macro runs you have a file called temp in c:\mach3\gcode that is your new gcode to be loaded as normal. There is no point in saving this file for future use, because as soon as you use it and put a new board on the table, it is no longer accurate.
Bear in mind that this programme is specifically designed for the output of Target 3001. Target always uses 'G01' for x/y moves and 'G1' for Z moves. I use this difference in my parsing of the code. If you use another programme for producing the isolation code this would have to be taken into account. The main part, producing amended Z heights, would still be the same.
If you do intend to use Target, I can give more information about breaking the code up, so that you can get top and bottom amended gcode.

Regards

Dave

[chuck99z28]

Thanks for the reply.
I don't intend to use Target, but I haven't looked deeply into it yet. Maybe this weekend.

My main problem is getting the cut depth to be consistent within 0.001" across the whole surface of the board. There are lots of factors, sligh warps in the board, a little extra copper buildup on one area, the rubber mat which helps seal the vacuum table. Even though the table surface is milled perfectly flat I seem to get up to a 0.005" difference in some cases.

If I could compensate that with your virtual "floating z axis" routine then things would be golden. I scored a electronic dial indicator from EBay which now mounts perfectly where the spindle goes. I'm even considering running the g-code but instead of milling I would be measuring the entire path and adjusting the z-axis depth into a second file as you did.

Such as, if depth changes write z-axis compensation to the file.

Anyway, thanks for your help.

[dhookings]

I did not intend to use Target either, but ended up loving it. The point is, that a free trial is pin limited but all other functions, inlcuding 3d view, are on. There is definitely enough functionality to route a respectable board. If you just did a simple single sided design it would be easy to do some trials, before getting too involved. I'm assuming you have an input to mach for the probe?
I would be wary of probing with anything other than the exact tool, in position. I don't want to get too technical, but we are dealing with gnat's whiskers here :-)

Regards

Dave

[michael_m]

OK got it working...

Python code is attached. Read the intro to the code for instructions for use. To get it to run in python, change the file name extension from .txt to .py

Seems to work best with 0.15 as the etch depth - probably not as accurate as the C version. However it does give a nice clean etch.

As per Poul-Henning's original idea, it gets your mill to probe a grid on a blank PCB based on user defined spacing (20mm seems to work OK). It stores the probed Z values to memory, then uses those Z values to adjust Z heights for etch moves along the by now very well probed PCB. You can reuse the generated file again and again as it will always start out by re-probing the surface before etching.

It's python so it's very easy to use, it's especially easy to use in EMC2. However the current version:
- doesn't reject spurious probe values - you need to make sure the PCB blank you use is clean and free of debris
- doesn't optimise X Y paths (you could use opti_qt.exe to do this first - see http://pcbgcode.org/read.php?6,5,5))
- doesn't optimise X Y moves between drills (Opti_qt can do this for 'simple drill moves' for a single drill size, Gopt can apparently do it for multiple drill sizes)
-doesn't adjust Z heights during arc etching (G02 and G03 moves) - this should not be a problem if arcs have a diameter of less than 10mm.

Feel free to address any of these issues!