Drilling order point selection

[GoogleCodeExporter]

It would be handy,in certain situations, to be able to select the order
that drilling is done to points manually. Sometimes it's good to have
absolute control over the order for avoiding clamps.

Thanks,
Dan

Original issue reported on code.google.com by ddfalck2...@yahoo.com on 6 Jul 2009 at 3:04

[GoogleCodeExporter]

Dan,

I see that there are two issues here.  The first is to optimize the order of 
holes
being drilled so as to minimize rapid travel.  The second is to avoid rapid 
movement
through fixtures such as clamps or vices.  I haven't done anything about the
optimization but I think that it would be the easier of the two problems to 
solve.

As for the fixture avoidance, I am a fan of the idea of defining the fixtures as
solid shapes that have some name.  (perhaps have a name that contains one of a 
few
keywords. names like 'vice', 'fixture' or 'clamp' for example).  Since we know 
the
tool path (both rapid and cutting) and we know the geometry of the tools from 
the
CuttingTool objects, we should be able to generate the volume of solids 
represented
by the tool's geometry travelling through the tool's path.  We could then 
subtract
that solid from the fixture solids to determine if we're likely to run into 
anything.
 This is something that interests me but it's a bigger problem than I'm keen to take
on just at the moment.

Sorry for the verbal dump.  I was just eager to contribute an idea.

Ta
David Nicholls

Original comment by David.Ni...@gmail.com on 6 Jul 2009 at 3:21

[GoogleCodeExporter]

Sorry, one more thing.  Dan Heeks presented a preference whereby the order of
machining operations in the 'operations' list reflected the order of GCode
generation.  I implemented an 'execution order' integer to the Operations class 
(COp)
but Dan was eager to make this a more visual thing.  Perhaps we should expand 
the
presentation of 'child objects' of the drilling object in the same way as Jon 
has
recently done for child objects of sketches.  i.e. have the graphical objects 
that
the drilling cycle is based on be listed as child objects.  If we then 
implemented a
drag and drop concept for objects within the drilling cycle, it may go towards 
your
ordering idea.

Again, just more food for thought.

Original comment by David.Ni...@gmail.com on 6 Jul 2009 at 3:24

[GoogleCodeExporter]

I mistakenly added a similar issue to HeeksCAD.  Should be here.  Please refer 
to:
http://code.google.com/p/heekscad/issues/detail?id=179

Also these two screenshots:
This was produced by a script written by DanielFalck to extract center
points from circles in a dxf and output g81 movements.  I don't think the
script does anything fancy to calculate a path, it just uses the geometry
from the dxf file.  I've attached the script for reference.
http://img382.imageshack.us/img382/4367/screenshot023.png

This is the path produced by the the heekscad drilling cycle for the same
file:  http://img12.imageshack.us/img12/7770/screenshot024seh.png

Original comment by shopinth...@gmail.com on 6 Jul 2009 at 3:24

Attachments:

• dxf2holes2.py

[GoogleCodeExporter]

I am in the process of adding a 'Design Rules Adjustment' mechanism.  The idea 
is
that the NC objects make certain basic checks to see if any of the parameters 
don't
make sense.  eg: If a drilling cycle's depth is deeper than the tool's cutting 
edge
length.

The point is that it's not an 'operation' that is added to the model.  Rather, 
it's a
command that affects the values in the 'operation' objects.  Perhaps we could
implement a travelling salesman sorting feature as a manually invoked command.  
That
way, any ordering implemented by the user would not be overwritten unless they
explicitly asked for it.  Maybe on a right mouse-click menu when pointing to a
drilling object.

I do like the idea of sorting the cutting operations.  The next one would be 
sorting
profile operations that apply to multiple sketches.  Same scenario.  i.e. just 
to
minimize rapid movements.

Original comment by David.Ni...@gmail.com on 6 Jul 2009 at 3:31

[GoogleCodeExporter]

I can't see any sorting in the Python script.  Is there any chance you could 
attach
the DXF file to this issue so that we can compare outputs of any changes?  If 
you
can't, it doesn't matter.  I was just curious.

Original comment by David.Ni...@gmail.com on 6 Jul 2009 at 3:35

[GoogleCodeExporter]

It's the same file I was using for the 'select same many holes' bug. I attached 
the
.heeks file before.  Here's the dxf.

Original comment by shopinth...@gmail.com on 6 Jul 2009 at 3:42

Attachments:

• cribbageboardholes.dxf

[GoogleCodeExporter]

Hi David,
I wrote that script long ago and all it does is parse the holes as they come in 
the
dxf file.

Thanks,
Dan 

Original comment by ddfalck2...@yahoo.com on 6 Jul 2009 at 3:44

[GoogleCodeExporter]

I have added a 'sort drill locations' flag to the drilling object properties 
list. 
If this flag is true (default) then a very basic sorting algorithm is applied 
to the
coordinates list for that drilling object.  The sorting starts at position 
0,0,0 and
finds the next closest point to the previous point.

I know this isn't what this issue first identified but it should fix
http://code.google.com/p/heekscad/issues/detail?id=179

This change includes changing the prototype of the FindAllLocations() method 
from
std::set to std::vector so that a) the sorting can occur and b) so that the 
locations
are not arranged in x then y then z order (which was why the excess rapid 
travelling
was occuring).  If we get to the point where we allow the user to sort the 
reference
objects within a drilling cycle, the sorting flag will allow this ordering to 
remain
unchanged.

I decided against adding this sorting as a separate command because the drilling
object doesn't store the locations for holes directly.  Instead, it stores a 
list of
type/id pairs of other objects.  These objects are asked for their locations
differently, based on their type, at the time of both graphics generation and 
also at
GCode generation time.  We need to get these points at runtime so that, if one 
of the
reference object properties changes, the corresponding drilling object also 
changes.

I suggest we leave this issue open until we do the reference symbol 
re-arrangement
code.  I'm not putting my hand up for this as the GUI and menu stuff is not 
something
I'm good at.

Original comment by David.Ni...@gmail.com on 6 Jul 2009 at 10:03

[GoogleCodeExporter]

I also added the same type of sorting option to CounterBore and Profile 
operations
(because I'm such a fan of cut and paste)

Original comment by David.Ni...@gmail.com on 6 Jul 2009 at 12:53

[GoogleCodeExporter]

Hi all,
opencamlib r728 and newer includes a heuristic from the boost graph library for 
solving the travelling salesman problem (optimizing drilling order). It 
guarantees a tour not longer than twice the optimal tour.
There is only one example of how to use this for now:
http://code.google.com/p/opencamlib/source/browse/trunk/scripts/tsp_01.py

There are ofcourse other heuristics with better optimality guarantee or 
genetic/particle-swarm approaches to this also.

Original comment by anders.e...@gmail.com on 1 May 2011 at 11:00

[GoogleCodeExporter]

You just have to select the positions in the right order.

Original comment by danhe...@gmail.com on 24 Mar 2014 at 3:29

• Changed state: WontFix