Machining entry moves

[GoogleCodeExporter]

I was interested in continuing the discussion about entry moves (plunge, ramp 
or helical) when feeding the cutter deeper into the material.  I know that Dan 
Falck and ShopIntheWoods have discussed this within Issue 201 but I didn't want 
to deflect the purpose of Dan's original enhancement for Issue 201.

I have been playing with the ability to ramp the tool down in a contour 
operation.  The profile and contour operations have the great property that the 
sketch defines where the tool will go.  i.e. the operator does not need to 
manually identify the location for a helical entry move so as to ensure the 
entry move does not gouge 'good' material.

I haven't made it work yet but I believe I will be able to.

The process is to rapid to the starting X,Y coordinate, rapid to the 'rapid 
down to' height, feed to the 'start depth' (presumably zero) and then follow 
the sketch boundary at the cutting tool's defined gradient until the 'step 
down' height is achieved.  The tool can then back-track along the sketch's 
edges to the original X,Y starting point.  From there it simply runs around the 
sketch at that depth.

When the cut is complete at that depth, it does not retract.  Instead, it looks 
to see if the next X,Y starting point (ignoring Z) is at this same location.  
If not, it rapids to clearance height and moves above the next starting point.  
Normally, however, it is in the correct location to start the next cut at the 
next step-down depth.  The cycle continues as above until all step-down depths 
have been machined.

After looking at ShopInTheWood's blog, it occured to me we could do a similar 
thing in the area_funcs.py file for the pocket operation.  As Dan Falck said 
(at least mentioned in the blog), the 'cut_area()' routine is where both the 
plunging and the main cutting occurs.  If we change the loop so that the tool's 
gradient is also passed in, we could iterate through the vertices in each curve 
stepping down at the gradient until the appropriate depth is reached.  We could 
then just machine around these vertices at this depth.  i.e. the tool path 
defined by the pocket operation would determine where the tool ramped down.  
This would avoid the operator having to manually define where a helical entry 
move should start.

Does this make sense?  It would probably make more sense with a picture.  
Perhaps I could post a picture of the ONE scenario that works with my contour 
ramping code.  I will see if I can get it running again and post a picture of 
what I mean.

Original issue reported on code.google.com by David.Ni...@gmail.com on 23 Jun 2010 at 10:57

[GoogleCodeExporter]

Here is the only example that works at the moment.  As soon as the gradient 
forces the entry move to include the second and subsequent edges, it runs 
around the arcs the wrong way around and creates some really pretty patterns.

It has occured to me that I should ramp down at the tool's gradient forwards 
for half the step-down depth before backing up.  At the moment I'm going 
forwards at the tool's gradient until the full cutting depth is achieved before 
backing up to the starting point.  One step at a time (pardon the pun)

Original comment by David.Ni...@gmail.com on 23 Jun 2010 at 11:06

Attachments:

