Pocket operation on Sketch: Step down attribute ignored if attachOp used.

[GoogleCodeExporter]

What steps will reproduce the problem?
- Test with attached .heeks file, turning AttachOp on/off.

What is the expected output? What do you see instead?
- Regardless of AttachOp I was expecting the pocket operation to honor it's 
maximum step-down so as not to try milling with a non-active part of the tool, 
or overloading tool.
- With AttachOp active, step down is ignored and tool is plunged all the way 
down to AttachOp's minimum z limit.

What version of the product are you using? On what operating system?
Windows 7, x64 and HeeksCNC 0.17.1 but same behavious apparantly also present 
in Linux on 0.17.0.

Please provide any additional information below.
- Bug or feature?

Original issue reported on code.google.com by tha_krea...@hotmail.com on 14 Feb 2011 at 9:28

Attachments:

• pocket_scetch_attachop-inactive.png
• pocket_scetch_attachop-active.png
• pocket_sphere.heeks

[GoogleCodeExporter]

To be able to test this you have to work around another bug (issue 282) by 
loading the file twice. You will notice the stored toolpath in the file looking 
better on windows after second load. The bugs are unrelated however, and I 
believe this simply misses the checking when the AttachOp is present as it uses 
it's z limit instead, forgetting that it's step down may be of just as much 
importance.

Original comment by tha_krea...@hotmail.com on 14 Feb 2011 at 10:07

[GoogleCodeExporter]

I dug around in the code and found that this is all done in .py so I didn't 
have to rebuild anything. I modified attach.py with this:

**********
    def cut_path(self):
        if self.path == None: return
        self.setPdcfIfNotSet()

+        if (self.z>self.minz):
+            self.pdcf.setZ(self.z)  # Adjust Z if we have gotten a higher 
limit (Fix pocketing loosing steps when using attach?)
+        else:
+            self.pdcf.setZ(self.minz) # Else use minz

        # get the points on the surface
        self.pdcf.setPath(self.path)
**********

It's probably not the right place, and possibly not ideal, but it does result 
in my attached image, based on new attached file. (Old had error due to me 
misunderstanding the "rapid down to height" parameter.)

Original comment by tha_krea...@hotmail.com on 17 Feb 2011 at 12:17

Attachments:

• pocket_sphere-debug.heeks
• pocket_scetch_attachop-pyfix.png

[GoogleCodeExporter]

hi, on IRC you asked about removing the "identical paths" from the toolpaths of 
each z-layer. I don't know how to do this with AttachOp, or if that is the best 
way.
My approach would be:
Run a waterline operation at each z-level. Together with the stock boundary 
this waterline defines a pocket to be cleared at each z-height.
When all z-layers are pocketed you could then run a semi-finish or finish 
operation which closely follows the design surface (AttachOp or 'zigzag' or 
similar).

I would call repeated use of the combination of waterline+stock-outline -> 
pocket/clearing algorithm something like "z-terrace roughing" or similar. It's 
very confusing when there aren't standard names for these things...

Original comment by anders.e...@gmail.com on 17 Feb 2011 at 9:43

[GoogleCodeExporter]

tha_krea...@hotmail.com, I like this change. I have committed the change to SVN.
Regarding '"identical paths" from the toolpaths of each z-layer', I guess what 
we need is a method "self.pdcf.SetMaxZ(z)", so that machining above a certain Z 
can be omitted.
Does this sound like a good idea?

Original comment by danhe...@gmail.com on 17 Feb 2011 at 10:02

[GoogleCodeExporter]

The reason for the use of pocket was simply that waterline bases the x spacing 
on angle of surface, while pocket varies y based on same.
Also, waterline when run from HeeksCNC leaks horribly, and is basically useless 
for now. (0.17.0)
As for the z max I think that would work well as long as the paths can be 
handled right. That is, areas must not be missed and ideally the islands 
created should be milled seperately so as not to pass over the already cleared 
areas in normal zigzag (taking almost same time as following the path in any 
case).

Original comment by tha_krea...@hotmail.com on 17 Feb 2011 at 11:20

[GoogleCodeExporter]

OK, so SetMaxZ is not very useful. I think Anders's idea is the only way to do 
this, calculating separate areas to pocket, but it can not be part of Attach 
operation.

Original comment by danhe...@gmail.com on 17 Feb 2011 at 11:32

• Changed state: Fixed

[GoogleCodeExporter]

Although not super speedy, it does work now so it is finally usefull for me 
atleast.
That said, zigzag and waterline is essentially the same operation in my book.  
Just in different axis.

Original comment by tha_krea...@hotmail.com on 17 Feb 2011 at 1:20