Other entry methods for pocketing operations

[GoogleCodeExporter]

Currently the only way to engage the cutter into the material is by
directly plunging.  This doesn't work well for some cutters.

It would be a great enhancement to have a parameter of the operations which
controls how the cutter moves downward from the clearance height into the
material.  Specifically, it should be able to ramp the cutter downward as
it is moving forward to engage more gently.

Another option would be a helical descent. 

Original issue reported on code.google.com by shopinth...@gmail.com on 17 May 2010 at 12:52

[GoogleCodeExporter]

Let me start by saying that I agree with this suggestion.  Options for straight
plunge, ramping along the sketch edges and helical descent would be the three 
options
I would like to see.

Let me finish by suggesting a bit of a hack as a short-term workaround.

I added the ability for a profile operation to be used as a source of location 
for a
drilling cycle.  The idea being that the profile operation's starting point 
would be
used as the location to drill a hole.  Whenever the profile was subsequently
implemented it would plunge into the hole just drilled before moving sideways.  
It
was a half-way solution.

We could extend this half-way solution by adding a child counterbore operation 
to
profiles, pockets and/or contours.  The counterbore operation already does the
helical descent to form the hole.  The difficulty has always been knowing where 
to
put such a movement's starting point.  Ideally the software would select a 
location
with enough space around it to make a helical descent without cutting into 
'good'
material.  If we force the operator to manually define starting point (such as 
may be
done for a profile) then the software wouldn't have to make such a difficult
decision.  We would need to modify the glCommands() method for the profile, 
pocket
and contour so that, if one of these counterbore operations was implicitly 
added as
an entry mechanism, that counterbore's outline was included in the visual
representation.  This would make it easier for the operator to manually place 
the
starting point in a place that wouldn't remove 'good' material.

I don't want to detract from the original request as I agree that it's where we 
want
to end up.  This is just an idea for an easier solution that may serve as a
stepping-stone to get there.

Original comment by David.Ni...@gmail.com on 17 May 2010 at 11:53

[GoogleCodeExporter]

I think that defining the starting point above the pocket and the 
destination/start
point in the pocket might be a good way to do this. That way the person doing 
the
gcode programming would be aware that they are doing something that could 
potentially
clip an island in the pocket and they should watch for it.

Original comment by ddfalck2...@yahoo.com on 18 May 2010 at 2:07

[GoogleCodeExporter]

I agree completely with shopinthewoods.
The options should be
* straight plunge
* linear ramp
* helical descent
We need to do some work to not keep retracting and descending like we are doing 
now,
anyway. I will look into improving pocketing, as it is one of my favourite 
operations.

Original comment by danhe...@gmail.com on 24 May 2010 at 3:22

• Changed state: Accepted

[GoogleCodeExporter]

to encourage progress I added a property to Pocket

currently it only sets the descent_strategy variable in post.py before each 
area_funcs.pocket()  to 0 (plunge), 1(ramp) or 2(helical)

Original comment by haberl...@gmail.com on 6 Nov 2010 at 11:47

[GoogleCodeExporter]

It's not ideal but a work-around would be possible if the pocket operation 
allowed the user to specify the entry point manually.  (I could see the UI 
working like the profile operation where the user can specify the location for 
holding tags.)  

If the user could always know where the cutter is going to descend, we could 
hand code or add a scriptop at that point first to do a helical entry.

The workflow would be this:
User adds a pocket operation.
User picks a point away from boundaries and designates it as an entry point.
The pocket operation does what it normally does but only descends at any of the 
associated entry points.  If it can't reach an area from one of the points, it 
doesn't clear it.
The user adds a scriptop or modifies the gcode manually to create a ramp or 
helical entry at that point before the pocket operation code.

Like I said, not ideal, but maybe workable.

Original comment by shopinth...@gmail.com on 10 Apr 2011 at 2:07

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

no feature requests for HeeksCNC 1.0, just bug reports please.

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

• Changed state: WontFix