• [Contour Ramp Entry Example.png](https://storage.googleapis.com/google-code-attachments/heekscnc/issue-226/comment-1/Contour Ramp Entry Example.png)

[GoogleCodeExporter]

Hi David,
You might want to concentrate on ramping for pocketing. Typically you do 
pocketing first and then contouring/profiling. Once the material is removed 
with pocketing, it's easy to do the standard lead in/lead out that is already 
built into kurve. 
Thanks,
Dan

Original comment by ddfalck2...@yahoo.com on 24 Jun 2010 at 2:22

[GoogleCodeExporter]

With any great luck, that advice is too late.  I am hopeful of getting the 
ramping working with Contour operations very soon.  I thought I had cracked it 
last night but then I came across another scenario that didn't work.

I suspect, from what I've done with contours, that a similar process would work 
for pocketing.  The benefit being that the user would not need to manually 
specify entry move locations for each sketch.

Original comment by David.Ni...@gmail.com on 24 Jun 2010 at 10:34

[GoogleCodeExporter]

I think I've cracked it.  A few more tests and I will commit it.  Have a look 
at the toolpaths.

Original comment by David.Ni...@gmail.com on 27 Jun 2010 at 12:59

Attachments:

• a.heeks

[GoogleCodeExporter]

It looks pretty interesting. You even have nice helical ramping on the arcs. 
Looks great.

Original comment by ddfalck2...@yahoo.com on 27 Jun 2010 at 3:47

[GoogleCodeExporter]

Any luck with this?  I'm happy to help with testing if needed.

Original comment by shopinth...@gmail.com on 7 Jul 2010 at 2:33

[GoogleCodeExporter]

I thought I had done it.  Just one more test showed that I had not.  I think 
it's close.  I was tempted to commit the changes as, when the user selects the 
'plunge' entry move, it works just as well as it does today.  It's only when 
they select 'ramp' that it sometimes makes a mess.  My current problems relate 
to where the ramping movement needs to double back on itself after hitting an 
'open end'.

I haven't done anything on it for a couple of weeks now.  There have been some 
family things going on that have taken my time.  It may still be a week or two 
before I get there.

Original comment by David.Ni...@gmail.com on 7 Jul 2010 at 11:46

[GoogleCodeExporter]

Brad,
  have a look at what I've committed.  As I said in the comment, there is still an error when the sketch is 'open' but it's pretty obvious.  If the sketch is closed then it works alright.  I decided to commit it anyway as it's no worse than the existing code.  If the toolpath is poor, just select a 'plunge' entry type and it works just as well as it did before this commit.

  I will continue to look for this error but there is some common logic between this and some work I plan on doing for the ScriptOp.  i.e. we convert sketches into TopoDS_Edge objects and then we need to arrange them into connected sequences of edges.  I was thinking of rewriting the code that aggregates the edges into a dedicated routine and then processing each series of connected edges in order.  This may alleviate the problems I'm seeing in this contour ramping code.

  Anyway, I'll get there in the end.

  Ta
  David

Original comment by David.Ni...@gmail.com on 8 Jul 2010 at 11:46

[GoogleCodeExporter]

Brad,
  can you see how you go with this now?

  Thanks
  David

Original comment by David.Ni...@gmail.com on 12 Jul 2010 at 10:46

[GoogleCodeExporter]

I haven't done a lot of experimenting yet, but so far it seems to be handling 
everything pretty well.  I'll try to throw some tougher cases at it.

Ramp entry to the pocket operation is the one I'm really hungry for.  This 
project, http://sliptonic.com/?p=260,  is kind of stalled for me right now 
because I can't figure out how to do it without a more efficient pocket op.

Could you implement the material allowance for the contour operation?  I 
thought I might be able to add multiple contour operations and set each one 
with a greater 'material allowance'. It's a hack but might get me there.

Original comment by shopinth...@gmail.com on 14 Jul 2010 at 12:37

[GoogleCodeExporter]

I think the same logic could be used for the pocketing operation.  i.e. that 
the tool's path follows the lines/arcs that are defined for the pocket 
descending by the tool's gradient until the cutting depth is reached.  Once at 
depth, it follows the lines/arcs to make the full depth cut all the way around.

The other trick we need, however, is to recognize that once we are at full 
cutting depth, we don't need to raise up again before moving onto the next set 
of lines/arcs.  This is more difficult than it sounds because the next set of 
lines/arcs may be for another area.  I suspect we will need to look at the 
distances between the tool's finishing point and the start of the next 
lines/arc set and compare these with the diameter of the tool.

I like the idea of doing this but I have a few functions I need to finish 
properly before I go onto this.  I still want to get the Inlay function working 
properly this year.  I also promised to add graphics definitions into the 
ScriptOp object.  I really need to retire from full-time work to do the stuff 
that's interesting instead.  Unfortunately, I am niether rich enough no old 
enough to do this.

I also like the idea of adding a material allowance to the contour operation 
but, again, I won't get to it for a while.  I will create another Issue 
specifically for this so that it's not lost within this Issue's functionality.

Original comment by David.Ni...@gmail.com on 14 Jul 2010 at 2:57

[GoogleCodeExporter]

I'm hitting something that looks like a bug.  I don't seem to be able to change 
the tool on the contour operation. Changing to a tool with a different diameter 
and hitting post-process makes HeeksCAD lock up and never return.  This is 
happening all the time in the project file I'm using, but I haven't tried to 
replicate it with a simple case yet.

Original comment by shopinth...@gmail.com on 14 Jul 2010 at 6:46

[GoogleCodeExporter]

I can't reproduce the fault on a new file.  Can you attach the file you have so 
I can see what's going on?

Original comment by David.Ni...@gmail.com on 14 Jul 2010 at 11:35

[GoogleCodeExporter]

no feature requests here, just bug reports for HeeksCNC 1.0

Original comment by danhe...@gmail.com on 24 Mar 2014 at 5:07

• Changed state: WontFix