Undesirable Plunge

[GoogleCodeExporter]

I am slowly picking up on the pattern that this issue is exhibiting, so please 
pardon the lack of specific examples and details.

On a number of models the generated tool path appears to inadvertently direct 
the mill to plunge into the piece where it should not otherwise.

In the following example (http://imageshack.us/photo/my-images/21/fa66.jpg/) 
you can see the highlighted red line, which overshadows a green line, sitting 
directly adjacent to the model. Per the pocket properties the toolpath was 
generated for a 9mm end mill, 6mm stepover, and 4mm step down. In the code 
output you can see the command to drive the end mill down to Z-23, whereas the 
lowest point in the model is no more than Z-21('ish).

Not visible in the image is the pocket property 'final depth'. This is set to 
-30. I would imagine that if I set this to -21 then I would circumvent the 
'random' plunges. However, I am able to save time by issuing a depth that more 
than covers the models features.

It is unclear at this time when and why the 'plunge' commands are issued, but 
are usually not discovered until the coding is put through its testing with the 
actual mill. It seems at this moment that a 'plunge' command may be issued 
before a new g-code is given... but, I would like to see what advice others may 
have.

Original issue reported on code.google.com by nathanie...@gmail.com on 6 Sep 2013 at 12:38

[GoogleCodeExporter]

An additional property that is exhibited by this "defect" is repetition of 
commands.
For example, let's say I have a model with the deepest cut at Z-10, my 'Step 
Down' at 5, and the 'Final Depth' at -30. The code will be generated something 
as follows:

(Pass 1)
Z-5 lowest cut

(Pass 2)
Z-10 lowest cut

(Pass 3)
Z-10 lowest cut
'Defect' plunge to Z-15

(Pass 4)
Z-10 lowest cut
'Defect plunge to Z-20

...etc.

Within Pass 3, Pass 4, etc. we will have the same exact commands as Pass 2, 
with the exception of the final command that plunges the end mill. As a result, 
not only are we getting undesired plunges, but our cut time has now increased 
(in the example, three times as much) because of the redundant passes. 

Original comment by Comlogi...@gmail.com on 16 Oct 2013 at 8:40

[GoogleCodeExporter]

I've confirmed that this is still present in v1.0. (I experienced this in 
previous versions as described in the original report.)

During each step-down there's a G00 move to the start location for the pocket, 
followed by a G00 plunge to the rapid safety space above the depth of the 
previous pass, and then a G01 Z move to the correct depth of cut height for the 
pass that's starting.

G00 plunge to the rapid safety space above the depth of the previous pass: This 
move should be to the rapid safety space above the surface-adjusted start 
height for the pass that's starting. In a normal pocket, the start height is 
the depth of the previous pass, but not when a surface is involved.

G01 Z move to the correct depth of cut height for the pass that's starting: 
This move is executing correctly, moving to the depth of cut for the pass or 
the height of the surface at that point, whichever is higher.

Original comment by mike.mer...@gmail.com on 9 May 2014 at 9:33

[GoogleCodeExporter]

recreator.Redirector's implementation of rapid does not call z2 to determine 
whether or not the movement's z value collides with the shape (in the context 
of attach.Creator). Adding this in fixes the gross issue by limiting the z 
height, but does not support the rapid safety space (it is not known in that 
context).

Original comment by mike.mer...@gmail.com on 10 May 2014 at 2:03

[GoogleCodeExporter]

Changing recreator.Redirector's rapid method to something like this is working 
for me:

{{{
def rapid(self, x=None, y=None, z=None, a=None, b=None, c=None):
        px = self.x
        py = self.y
        pz = self.z          
        self.cut_path()     
        if x != None: self.x = x * units
        if y != None: self.y = y * units
        if z != None: self.z = z * units

        if (self.x != None and self.y != None and self.z != None) and (px == self.x and py == self.y):
            # z move only 
            nz = self.z2(self.z)/units
            if nz > z:
                # add an arbitrary safety space above the z limit
                nz = nz + (1 / units)
            self.original.rapid(self.x/units, self.y/units, nz, a, b, c)
            return

        self.original.rapid(x, y, z, a, b, c)
}}}

Original comment by mike.mer...@gmail.com on 12 May 2014 at 6:14

[GoogleCodeExporter]

Mike, sorry I'm having trouble repeating this. Any chance you could attach ( or 
email me danheeks@gmail.com ) a heeks file with the problem.
Dan. Dan Heeks.

Original comment by danhe...@gmail.com on 12 May 2014 at 6:44

[GoogleCodeExporter]

I emailed the example file yesterday (the issue attachment storage quota has 
been exceeded).

The issue won't be apparent unless the corner of the sketch where the tool path 
begins is over a relatively high point on the surface. e.g. when cutting a 
pocket in the middle of a block. The image linked by the OP shows the rapid 
plunge at the start point where (judging from the toolpaths) the framing sketch 
falls within the margins of the surface.

Original comment by mike.mer...@gmail.com on 13 May 2014 at 5:29

[GoogleCodeExporter]

Hi Mike, I'm having this problem. Would you mind sharing your fixed file that 
is working? Thanks so much.

Original comment by takeo.ka...@gmail.com on 2 Jan 2015 at 1:13

[GoogleCodeExporter]

Original comment by neomil...@gmail.com on 15 Jan 2015 at 8:51

• Added labels: Priority-High
• Removed labels: Priority-Medium