Clearence/Rapid/Feed Plane

So, it looks like you are using metric and we use Freedom units, so its hard for my brain to wrap around that. It looks like you are machining a feature down in a pocket or something. One thing it seems is that other users think that 2D needs to be magic, but its not. You have to give it all of the information. You could definelty use a 3D strategy that will do more thinking for you if you have a solid model.

In any case, I always set my clearance plane to .1" and my feed plane is pretty much all .1" as well. I never tend to adjust the feed plane as .1" is sufficient in almost all cases. It looks like you would like to have the tool come out of the feature and clear the actual top of part. What I do in this case is adjust the rapid plane. So if you have a top of feature -1" I would put 1.1" as my rapid plane. this will bring my tool out of the pocket and to my .1" clearance plane.

In your instance your clearance plane is 2mm, I would try and leave your feed plane at 2mm then make your rapid plane 46mm by adding the 44mm to 2mm. this should bring your tool out of the pocket to your global clearance plane. You can verify by the toolpath and see it wont be going through your part.

Separately if you are doing a drill cycle its good to check group retract, as I cant verify, but I believe it takes into account your stock. I tend to program everything from a face top of part, so i always go in and make this .1" to match my clearance plane. In your case 2mm. I would experiment with this in the air the first go around, but once you understand you will be rollin!

Hello @The_mtbiking_viking,
yes, for sure you can do calculation to get the travel g-code you like to have. But it is exactly the request to not always have to check over and over again.

Regards, Harald

But in order to do what you were asking, it would limit your control of the software. This upgrade would put many at a disadvantage. For instance if you had multiple pockets at a lower level but didn’t want to rapid to the z clearance plane every time. each box in the software you can do math in, so its pretty simple really. It always shows up in simulation as well. If you are not using machine compensation, why not use 3D toolpath. You could advanced rough to machine the pocket then flatlands to finish the floor. the 3D paths do basically what you are asking as long as you aren’t just working with wireframe.

Hi @The_mtbiking_viking,
you didn’t really read the posts, did you?

Why do you think we talked about absolute and relative or field lock possibilities?

Bye, Harald

1 Like

I read it, I’m not here to argue was just trying to help you understand a way to control it. I utilize this almost everyday with zero issues. a retract to clearance check box would be cool, but would be another thing to remember, where this is consistently the same with more control over the path. Like I said it shows up in the sim and if you are paying attention really easy to catch and correct.

Hello,

These are great requests. Thank you for the feedback.

I can understand why you would want it to error out if the Clearance Plane is smaller than the Rapid Plane. I will check to see if these has already been submitted to the Dev team. If not, I will do so. (Note: I will also add in an error for Top of Part versus RP)

As for using Absolute values instead of incremental for the Rapid and Feed Planes, I can put in a request for this as well. However, the software has always worked in that the Rapid and Feed planes are the incremental distance from the “Top of Feature” for 2x operations. (Note: In 3x Finish operations, the FP and RP are incremental from the surfaces of the model at any given point). If we were to implement Absolute values, we would have to think about every other toolpath as well and how they would work and make sense in those scenarios.

A lot of times, something that may seem like the perfect feature request in one scenario does not end up working well for all scenarios. This is the battle that the Dev team faces. What works best in all scenarios and makes the most sense across the board. That is not to say that they can not figure it out, but rather it is just to understand the perspective that the dev team has to come from. Something that seems like a simple and obvious feature request, may not be so when you dig deeper into what that means for the entire software and every scenario.

Looking at the Feature Request in a more broad sense and digging deeper into each scenario, rather than just thinking about one specific scenario. I hope that makes sense.

Like Alex said, this one can be solved by an understanding of how the software works. However, feedback like this is always welcome so that we can understand what your pain points are.

With that being said, I will submit a request to development about the Absolute values as well so that the Dev team can review and think on that further as I do agree, especially if you are a new user, you may not understand what these values are referencing.

Thank you all for the feedback!

1 Like