Avoiding a fixture

[gking86]

We have an Onsrud router that has been crashed multiple times (by others, not me) due to a large post that is permanently on the table. It's also a policy of the company to fire anyone who crashes it after being warned. We run many different parts on it, but the post is always the XYZ origin. I typically just add clearance in the bulk toolpath editor so that rapid moves are always clear of it and appropriate containment or check surfaces to prevent tools from feeding into it.

I'd like to semi-permanently prevent crashes from hitting the center post. The OSAI controller has code you can insert in your program to define protected areas. I made a copy of the post file and made those changes and it's working. However, it's a pain to make Mastercamnot want to rapid across that area when going from one side of the part to others. So here are my questions:

1. Is it possible to modify a setting in Mastercam or the post so that rapid moves happen in Z, then Y, then X instead of Z then XY?

2. Is it possible to modify the post to just always home out Z or go to a specified Z level every time an M00 gets passed to it?

3. Is there any other setting in Mastercam that you can define a permanent no-go area on either the machine or control definition?

[gcode]

yes to 1 and 2

as for #3 It may be possible to define a no fly zone via the machine's parameters, but you would have to consult the builder for that

 

 

[gking86]

2 minutes ago, gcode said:

yes to 1 and 2

as for #3 It may be possible to define a no fly zone via the machine's parameters, but you would have to consult the builder for that 

My google-fu is failing, have a rough idea where to point me?

 

Edit: 3, I did define a no-fly zone on the machine, but it only looks at XY coordinates. The parts are always symmetrical, so if I do a contour on one end, the next op is always the same on the other end, which makes the rapid go nearly directly through the center, so my no-fly zone is triggered on nearly every program. If I could modify the rapid behavior before the post or in the post the no-fly zone would still prevent accidental entry, and programming could be completed "normally" without too much load on the programmers.

[gcode]

Look on the Rapids page of the control definition

older posts do not respect these settings because the post was written before the control def even existing

a modern post may or may not respect these settings depending on who wrote it.

It is easy to obtain a post that will do what you need here, but it will cost $$

It won't cost as much as a hard crash.. but selling management on buying a new post can be very difficult

 

[huskermcdoogle]

If it were me, I would add some logic to the rapid section of the post assuming it is not binned.  Basically if the rapid move distance in xy is greater than ## amount, then break rapid motion into x then y, depending on the post there already should be some logic built into it that is like this, but for breaking up z then xy and whatnot.  Before you make any edits to the post, backup your post, back it up again, then look at the logic of those cases and see if you can follow the syntax to add your own case.  If you have trouble with that or feel it is over your head.  I would imagine your reseller would be happy to help, and probably for free if you are current on maintenance.  At the end of the day, if your post is based on a generic post, the tweak is about a 10 minute job.  You will spend more time talking about it than actually doing it and testing it.

[sir Camalot]

If the post method isn't a current option, could you just create some surfaces around the post and then select those surfaces as check surfaces with an additional value and just avoid that area altogether? (Similar to how one might avoid fixtures or clamps? ) Then create template file that you can use every time you start a job so that is already setup and populated.

[Leon82]

You can break up rapid moves in prapidout

Copy the line and remove pxout from one and pyout from the other. A third one can be z first obviously.