search

prdatur / heekscnc

Automatically exported from code.google.com/p/heekscnc
Other
0 stars 0 forks source link

CounterBore function for Socket Head Cap Screws #105

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
I have been playing with the idea of using the Drilling object as a source
of location and size for generating a series of circular pockets.  The idea
comes from a Python utility written by John Thornton
(http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Simple_EMC_G-Code_Generators)

John's utility can generate the GCode to machine circular pockets to cater
for the heads of Socket Head Cap Screws (SHCS).  I wasn't thinking of
reproducing his method here.  Instead, I was thinking of using the drilling
object as a reference (since it is, in turn, a reference to other graphical
objects - including intersections). With the drilling object, we can get
both position and hole diameter.  From the hole diameter we could derive
the size of the cap screw's head.  With this information we could use
either the circular pocketing functionality or the adaptive roughing
functionality to remove the material for the screw's head.

I was wondering if anyone else thought this was a good idea or have I
really gone off the deep end with all this stuff.

I have started the coding.  I have created a new Operation class called
CounterBore that works suspiciously like the Drilling operation class.  The
only enhancement is that, in addition to selecting points, intersecting
objects and standalone circles, the CounterBore object can make reference
to Drilling objects.  It works to the point of drawing the graphics for the
cylinder surrounding the top of the Drilling object's location.

Now I need to learn about Sketches and/or adaptive clearing.  I really like
the idea of the adaptive clearing algorithm but I know very little about
it.  I like the idea of plunging the milling bit in the hole already
drilled and then slowly milling out to create the pocket.

I have attached a screenshot of what it looks like so far.

I am just interested in getting some feeback as to whether this is too
specific a tool for HeeksCNC.  All this could be done with existing
pocketing functionality.  It's really just to pull it all together into one
utility.  It also means that the original points and/or intersections the
drilling holes were based on, also determine where the circular pockets
will be put.  i.e. one could move the points to another location and
re-generate the GCode and the holes and pockets would all move with them. 
This idea appeals to me.

Thanks
David Nicholls

Original issue reported on code.google.com by David.Ni...@gmail.com on 16 Jun 2009 at 10:35

Attachments:

GoogleCodeExporter commented 8 years ago 
David,
This sounds like a good idea to me.
The existing pocketing functionality doesn't do a perfect job of circular 
pockets,
anyway, so having a specific circular pocket operation done in the same way as
drilling would be great. The code to calculate the moves could be mostly in a 
python
file.

P.S.
In your picture, why are some of the icons in the tree view so big?
In Drilling.h
    wxString GetIcon(){if(m_active)return theApp.GetResFolder() + _T("/icons/drilling");
else return COp::GetIcon();}
refers to icons/drilling.
All the .png files in the icons directory are small ( 16x16 ). Maybe you have 
copied
some of the big .png files ( 96x96 ) from the "bitmaps" directory, which is 
intended
for toolbar pictures, which are resizeable.

Original comment by danhe...@gmail.com on 16 Jun 2009 at 11:22

GoogleCodeExporter commented 8 years ago 
Hi David
Sounds good and this will be another highlight in HeeksCAD/CNC ...
Specifically as a separate function... I like this Idea 

Thx for your Work !

Hans

Original comment by aachen.h...@googlemail.com on 16 Jun 2009 at 11:56

GoogleCodeExporter commented 8 years ago 
Dan,

  thanks for that.  I did, indeed, copy the files from the bitmaps directory.  I've
cleaned it up and it's much better now.

  As for the pocketing work.  Are you suggesting that I do generate the pocketing
code without using the existing pocketing function?  Or are you suggesting I 
learn
about the Adaptive clearing code.  I had considered having the operator select a
'solid' object as well and then using the cylinder of the screw's head (which we
already have) as the boundary for the Adaptive clearing code.

  From my reading of John Thornton's code, he does a spiralling cut to produce the
pockets.  The only advantage to the Adaptive clearing code here is that it 
would know
what shape the existing solid is so that it wouldn't waste time cutting 
something
that's not there.

  From yours and Hans feedback, I am tempted to checkin the code changes I've made so
far.  They're not complete but they do complile and the won't break anything 
else as
long as the CounterBore objects are not included in the model.

  Thanks
  David Nicholls

