Path.Area: Welcome, to the new era!

[realthunder]

I'm still having some confusion related to startpoint in fromShapes()

The 'start' is for indicating the initial resting position of the tool, not as an instruction to move to that position. I made it this way because, without knowing the resting position, it is dangerous to to blindly move the tool to some point. So the assumption here is that the user defines the resting position, and must make sure the tool is safe to move from that position to the first section.

BTW, maybe you can answer what herbk asked in his post above, since you are the person in charge of that part.

[sliptonic]

Hi,
in some of sliptonic pics i saw that the pocket opeation works with spherical pockets to.
But it seams, that it works only with a sperical shape of the pocket. I try'd some other shapes to, but i got no, or only partial pathes.
Is that the current state or do i make i mistake?

It's not very thoroughly tested by it should work. My test file is attached and I get valid paths for a variety of shapes.

oddpockets.fcstd

(203.35 KiB) Downloaded 75 times

[chrisb]

Why do you have all these rapid moves?

[sliptonic]

Why do you have all these rapid moves?

I this case, the pocket has been calculated for the whole shape. In other words, that's not seven individual pockets but one pocket with seven low points. So each step down is done at each location.

It's possible to do individual pocket operations for each of the locations (although selection gets tricky) and then each would be processed completely before moving to the next.

[chrisb]

I understand, although I still wonder, why some of the pockets (middle, right and back) have so many more vertical rapids than the other pockets. I will counter check with a model of mine where I had a similar setup and path creation was perfect. No wonder: I had only a depth of one step.

[sliptonic]

I understand, although I still wonder, why some of the pockets (middle, right and back) have so many more vertical rapids than the other pockets. I will counter check with a model of mine where I had a similar setup and path creation was perfect. No wonder: I had only a depth of one step.

It's showing rapids into and out of the holes. The ones that have curved bottoms have more different locations where the cutter starts and ends. The flat bottom holes have the same number of rapids in and out (if they're the same depth) but the paths overlap so you don't see them.

[chrisb]

I finally downloaded the model and everything is clear now. From the image it was not clear to me that all these pockets are very different in depth and structure. Sorry for buzzing.

[sliptonic]

I'm still having some confusion related to startpoint in fromShapes()

The 'start' is for indicating the initial resting position of the tool, not as an instruction to move to that position. I made it this way because, without knowing the resting position, it is dangerous to to blindly move the tool to some point. So the assumption here is that the user defines the resting position, and must make sure the tool is safe to move from that position to the first section.

The problem I'm having is that the first move you generate is a Rapid to the beginning of your path. I can move the cutter to a safe starting location, but entering into the material has be to be done at feed rate. Since I don't know exactly where your path will begin, I can't calculate a safe entry path.

Right now we're talking about the issue in a thread on MillFace operation but it will really be an issue as we add dressups to create custom entry methods.

[realthunder]

The problem I'm having is that the first move you generate is a Rapid to the beginning of your path.

That is a problem indeed. And I've fixed it in my branch. The first move now honors the 'resume_height' parameter, which specifies the relative height above the next section to resume G1 move. Please check.

[bill]

I am more concerned with the through features that dont go through!
What caused it to stop there?

notthru.png (26.18 KiB) Viewed 2272 times