Jump to content

Welcome to eMastercam

Register now to participate in the forums, access the download area, buy Mastercam training materials, post processors and more. This message will be removed once you have signed in.

Use your display name or email address to sign in:

Chally72

Verified Members
  • Posts

    370
  • Joined

  • Last visited

  • Days Won

    17

Chally72 last won the day on March 17

Chally72 had the most liked content!

4 Followers

Recent Profile Visitors

1,334 profile views

Chally72's Achievements

Newbie

Newbie (1/14)

  • Dedicated Rare
  • Reacting Well Rare
  • Very Popular Rare
  • First Post Rare
  • Collaborator Rare

Recent Badges

466

Reputation

  1. I'd just send the questions to your reseller. CIMCO probing, when we did testing, came with the modified haas 3/4 axis post directly from them and it was 100% plug and play. I'd be very surprised if there were suddenly any issues with posted output. If your reseller used their own post and added CIMCO probing routines, (which is not a big deal to add into a post,) then maybe there are some slight tweaks to be made.
  2. Hey Sigurd, I assume your problem here is unwanted cutting of the top surface of the part at the end of Toolpath 2 which is doing the cavity, and where we see the "Band" machined in your part picture that doesn't exist on the model. What is likely happening here is that because you are using two different tools- 0.280 ball for Path 1 and 0.311 ball for Path 2- is that you have some slight error in the tool Height offset. The way this is programmed is primed to show even the slightest height variance- Note here how Toolpath #2 takes a pass right at the sharp edge of the cavity. If those two tools are not perfect in their H offset down to the tenth of a thousandth, you'll get mismatch because you're essentially asking one path to remachine part of the other with a zero tolerance: Backplot and Verify/Simulation would never show this because of course in the computer world, all the tools are a perfect shape with perfect height offsets and no wear! To avoid this situation, you could do something like Turn on Tool contact point in the Toolpath Control page, and then also go to Model Geometry and add the Top Face and Front Faces as Avoidance surfaces to clean up the motion that Tool Contact Point creates. I think you might be using Toolpath #2 as both a roughing and finishing path, so this may not be viable, but it's how I would avoid these "accidental" remachining circumstances. Another solution would be to finish both surfaces with the same tool, if possible. This will naturally avoid this tool offset problem you're encountering.
  3. Linking would be a big one. By transforming within the operation, rather than transforming an operation as a whole, the NCI is radically different in terms of headers and how it could be read/interpreted by the post. Note also the sorting options you have to do some more intelligent things with how you break out that toolpath and do each depth on all transformed contours before moving to the next, etc, which can only exist if the transform is calculated within the toolpath itself. It's also nice in the case of blades or other repeating shapes to have all information related to cutting the part contained within one toolpath, rather than spread across two- the Morph/etc AND the transform.
  4. Just a note that the Core certification program is new and most of the materials are completely revamped in the last 12-24 months. Usefulness depends on a few factors. I've had job shops that cared more about their own practical tests, and big corporations that all but required a cert of some type.
  5. If you are Saving and Loading defaults in the actual toolpath dialog, this WILL affect the point sort order in the hole selection panel as well, so you can set point to point, green check out of hole selection, and then click Save in the toolpath to overwrite your defaults. Remember that sort order, like other toolpath parameters, will also change state based on "last created op" unless you've turned that behavior off in config, so if you're creating multiple subsequent drill ops, it's always remembering what you created the last op with and then starting you off with that as a setting.
  6. Hey Kendo, could you post the file or send it to me if possible so I can poke around and offer some suggestions? In the subpages under Cut Pattern, there are options for height control similar to steep/shallow, but a lot of conventional Optirough wisdom does not apply here. Looking at your part shape and approaching it with my apps engineer hat, I'd probably choose to go after this with multiple Optiroughs with stock models, but with some preconfigured settings with 3+2 auto, perhaps you can get something approaching as efficient as opti with a little less time invested.
  7. Just an update that a defect was logged for Thread Mill spring passes not keeping override RPM- thank you for sending me the file.
  8. Verify has gotten a lot of attention in 2023 to try and cut down on the number of issues- I used to also have to shut down/restart Mastercam quite a bit in 2021/2022 to "clear the works". A good chunk of the issues can be solved in '21/'22 by going into the Verify/Simulator options and toggling your machine selection to something else, then toggling it back to the one you want to use. The spring pass issue is something that should be looked at, if you have a file.
  9. I know that in the case of things like the C axis of UMC's, when running a Next Gen Control, there are no longer any windup limits and you can safely change the control def min and max travel limits to a number of 9's in a row, (or go and edit your .pst if the axis limit values are stored there), to remove the unwind being added to your posted code. I think the limit still exists on the ST20's, however. You can give it a try and the worst that will happen is it'll reach the machine's max windup and then stop and throw an error when you hit degree 36,001.
  10. Hi Rob, I sent you a message but haven't heard from you. If possible, I'd like to take a look at that toolpath so that we can determine if it's a toolpath-level issue or a rounding issue when the NCI vector is converted to an angle- (Very likely the latter and I'd like the team to look at it).
  11. Hi Shiva, Here's a video showing how to build up a regular morph toolpath on an impeller to get similar motion to what you'd get in Blade Expert. Using Oval form tools, you might not use this method of From Chain, but instead set side tilt by angle or contact point in the Tool Axis Control page. Trying to get complete, clean paths using oval form tools on impeller geometry is a large programming challenge. You can always use the trick of using a path like Blade Expert as the source path for a Convert to 5 Axis operation, and take advantage of this to swap out the tool to an oval form tool from a ball mill and adjust the collision control tilt and retract.
  12. Hey Jake, Even though we're locking this to 3 axis, Deburr is still a multiaxis path in the background, whose output is restricted to linear segments- so there's no way to have this path type output arcs. Depending on your machine, you should try going after smoothing/tolerance parameters at the control to loosen them up and allow the machine to flow through these linear segments more naturally- IE, Haas G187, Heidenhain Cycle 32, etc. Using a looser toolpath tolerance to avoid dense clumps of points will also help. That 0.0005" tolerance on your example path inserts some pretty clustered groupings that would wreak havoc on machines with no/limited smoothing and lookahead.
  13. Hey Jake, thanks for uploading the file. This "noise" issue is something we spent some time addressing for 2023 to improve results. This is happening specifically in the area where those two sharp edges come together to the single edge- What happens when the lollipop transitions through that "Y" is that at some point, we need to shuffle the tool to the side so as to not violate/gouge our part beyond our allowed edge break and tolerance. 2023 handles this a lot better and gets rid of the funky oscillation. It actually helps to loosen the tolerance back up again, so as to allow more wiggle room for the tool to overcut/gouge as it reaches those intersecting surfaces. I brought it up to 0.002" on your path and regenerated. The remaining zig you see below is the minimum necessary move to avoid chewing up the adjacent edge as we pass through the Y intersection: And here's what it looks like for tool engagement in backplot:
  14. There are a few things we're looking to do to alleviate these issues in the future: -Change helix mill entry/exit sweep default to 90°. Because of the math being used to automatically create the lead arcs, 180 degree arc sweep and control/wear comp immediately put you into the scenario of turning on comp on an arc- and invalidate the use of Start/End at Center to get you that linear move. -Notify a user at toolpath generation that cutter comp is being activated/deactivated on an arc move, and suggest adding a linear entry/exit. This would replace the need to add this logic to the post just to see the issue that is being created at the toolpath level. -Make it easier to add perpendicular entry/exit in a relevant way.
  15. I'd want to take a look at the file before answering that one, so as to attempt to give correct info! Please send it over if possible, or perhaps email pictures if not.

Join us!

eMastercam - your online source for all things Mastercam.

Together, we are the strongest Mastercam community on the web with over 56,000 members, and our online store offers a wide selection of training materials for all applications and skill levels.

Follow us

×