Original comment by David.Ni...@gmail.com on 16 Jun 2009 at 12:33

GoogleCodeExporter commented 8 years ago 
Yes; for counter-bore operations, generate the pocketing code without using the
existing pocketing function. The algorithm for producing your arc moves ( and 
spiral
moves if required ) will be relatively simple, like feed down, feed across, do 
a 180
degree arc, do another 180 degree arc, feed across a bit more, ... in a loop.
Or for spiralling, use a different algorithm, but don't bother trying to copy 
the
Pocket operation's code because for arcs it has to convert them to little lines 
to do
the offsetting before fitting arcs back to the result.
Maybe your operation could write "import circle_pocket" at the top of the python
script, and then "circle_pocket(5, 10, etc.. " to the python script for the
operation, and this circle_pocket could be coded in a new file 
"circle_pocket.py"

Yes; checkin any modifications that don't break anything, as often as possible, 
to
reduce the number of conflicting changes you have to work with.

Original comment by danhe...@gmail.com on 16 Jun 2009 at 12:57

GoogleCodeExporter commented 8 years ago 
I must apologise for leaving the code in a mess again last night (second night 
in a
row).  I really thought I added the CounterBore.h(cpp) files but my subversion 
skills
are obviously poor.

In any case I have just added them again and now they appear in the source tree
browser so I believe it has worked now.

I have also added a shell of a program called circular_pocket.py.  I have 
actually
finished the real one but it's an adaptation (read almost straight take off) of 
the
counterbore.py file found on the EMC web pages.  I am trying to contact the 
author to
ask permission to redistribute the modified version but the email address listed
bounces back.  It has GPL mentioned in the file but HeeksCAD uses the 'New BSD
license' and I don't know if one is allowed to fit within the other.  In any 
case I
have asked the question on the EMC email forum so see if anyone knows how to 
contact
John Thornton.

I believe it all works.  It certainly generates GCode.  When I load that GCode 
into
EMC2 it produces lines a spirals that look about what I was expecting. 
Unfortunately, I'm still building my CNC machine so I can't actually test it.

I also added an 'M2' (end program) to the GCode generation routine in 
Program.cpp. 
Without this, EMC2 growls at me telling me it should be there.

Original comment by David.Ni...@gmail.com on 17 Jun 2009 at 10:34

GoogleCodeExporter commented 8 years ago 
This is the real copy of circular_pocket.py.  I'm happy to put it here as it's
covered by GPL but I don't want to check it in yet as I want to be sure it's 
legal to
do so.  In any case, if you want to give it a run then you can.  I've added a 
shell
of a program so that all the infrastructure is in place.  The shell of the 
routine
simply adds comments.

Original comment by David.Ni...@gmail.com on 17 Jun 2009 at 10:37

Attachments:

GoogleCodeExporter commented 8 years ago 
I just received the email from John Thornton giving permission to add the file 
to
HeeksCNC.  To this end I've just checked it in.  I believe this function now 
works. 
I imagine I'm going to have to think through some of the default settings but it
should be mostly alright.

Original comment by David.Ni...@gmail.com on 17 Jun 2009 at 11:07

GoogleCodeExporter commented 8 years ago 
You are right, we must not put any GPL code in HeeksCNC google code project 
without
permission to release it as "New BSD".
But, as you have permission, it's OK. However you should change the license 
header in
our file to say "New BSD", this includes removing "you must donate $20 USD to a 
local
food bank" :)

This file is purely for ISO NC code.
To make it flexible it should call code like this ( see HeeksCNC/kurve_funcs.py 
)
                    arc_ccw(sx, sy, i = rcx, j = rcy)
                elif rdir == -1:# clockwise arc
                    arc_cw(sx, sy, i = rcx, j = rcy)
                else:# line
                    feed(sx, sy)

I think these files ( area_funcs.py, kurve_funcs.py and circular_pocket.py ) 
should
all be in the same folder.

Original comment by danhe...@gmail.com on 17 Jun 2009 at 11:53

GoogleCodeExporter commented 8 years ago

Original comment by David.Ni...@gmail.com on 19 Jun 2009 at 11:09