Cheap & simple height-probing - Page 3

Page 3 of 9 FirstFirst 123456 ... LastLast
Results 41 to 60 of 169

Thread: Cheap & simple height-probing

  1. #41
    Registered
    Join Date
    Aug 2009
    Location
    Portugal
    Posts
    62
    Downloads
    0
    Uploads
    0

    Default

    Quote Originally Posted by michael_m View Post
    It's python so it's very easy to use, it's especially easy to use in EMC2.
    Many thanks for sharing! Being Python I think it will be much more easy for everyone use... no need to compile/build as the Poul-Henning C code.

    I do not have my CNC working yet, but I really need to mill 2 PCBs and I will try this code on that time.

    If I find something I will share. Thanks ;-)

    I use this program to convert the gerber files exported by KiCad.

    Last edited by casainho; 07-25-2010 at 09:35 AM.


  2. #42
    Registered
    Join Date
    Apr 2009
    Location
    Denmark
    Posts
    42
    Downloads
    0
    Uploads
    0

    Default

    Quote Originally Posted by michael_m View Post
    OK got it working...

    Python code is attached.
    Hey, great idea, thanks for doing that.

    I have not had as much time to spend on this as I (and others) had hoped, so I'm glad to see independent development using this idea.

    Seems to work best with 0.15 as the etch depth...
    In my experience the depth setting depends a lot on your your bit, but which parameters of the bit I have no idea.

    ...on user defined spacing (20mm seems to work OK).
    ...
    -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.
    I found that 25mm was too big a grid, and went to approx 10mm probe grid. Probably depends how well your PCB is mounted.

    The G-Code I get out of pcb-gcode does not have G02/G03 arcs in it, they have all been flattened, so I have not had to contend with that problem.

    I'll give your python code a whirl next time, would be most smart if we could end up just having one program for it.

    Poul-Henning



  3. #43
    Registered
    Join Date
    Jul 2010
    Location
    Australia
    Posts
    32
    Downloads
    0
    Uploads
    0

    Default Generic TSP solvers that are fast - and free...

    One of the nice things about python (and visual basic for that matter) is that it's easy to use. But - it's not fast.

    To optimise the milling and drilling paths you can't beat a decent compiled file. For a general solution we would need to have a program that had a windows version, an ubuntu 8.04 linux version (for all those EMC2 users), and which had its source code available for all the C code compiler dudes to use...

    There are already a number of really good, really fast, generic TSP (Travelling Salesman Problem) solvers out there that fit that exactly specification - compiled programs that python or visual basic code could pass the data to, then when the optimised generic solution is returned, format it and stitch it back into the gcode.

    The results these programs give for the number of datapoints were are using would be pretty close to perfect - they are used to optimising hundreds of thousands of data points...

    Concorde TSP apparently is the best but is not that easy to use (and would be like using a sledge hammer to crack a peanut).

    LKH in particular is really easy to use - you call it, pass it the name of a parameter file and it solves the problem for you in in milliseconds. But it is not freeware (unless you are a researcher) see: http://www.akira.ruc.dk/~keld/research/LKH/ If you have time, download it and have a play - it's pretty impressive, very fast and very easy to use.

    Does anyone out there know of any good, fast, easy to use generic TSP solvers, that run under both linux and windows, (kind of like LKH) that we could use to plug data into - that are free???



  4. #44
    Registered
    Join Date
    Aug 2009
    Location
    Portugal
    Posts
    62
    Downloads
    0
    Uploads
    0

    Default

    Problem with etch_z_adjust.py

    I were testing because I need to mill one PCB. Here the image of original GCode on EMC2:


    And here after apply etch_z_adjust.py:


    As we can see, etch_z_adjust.py adds 4 probing points at begin which it shouldn't, right? Or I do not understand... -- please help me.

    Also the pcb2gcode program I am using outputs code just in inch, so I add to adjust <_z_probe>, <_etch_depth>, etc to match inch values. Luckily all seems ok :-)

    How to connect the electronic signal to parallel port and EMC2

    I would like to connect the wire needed to parallel port. My controller have parallel inputs protected by optocoupler - the board manual is here - seller page "3 Axis Stepper Motor Driver" from http://www.easy-cnc.com.

    Does anyone knows if I need to connect the wire to any specific parallel port pin?
    How do I configure it on EMC2?

    Picture of my controller:


    Attached Thumbnails Attached Thumbnails Cheap &amp; simple height-probing-original-jpg   Cheap &amp; simple height-probing-z_adjust-jpg  
    Last edited by casainho; 07-27-2010 at 07:32 AM.


  5. #45
    Registered
    Join Date
    Apr 2009
    Location
    Denmark
    Posts
    42
    Downloads
    0
    Uploads
    0

    Default

    Quote Originally Posted by michael_m View Post
    One of the nice things about python (and visual basic for that matter) is that it's easy to use. But - it's not fast.

    To optimise the milling and drilling paths you can't beat a decent compiled file. [...]
    First, never ask if a computer program "is fast", always ask if it is "fast enough".

    The relevant question here is if the time spent optimizing the path is saved again while routing the PCB. As long as you end up saving significant time in the end, the program is fast enough.

    My experience is that, as so often, that the easy 20% of the optimization saves 80% of the routing time, there is no relevant time difference saved beteen a 99% and a 99.9% optimized path.

    The fun I had optimizing the paths in my C-code version were largely academical, because the optimization task is not a straight Traveling Salesman Problem.

    The paths output by pcb-gcode are all closed curves, and since you can start routing all of these at an arbitrary point, most, if not all, standard TSP algorithms miss a ton of opportunities for optimization.

    The best analogy for the task I have come up with, is a water inspector who has to take a water sample from all communal water supplies in the state. It doesn't matter where on the townships waterlines he takes the samples, he can freely pick any manhole he wants.

    It is a very interesting variation of TSP, and I spent some enjoyable days playing with it, I can highly recommend it for recreational programming.

    In practical terms, and well within Pythons grasp, is a simple greedy sorting of the curves: Pick the curve that has a point closest to whereever the bit is right now, and route that next. Repeat until done.

    This will likely get you at least 50% of theoretical optimization.

    Another way to optimize routing time, is to use different routing speeds, depending on where/what your route:

    First run high speed on all the curves which do not touch the final traces, and then finish with a slow pass on the innermost curves, to get a high quality edge finish.

    For all isolations on your pcb requiring more than one pass to get the necessary width (anything >16mil ?) you will save oodles of spindle time.

    With the pcb-gcode output, this is pretty easy to implement, because the curves are output "nested". I asked the pcb-gcode author to include comment in the output file after each "pass" of curves, but I have not checked if he has added this feature.

    I can't remember if the order is innermost to outhermost curves or the other way, it would be beneficial if they were outher->inner, because then you don't even have to sort the curves to get this right.

    (The inner most curves should be done last, so the bit does not have to carve both edges of the copper)

    Poul-Henning



  6. #46
    Registered
    Join Date
    Jul 2010
    Location
    Australia
    Posts
    32
    Downloads
    0
    Uploads
    0

    Default

    Poul_Henning: Time is one factor, the other factor is wear and tear. A nicely optimised program will be quicker (and cause less spindle wear), but it will also cause less wear and tear on the leadscrews because there is less X Y movement. Plus the idea is appealing!!

    I have to say I'm not an expert on the TSP thing, but with regard to the etching (the most time consuming part) the solution I was going to use was to call the isolation track a subtour that is defined at the outset as being an optimal path and therefore not to be further optimised, and give the generic solver program a collection of these subtours to optimise - and see what happened!

    On reflection the effort involved to do all that rather than just using a simple 'greedy' strategy in python is considerable, and as you say, for not much gain. OK...

    PCB Gcode has the the path between drills flying all over the place so I have to say I do optimise these (using Excel believe it or not - see yakpol.net/TravellingSalesman.xls ) just so I don't have to watch my leadscrews flying up and down and getting worn away. Again as you say a greedy strategy would get you pretty close, and if it's all done in python it's pretty straightforward.

    I'll go for your simple approach...

    Give me a few weeks!



  7. #47
    Registered
    Join Date
    Jul 2010
    Location
    Australia
    Posts
    32
    Downloads
    0
    Uploads
    0

    Default

    Casainho: looking at your images, I don't see any probe grid paths, so I'm pretty sure it's a scale thing to do with your using inches ie your grid size is probably 20 inches (not 20mm) square. The default grid size is 20mm (and it's been suggested 10mm is probably better), so if you are using inches, try setting the grid size to be say 0.5 and see how that goes. If that works, change the default grid size in your python code to be 0.5 for your inch machine.

    Re setting up the probe in EMC2: the documentation is there in the EMC2 wiki but you have to go looking for it... I used pin 13 because when I made a breakout board it was the easiest pin to connect to.

    I found these links useful:
    http://wiki.linuxcnc.org/emcinfo.pl?Touch_Probe
    (it tells you the line to add to your standard_pinout.hal file)

    http://wiki.linuxcnc.org/cgi-bin/emc...el_Port_Tester
    (gives you a little display that shows you whats happening on the parallel port pins when you fiddle with them)

    If you can document the process as you discover it, it would be very helpful for others that follow - the EMC2 wiki is not detailed, and there may be other steps I've forgotten...

    Good luck!



  8. #48
    Registered
    Join Date
    Dec 2004
    Location
    Memphis, TN
    Posts
    1137
    Downloads
    0
    Uploads
    0

    Default

    Quote Originally Posted by michael_m View Post
    Poul_Henning: Time is one factor, the other factor is wear and tear. A nicely optimised program will be quicker (and cause less spindle wear), but it will also cause less wear and tear on the leadscrews because there is less X Y movement. Plus the idea is appealing!!

    I have to say I'm not an expert on the TSP thing, but with regard to the etching (the most time consuming part) the solution I was going to use was to call the isolation track a subtour that is defined at the outset as being an optimal path and therefore not to be further optimised, and give the generic solver program a collection of these subtours to optimise - and see what happened!

    On reflection the effort involved to do all that rather than just using a simple 'greedy' strategy in python is considerable, and as you say, for not much gain. OK...

    PCB Gcode has the the path between drills flying all over the place so I have to say I do optimise these (using Excel believe it or not - see yakpol.net/TravellingSalesman.xls ) just so I don't have to watch my leadscrews flying up and down and getting worn away. Again as you say a greedy strategy would get you pretty close, and if it's all done in python it's pretty straightforward.

    I'll go for your simple approach...

    Give me a few weeks!
    The Opti program looks for the PCB_Gcode paths. A path is defined as a negative move in the Z, a series of X-Y coordinates and a retract in the Z. The first pass gathers all of these paths into an input vector (single dimension array). I chose to keep the first and last paths in their original order. Thus the system starts with the original first path. From the endpoint coordinates it walks the entire vector looking for the shortest path to another path. This is a simple sqrt(|x2-x1|^2 + |y2-y1|^2). It then moves this path from the input vector and places it in the output vector. So on and so forth until the vector is empty.

    All of the source code for Opti is freely available and written in C++ for QT (available on Windows, Mac, and Linux). I'm more of a C coder, but fitting the C code into the C++ framework wasn't too difficult.

    I'm following this thread, but right now, I don't have the time to do much more than offer words of encouragement

    -Jay



  9. #49
    Registered
    Join Date
    Aug 2009
    Location
    Portugal
    Posts
    62
    Downloads
    0
    Uploads
    0

    Default

    Quote Originally Posted by michael_m View Post
    Casainho: looking at your images, I don't see any probe grid paths, so I'm pretty sure it's a scale thing to do with your using inches ie your grid size is probably 20 inches (not 20mm) square. The default grid size is 20mm (and it's been suggested 10mm is probably better), so if you are using inches, try setting the grid size to be say 0.5 and see how that goes. If that works, change the default grid size in your python code to be 0.5 for your inch machine.
    Yes, looks like the problem is the inch instead of mm. Unfortunately pcb2gcode just outputs the gcode in inchs (mm is on TODO list).

    If you want to try my gcode file and develop your code, please get it from here: file "lyre_v1_io-Component.pho.ngc". That's for an Open Source project and so all the files are shared on that place, if you want to generate the gerber files you just need to used KiCad with that source files. Project page is here: http://lyre.sourceforge.net/


    Quote Originally Posted by michael_m View Post
    Re setting up the probe in EMC2: the documentation is there in the EMC2 wiki but you have to go looking for it... I used pin 13 because when I made a breakout board it was the easiest pin to connect to.

    I found these links useful:
    http://wiki.linuxcnc.org/emcinfo.pl?Touch_Probe
    (it tells you the line to add to your standard_pinout.hal file)

    http://wiki.linuxcnc.org/cgi-bin/emc...el_Port_Tester
    (gives you a little display that shows you whats happening on the parallel port pins when you fiddle with them)
    Thanks! With that links/info I got my probe working and did run that gcode that have problems at least until the probing... and it works! I got the "OK folks - power up the mill..." :-)

    So now I just need your code to work for me.

    Right now I am on Linux Ubuntu 8.04 because EMC2 just run on this version. I have here Python 2.4 and I get:
    Code:
    python Etch_Z_adjust.py 
    Traceback (most recent call last):
      File "Etch_Z_adjust.py", line 155, in <module>
        X_span = X_max - X_min
    NameError: name 'X_max' is not defined
    On Ubuntu 10.04 I get none errors, it goes perfect. I have Python 2.5 there.

    Quote Originally Posted by michael_m View Post
    If you can document the process as you discover it, it would be very helpful for others that follow - the EMC2 wiki is not detailed, and there may be other steps I've forgotten...
    I will... and I started to document before with title "CNC milling/drilling of PCB" but on KiCad Wiki page. I think that the best place may be on the EMC2 wiki. I will do it later, I promise. I usually do because later I forget what I did and than is best to read docs than have to do/discover all again :-)



  10. #50
    Registered
    Join Date
    Aug 2009
    Location
    Portugal
    Posts
    62
    Downloads
    0
    Uploads
    0

    Default

    Now it seems to work:



    At starting of your gcode, you put a "G21 (mm)" while the rest of code is in G20 (inchs). I just changed your gcode for G20 :-)

    The only question now seems that grid is with 1 inch, which is a lot, I think.

    Also looks to me that if the code mill a big line, the Z value is always the same all over the length of the line... which I think is a problem because there should be different Z values over all the line, right?

    Attached Thumbnails Attached Thumbnails Cheap &amp; simple height-probing-capturaecra-jpg  


  11. #51
    Registered
    Join Date
    Jul 2010
    Location
    Australia
    Posts
    32
    Downloads
    0
    Uploads
    0

    Default

    Hey well done casainho! That inch / mm thing does my head in... I just stick to mm... I had a look at your first file and I couldn't work it out.

    I have a minor alteration to the code so you can use it in inches - the step size was previously required to be an integer (for no very good reason). I've changed it to allow a float value by altering the Tkinter instruction to ask for a float rather than an integer. So now you can make the step size as small as 0.05. Inch users should also look at the python intro for how to make the *two* minor changes that they will require. (These could be automated eventually)

    For all us mm users out there, I have changed the default grid size to 10 which based on PHK's previous experience will work better. Inch users should change this to eg 0.4

    Re long lines - Aha! I thought of that - buried in the intro you will read:

    "For long etch moves it puts in a way point every 5mm (or half the grid spacing if you change the 10mm default gridspacing) to calculate new heights as it goes along"

    So you should be fine.

    PS don't forget to change the file extension to .py after you download it!

    Attached Files Attached Files
    Last edited by michael_m; 07-28-2010 at 09:15 AM. Reason: corrected attached file (as above)


  12. #52
    Registered
    Join Date
    Aug 2009
    Location
    Portugal
    Posts
    62
    Downloads
    0
    Uploads
    0

    Default

    I get a warning while loading the gcode on EMC2: "Attempt to dive by zero" on this line:

    Code:
         #<waypoint_number> = fix[#<distance> / [#<_step_size>/2

    eheh, you forgot to change this line:
    Code:
    line =  '#<_step_size>     = %d' % (step_size)
    Ok, changed to:
    Code:
    line =  '#<_step_size>     = %.4f' % (step_size)
    And it look like to work :-)

    I hope to be able to test this today on my CNC. I will post pictures :-)



  13. #53
    Registered
    Join Date
    Jul 2010
    Location
    Australia
    Posts
    32
    Downloads
    0
    Uploads
    0

    Default Corrected version!!!

    Change the first attached file to a .py file, the second to a .wav (otherwise it won't play...)

    Attached Files Attached Files


  14. #54
    Registered
    Join Date
    Aug 2009
    Location
    Portugal
    Posts
    62
    Downloads
    0
    Uploads
    0

    Default

    Quote Originally Posted by michael_m View Post
    Change the first attached file to a .py file, the second to a .wav (otherwise it won't play...)
    I am sending a patch with my changes. You maybe did paste an error of G1 Z40 just after the probing!!!

    I went to test the probing and it worked but just after start milling all went wrong!! Looks like Z values are inverted :-(
    The pads of PCB were milling in air while when the bit should go upper in Z direction it was instead going down against the PCB :-(

    I am sending pictures and even the original gerber file and gcode.





    Attached Thumbnails Attached Thumbnails Cheap &amp; simple height-probing-img_2964-redimensionado-jpg   Cheap &amp; simple height-probing-capturaecra-38-jpg  
    Attached Files Attached Files
    Last edited by casainho; 07-28-2010 at 05:16 PM.


  15. #55
    Registered
    Join Date
    Aug 2009
    Location
    Portugal
    Posts
    62
    Downloads
    0
    Uploads
    0

    Default

    Michael, could you please share a gcode files you are using for testing etch_z_adjust.py? -- I would like to see the original e changed gcode files.

    Maybe the original gcode files I am using are not compatible with your etch_z_adjust.py program...



  16. #56
    Registered
    Join Date
    Jul 2010
    Location
    indonesia
    Posts
    13
    Downloads
    0
    Uploads
    0

    Thumbs up

    hallo all....

    what the software of you use for gerber to G-code..??
    but it must be match with EMC2...
    tell me please,,, i beg..




  17. #57
    Registered
    Join Date
    Aug 2009
    Location
    Portugal
    Posts
    62
    Downloads
    0
    Uploads
    0

    Default

    Quote Originally Posted by tyo View Post
    what the software of you use for gerber to G-code..??
    but it must be match with EMC2...
    I use "pcb2gcode".



  18. #58
    Registered
    Join Date
    Aug 2009
    Location
    Portugal
    Posts
    62
    Downloads
    0
    Uploads
    0

    Default

    Ok, I found a problem. My gcode was being generated like this:

    Code:
    ( Connected component 0: )
    G00 X0.099000 Y2.412000 ( rapid move to begin of connected component )
    G01 Z-0.010000 F20.000000 ( plunge )
    G64 P0.000400 ( set maximum deviation from commanded toolpath )
    X0.099000 Y2.412000
    X1.931000 Y2.412000
    (...)
    X0.093000 Y2.412000
    X0.097000 Y2.412000
    G61 ( mo more deviation! )
    G00 Z0.010000 ( retract )
    (Completed connected component 0.)
    And I believe G64 and G61 are the problems. Well, Michael already told me that on a PM but I didn't understand on that time.

    Since the pcb2gcode is OpenSource (yeah, OpenSource is the best!), I quickly went to sources and saw where that G64 and G61 are being printed... and then I found that I need to make "--max-deviation=0" parameter so pcb2gcode don't print G64 and G61. Now final gcode is (from other file):

    Code:
    ( Connected component 0: )
    G00 X0.529000 Y0.792000 ( rapid move to begin of connected component )
    O200 call [0.5290] [0.7920] [0.5290] [0.7920]
    O200 call [0.5290] [0.7920] [0.5290] [0.7920]
    O200 call [0.5290] [0.7920] [0.5420] [0.7920]
    O200 call [0.5420] [0.7920] [0.5420] [0.7280]
    O200 call [0.5420] [0.7280] [0.5230] [0.7280]
    O200 call [0.5230] [0.7280] [0.5230] [0.7920]
    O200 call [0.5230] [0.7920] [0.5270] [0.7920]
    G00 Z0.010000 ( retract )
    (Completed connected component 0.)




  19. #59
    Registered
    Join Date
    Jul 2010
    Location
    Australia
    Posts
    32
    Downloads
    0
    Uploads
    0

    Default Etch_Z_adjust.py - default units are all in mm

    First of all, can I just say, Etch_Z_adjust.py works well, and has worked perfectly for me ever since I posted it.

    But, here is my set up: I take output from EAGLE 5.10 via PCB Gcode in millimetres, then run Python 2.5 from within EMC2 v 2.3.

    I have attached a G-code file that I used to make my break out board with, for you to see if it works for you too under your set up.

    The problems Casainho has had so far are due to my code not previously being adapted for use with inches. I never use inches! I had a look again, and my last inch fix was incomplete... there were still other default values (in mm) further on that I didn't remember (it was late at night here)... So I've picked them all out now (hopefully) and listed them all below, and in the intro to the program, so you know where and what to change...

    The latest code is the same working code, with instructions added on how to adapt it to inches.

    I agree that it would be good to automate the inch/mm thing, I'll do that further down the track - once I'm reassured I have picked up all the inch anomalies. Casainho, I'm sorry this has caused you these dramas - I just never use inches. Let me know if it works with inches after you make these extra changes.


    ## DEFAULT UNITS ARE ALL IN MM
    # If you need to use inches, you must change all of the following values in the five places listed below
    # (this could be automated later):

    # MM | INCHES

    # 1. set initial values
    # G_dest = '00' | '00' (yep - it's a string)
    # X_dest = -80 | -3.000
    # Y_dest = 40 | -2.000
    # Z_dest = 40 | -2.000

    # 2. if the line is an etch move, then replace the line with an etch call
    # if G_dest == '01' and Z_dest > -0.5:| -0.020

    # 3. G code configuration section
    # G21 (mm) | G20 (inches)
    # #<_etch_speed> = 120 | 4.000
    # #<_probe_speed> = 25 | 1.000
    # #<_z_safety> = 1 | 0.050
    # #<_z_probe> = -1 | -0.050
    # #<_etch_depth> = -0.15 | 0.005

    # 4. ignore trivial z axis moves
    # [#<z_etch> - #<_last_z_etch> ] lt 0.02]| 0.001

    # 5. Withdraw probe
    # G00 Z40 | Z2.000


    NB
    change Etch_Z_adjust extension to .py
    change breakout etc etc extension to .ngc

    Attached Files Attached Files


  20. #60
    Registered
    Join Date
    Aug 2009
    Location
    Portugal
    Posts
    62
    Downloads
    0
    Uploads
    0

    Default

    I got it! It seems to work very well! Here 2 pictures of what I got:



    Workflow
    • export the Gerber files from KiCad (select Plot Origin as Auxiliar Axis)
    • use pcb2gcode to convert Gerber files to Gcode, by executing on command line: pcb2gcode --verbose --zup=0.4 --zchange=1 --offset=0,010 --zdown=0,01 --max-deviation=0 --dpi=1000 --toolpath-smoothing-passes=0 example-Component.pho
    • execute etch_z_adjust.py: python etch_z_adjust.py
    • open the Gcode files with EMC2, run it and it will automatically probe and mill the PCB


    I am attaching the files I am being using.

    A big thanks to Michael and to Poul-Henning ;-)

    I will soon (tomorrow maybe) document all this on EMC2 wiki.

    Attached Files Attached Files


Page 3 of 9 FirstFirst 123456 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


About CNCzone.com

    We are the largest and most active discussion forum for manufacturing industry. The site is 100% free to join and use, so join today!

Follow us on


Our Brands

Cheap &amp; simple height-probing

Cheap &amp; simple height-probing