1. jpcgt
  2. FlatCAM
  3. Issues

Issues

Issue #188 resolved

Order of the drill bits in Gcode generation from Excellon file

Marius Stanciu
created an issue

I think that it will be better to have the drill bits ordered (from the lower diameter to the higher preferably) in the the GCode generated from the Excellon drill file.

REASON:

My drill bits are in metric system. When we are working with an EDA software we still have to switch in between imperial and metric units, sometime in the same project (most of the through hole components have a pin pitch in imperial units while most of the modern SMT components are in metric). Some footprints for the components are made in imperial units so they have the drill bits diameters stated in inch and sub divisions, thous (mils). When in inch (mils) the drill bit diameter is a nice round number but when converted to mm's it will give something with many decimals.

Because of those above, I frequently find myself in the following situation. When I am looking to my design drill hole diameter list, converted from inch into mm's, I found diameters like (example following, the numbers are not realistic but around there): 1.0mm, 1.0017mm, 0.59999mm, 0.6mm and so on.

Usually, when I see the above, I simply ignore the toolchange request and hit continue but because of the way Flatcam is generating the Gcode, sometimes I cannot do that. Because Flatcam likes to select first one drill bit, let's say 0.6mm and then 3mm, and then 0.5999mm and then maybe 1.0017mm and so on.

You see, in this way I am forced to change the drill bits more than it is necessary. 0.6mm and 0.5999mm can be drilled with the same drill bit and so on.

I know that I could solve this in EDA software by modifying the footprints and changing the drill diameters but this is a tedious task and time consuming.

What I would like to see is that the Gcode generated by Flatcam is at least ordered in the sense that the drill bits toochange requests are made in a ordered fashion.

A better way will be to treat this like they do in pcb2gcode ULP plugin for EagleCAD. They create a list of drill bits and then an interval of drill request diameters for each drill bit. In this way, when the software encounter a drill diameter inside a certain interval, it will select the appointed tool (drill bit).

This way you have only one tool selected and the Gcode for let's say 0.59999mm drill diameter and for 0.6mm drill diameter are generated for only one tool, in my case 0.6mm.

Example:

Real Drills Interval low Interval high

0.5mm 0.45mm 0.52mm

0.6mm 0.52mm 0.62mm

0.7mm 0.62mm 0.72mm

and so on.

Comments (11)

  1. Marius Stanciu reporter

    I might have solved this issue but I am not sure if I am not breaking something else.

    JP could you please check if the modification does not affect other parts of the code as I am working blind here (just a little monkeying with the code since me and Mr Python are strangers).

    By replacing the "for tool in points" line from generate_from_excellon_by_tool function (part of CNCjob class) in camlib.py file:

            for tool in points:
    
                # Tool change sequence (optional)
                if toolchange:
                    gcode += "G00 Z%.4f\n" % toolchangez
                    gcode += "T%d\n" % int(tool)  # Indicate tool slot (for automatic tool changer)
                    gcode += "M5\n"  # Spindle Stop
                    gcode += "M6\n"  # Tool change
                    gcode += "(MSG, Change to tool dia=%.4f)\n" % exobj.tools[tool]["C"]
                    gcode += "M0\n"  # Temporary machine stop
                    if self.spindlespeed is not None:
                        gcode += "M03 S%d\n" % int(self.spindlespeed)  # Spindle start with configured speed
                    else:
                        gcode += "M03\n"  # Spindle start
    
                # Drillling!
                for point in points[tool]:
                    x, y = point.coords.xy
                    gcode += t % (x[0], y[0])
                    gcode += down + up
    
            gcode += t % (0, 0)
            gcode += "M05\n"  # Spindle stop
    
            self.gcode = gcode
    

    with "for tool in tools" like this:

    for tool in tools:
    
                # Tool change sequence (optional)
                if toolchange:
                    gcode += "G00 Z%.4f\n" % toolchangez
                    gcode += "T%d\n" % int(tool)  # Indicate tool slot (for automatic tool changer)
                    gcode += "M5\n"  # Spindle Stop
                    gcode += "M6\n"  # Tool change
                    gcode += "(MSG, Change to tool dia=%.4f)\n" % exobj.tools[tool]["C"]
                    gcode += "M0\n"  # Temporary machine stop
                    if self.spindlespeed is not None:
                        gcode += "M03 S%d\n" % int(self.spindlespeed)  # Spindle start with configured speed
                    else:
                        gcode += "M03\n"  # Spindle start
    
                # Drillling!
                for point in points[tool]:
                    x, y = point.coords.xy
                    gcode += t % (x[0], y[0])
                    gcode += down + up
    
            gcode += t % (0, 0)
            gcode += "M05\n"  # Spindle stop
    
            self.gcode = gcode
    

    I actually get a Gcode with tools ordered from the lowest diameter to the highest.

    LE: If I select only some of the tools in the software interface, those tools are also ordered.

  2. Marius Stanciu reporter

    Actually it seems that it is not enough to replace

    for tool in points 
    

    with

    for tool in tools
    

    I just had an Excellon file with 12 tools. If the above mentioned line is replaced in this way I get a list of ordered tools like: 1,10,11,12,2,3,4,5,6,7,8,9 which is not good.

    I researched a bit and if we add line 2720 on the generate_from_excellon_by_tool function from camlib.py file like this:

    def generate_from_excellon_by_tool(self, exobj, tools="all",
                                           fastr=False, toolchange=False, manual_toolchange=False, toolchangez=0.1):
            """
            Creates gcode for this object from an Excellon object
            for the specified tools.
    
            :param exobj: Excellon object to process
            :type exobj: Excellon
            :param tools: Comma separated tool names
            :type: tools: str
            :return: None
            :rtype: None
            """
    
            log.debug("Creating CNC Job from Excellon...")
            # Tools
            if tools == "all":
                tools = [tool for tool in exobj.tools]
            else:
                tools = [x.strip() for x in tools.split(",")]
                tools = filter(lambda i: i in exobj.tools, tools)
            tools.sort(key=int) # it will sort the tools in G-code regardless of the order in the GUI list
    
    # and the function continue ....
    

    The last line is the one added.

    it will sort the list of tools in the right order:

    1,2,3,4,5,6,7,8,9,10,11,12

    I think that having the tools ordered regardless of the order in GUI is the right thing to do.

    It will also be nice to have all the tools selected as a default since it is reasonable to think that you used those tools because you need them ... I did not figured out (yet) how to do it.

  3. Marius Stanciu reporter

    Even with the fix from above, the sorting is not foolproof. Sometimes the Excellon file does not have the tools ordered by diameter so doing an order by the tool name does not guarantee that we will have an ascending sorting of the drill bits by diameter.

    I submitted a pull request that address this issue by performing a sorting on the tool table diameter column and it also will pre select all the tools by default.

    JP, is it possible that the GUI tool table could show dynamically all the rows (depending on the number of the tools)? Right now we have to use the slider from the right side, in a tiny table with only 3 rows, and when selecting only a number of tools you can't see all at once.

  4. Marius Stanciu reporter

    I found that the "tiny" tool table QT widget is set with a fixed height of 100pixels. I did made a quick hack that made the height of the widget adjust to the number of rows in the table. After the previously made pull request is accepted (or rejected) I will make another one with this fix. It is much much easier to make a custom selection of tools in this way.

  5. Marius Stanciu reporter

    I submitted a new pull request that perform the same sorting of tools for the Excellon file but this time is done in Python (the previous was done with QT methods, practically in UI).

    Both should work together well as the previous pull request on this subject also make visible the tool sorting in the GUI tool table.

  6. Log in to comment