Clearence/Rapid/Feed Plane

[MillingGuy]

@avocamfg2006

In this case if there is higher material in between the geometry selected, you will crash into it, unless the RP has a value that will bring it back up above Z0

hmm… IMHO, the different kind of planes should avoid to get machines crashed. If they don’t, isn’t it a big issue to solve/correct. I cannot believe it is the goal to always have to check, if the machine runs in troubles. If it could, the software should either warn for that (at least when doing a post).

I know, it’s

@avocamfg2006

In this case if there is higher material in between the geometry selected, you will crash into it

this cannot actually happen if travel paths between different geometries are not run on RP level, but on CP level. This as default with an option that the user can overrule the system telling it should use RP level would already provide the necessary safety here. Or is that a step backwards, because then everything is done at CP level?

Perhaps BC can comment on this?

Bye, Harald

[avocamfg2006]

Unlike the Mill 3 Axis toolpaths, Mill 2 Axis toolpaths are non-intuitive, most of the time they will do exactly what is inputted. Of coarse we have the simulation to catch errors. But not all unwanted things are seen in the simulation. In the screen shot below I was able to have RP of -1.500" (shown). This you could miss seeing in the simulator since it is away from the stock.

So, as for improvements,

Use CP as default (especially when multiple geometry is selected)
A Check Box to optionally use CP
A Check Box to optionally have RP Absolute.

I think a Pop up warning should also be implemented when the Top of Feature is below top of part or stock according to what is set in the job or stock parameters, or if the RP goes below the cut depth. Since Mill 2 axis toolpaths cannot see/use stock or model geometry to detect errors, then is it possible to use the numbers that are inputted in the RP and FP boxes for some kind of warning of user mistake ? I think so.

Any thoughts on this topic ?

@TheWeave, @gmyers

Thanks,
David.

[MillingGuy]

@avocamfg2006

But not all unwanted things are seen in the simulation.

I completely agree. Especially when things have to happen quickly and/or a lot of fine tuning has to be done, it needs something like trust.

@avocamfg2006

Since Mill 2 axis toolpaths cannot see/use stock or model geometry to detect errors

Is it? I cannot believe. Just doing 2 axis operatione there there is a stock definition with all dimensions.
Understandable, that collision detection is sure not easy to handle. But that’s also what users rely on with cam software.

@avocamfg2006

Use CP as default (especially when multiple geometry is selected)

Already makes two with the same thought

Bye, Harald

[MillingGuy]

Hi,

ARRGHH…

did 4 trials to get the final version. The fourth one looks like this and should be go to the customer’s front panel:

Because there are already pockets, I thought to optimize the last operation not to mill in the air and set the Top of the Feature to -12.2mm. Voila: got this:

instead of

and destroyed the front plate the customer brought to me

Hey… BC-Team: this is no fun. It is in no way logical that I have to set RP to 17.2 here to get the actual 5mm!

So… now I’m curious how the customer reacts to the “aesthetically” corrected version

I appeal vigorously to fix this bug! See postings above. I am also a little disappointed that BC has not yet issued a statement on this topic.

Bye, Harald

[avocamfg2006]

Hi Harald,

Been there and done that !. As I am sure many have also. Sure would be good to hear what BC has in planning for this. Things like this shouldn’t happen and as we have discussed previously in this post, there should be a pop up warning that your RP is below the part top and options to use CP when multiple geometries are selected in one feature operation.

[Eric]

agree my fix for that is to have the feed plane 2.5mm above the total depth. that seems to take out the dog legs also I think the New controls on the Haas you can change a setting to take out dog legs have not used it we have both controls so I just see bad things happen

[MillingGuy]

@Eric: cannot follow the content of your last post

To me, CP and RP must always be handled from top of material. No matter which machine or control system is behind it. And a change in “Top of Feature” or whatever else must not result in a change in absolut CP or RP. Meaning e.g. CP = 10mm and RP = 5mm BobCAM always makes CP=10mm and RP=5mm regardless what changes will be done inside the operations.

Bye, Harald

[Alex_Cole]

I made a short video to help explain how the system uses Clearance Plane and Rapid Plane in 2 Axis and 3 Axis features. Hopefully this will help you understand why you are getting what you are getting in your part. It is not a bug, but rather a misunderstanding of how these values are intended to be used.

HTH

Alex

[MillingGuy]

Hello Alex,

thanks for the video. yeah… V34

All understood. It was before.

By “bug” I did not mean to eliminate an error from the system, but the elimination of pre-programmed operating errors. Not rarely it comes to pick a “Top of Feature” below 0.00. But also oftne it comes to

1. to a crash, if one forget to correct the RP value (as shown in your video going through the workpiece between upper and lower pockets).

or

2. you do group all pockets of different depth and must therefore calculate each RP to get the same (optimized) height or be at least above a crashing route.

It would not come to such problems if:
BobCAM handles the RP as absolute value from Top of Stock and does not change it on its own. If the user wants to, he should explicit change the value hopefully knowing he had done so
At least a warning should be thrown, if “Top of Feature” is changed, that this affects the RP. But still has the risk to simply click away the message and drive a crash.

Perhaps a field lock would also help, preventing a value change. Neither BobCAM nor the user can change the value when the field lock is active (default). But it is the user who can remove/set this lock.

Automation is beautiful and great. Unfortunately, when it results in automatic errors, it’s not.

Bye, Harald

[Papa2020]

It sure would be nice if these values could be toggled between absolute and incremental. Would cut out a lot of confusion and add value to this software.

[MillingGuy]

Hi,

long ago …
Because I still keep running into problems or need time to resolve conflicts with CP, RP and FP: will there be anything new?

Bye, Harald

[avocamfg2006]

I hope so.
I run into issues with this too, especially when doing a copy and paste, and the geometries picked are below top of part and you forget to add the necessary height to RP to clear the in between geometry.

@Papa2020

It sure would be nice if these values could be toggled between absolute and incremental. Would cut out a lot of confusion and add value to this software.

I think it should be an easy thing to take care of.

@avocamfg2006

I think a Pop up warning should also be implemented when the Top of Feature is below top of part or stock according to what is set in the job or stock parameters, or if the RP goes below the cut depth. Since Mill 2 axis toolpaths cannot see/use stock or model geometry to detect errors, then is it possible to use the numbers that are inputted in the RP and FP boxes for some kind of warning of user mistake ? I think so.

Hopefully it will be addressed in V35. Although, the only BC input into this topic has been @Alex video.

[MillingGuy]

Hi,
sadly, no enhancement is given in V35/BC4RH_V3. Maybe in V36/BC4RH_V4?
What’s BC-Team saying about?
Bye, Harald

[avocamfg2006]

Yes, it sure would be good to have this taken care of. Not sure why BC don’t see the need for it.

David.

[The_mtbiking_viking]

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!

[MillingGuy]

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

[The_mtbiking_viking]

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.

[MillingGuy]

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

[The_mtbiking_viking]

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.

[TheWeave]

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!