gking86
-
Posts
4 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
eMastercam Wiki
Blogs
Gallery
Events
Posts posted by 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?
-
On 7/8/2019 at 3:33 PM, Matthew Hajicek™ - Conventus said:
Maybe Mastercam needs more blockchain.
I just physically cringed.
- 1
-
On 4/21/2018 at 6:40 AM, nickbe10 said:
Ant particular reason you want to go to the trouble of a Nethook? You can just use the transform functions available as standard functions.......
In my case, it's because I need to generate toolpaths for engraving possibly hundreds of different part numbers at a time, where the engraving lies on a surface.
Avoiding a fixture
in Industrial Forum
Posted
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.