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:

Frank Caudillo

Verified Members
  • Posts

    166
  • Joined

  • Last visited

Everything posted by Frank Caudillo

  1. Even with the Solidworks design tree, it still doesn't remember every single click or piece of geometry that was ever in each feature of the design. I can't imagine how many tens of thousands of clicks and iteration of geometry Mastercam would need to keep in a part file's history.
  2. Just ran the benchmark on a new build for a coworker. 3 minutes, 20 seconds Dell Precision 3630 i9-9900k @3.6 GHz (boost up to 4.8 GHz) 32GB DDR4 2666 MHz RAM M.2 512GB Class 40 SSD Nvidia Quadro RTX4000 8GB Pretty snappy little machine.
  3. Have you updated the drivers and verified that it doesn't work with your spacepilot? A few programmers in my shop are using discontinued models but were still able to get everything working in V9 with the latest drivers even though they didn't "officially" support their models.
  4. I see. Well if/when you do start putting manufacturing stuff in there it would be cool to trade ideas and see what's working well for you. Feel free to PM me.
  5. I know it's pretty belated but I just wanted to check in and see if you've had any progess with PDM and Mastercam. We've had PDM for our models and engineering workflows but I really think think the workflow automation can help with manufacturing data as well. If you've started storing manufacturing data in there what have been your pros/cons of implementation?
  6. I would get G50 output that would cause a crash in Vericut on our Mazak when doing 3+2. The issue was when any plane other than "Top" (actual MC Top or a user created Top) had a different origin other than the Top plane it was using as the WCS. This would happen when moving fixtures and planes around a single part in the file. If I needed to adjust the fixture position I would shift everything and all but one of my planes was associative. Post it and then I would get a G50 that would try to shift the coordinate system by the difference between the index plane and WCS. Check all of your plane origins and make sure they're all the same.
  7. Assuming you want this applied to feedrate, try adding the new format statement 18 below to your post. This should force up to 4 trailing digits for the first value (standard) and three for the second value (metric). Then, at your pmisc2$ postblock, update the new format statement from 12 to 18 (or whatever number you give to the new format statement). #Default english/metric position format statements fs2 1 0.7 0.6 #Decimal, absolute, 7 place, default for initialize (:) fs2 2 0.4 0.3 #Decimal, absolute, 4/3 place fs2 3 0.4 0.3d #Decimal, delta, 4/3 place #Common format statements fs2 4 1 0 1 0 #Integer, not leading fs2 5 2 0 2 0l #Integer, force two leading fs2 6 3 0 3 0l #Integer, force three leading fs2 7 4 0 4 0l #Integer, force four leading fs2 9 0.1 0.1 #Decimal, absolute, 1 place fs2 10 0.2 0.2 #Decimal, absolute, 2 place fs2 11 0.3 0.3 #Decimal, absolute, 3 place fs2 12 0.4 0.4 #Decimal, absolute, 4 place fs2 13 0.5 0.5 #Decimal, absolute, 5 place fs2 14 0.3 0.3d #Decimal, delta, 3 place fs2 15 0.2 0.1 #Decimal, absolute, 2/1 place (feedrate) fs2 16 1 0 1 0n #Integer, forced output fs2 17 0.2 0.3 #Decimal, absolute, 2/3 place (tapping feedrate) fs2 18 0.4t 0.3t #Decimal, absolute, 4/3 place (tapping feedrate) pmisc2$ #Canned Rigid Tapping Cycle pdrlcommonb #RH/LH based on spindle direction result = newfs(18, feed) pcan1, pbld, n$, *sgdrlref, *sgdrill, pxout, pyout, pfzout, pcout, prdrlout, *feed, strcantext, e$ pcom_movea
  8. Do you have an example of code that is currently posting and that same code edited to how you want it to post out? Pretty sure this could be an easy fix.
  9. I usually will edit manual entry code in Cimco and then paste it into the box. Makes it much easier to read and catch mistakes vs that tiny box. If you have more than 750 characters you'll have to link it to a text file anyways.
  10. This has been my method as well. It works well and I have done this to split a model in half and then boolean add a different half to create a frankenmodel.
  11. 2020 processing times are seriously impressive. I'm still mostly using 2017 but when I do use 2020 it just feels quicker, especially with verify and stock models.
  12. Thanks Chally. That makes a lot more sense now. I had never seen this behavior before now so I was pretty puzzled. I'll keep in mind for the future that dynamic might just need more info if I have any issues.
  13. Maybe a silly question but are you re-clicking the Verify button from the toolpath manager after regenerating the toolpath?
  14. Total tolerance is .001". See the file for what's going on. When I created this example using the exact same geometry and toolpath settings I noticed that the problem goes away when only one "area" to rough/finish is chained. With all three sections chained you'll see the boundary violation behavior happen. DYNAMIC_BOUNDARY_VIOLATION.mcam
  15. Came across this little surprise in 2020 just now. Dynamic path is violating the boundary when it leads off the material. The outer most path is a finish contour at 0 stock (Verify green) and the dynamic path violating it is leaving .01" stock on the wall (Verify purple). I can easily fix this by adding more stock to leave, but I feel like dynamic shouldn't do this regardless. Has this been a thing for awhile that I'm just now encountering?
  16. Here is one example of using only the QAT. Most of my commonly used functions are up there. I leave the wireframe ribbon tab enabled because I've memorized the Mastercam default ALT keypaths for them and those don't work if the ribbon is not enabled. I only use that for wireframe creation though. I wish there was a way to add more buttons to the QAT and have it to fit more rows instead of making you expand it.
  17. I don't get to mess around with serious post stuff too often so it's always nice to get confirmation from the Post Man himself, lol. Thanks, Colin.
  18. What Colin mentioned should work, but it also looks like the hsm1_flg is not being set to 1 when G61.1 is turned on. This is basically telling the post later on that G61.1 is not on so it has no reason to turn it off with G64 in the phsm1_off postblock. In the pshmb_on postblock change the last line for Option 1 from "hsm1_flg = 0" to "hsm1_flg = 1" and try that. Just as a side note for future reference, instead of posting images of code you can copy and paste it into the code window (the <> icon above the normal text window) like Colin did in his reply. This keeps all the formatting the same and allows other users to copy and edit it to make it clear what should be changed.
  19. I think there could be a few different reasons why this isn't working. If the Postability post is using a string select table to set the high speed option on or off but this new post is not, then simply copying and pasting those postblocks in without the string select table won't work. If you say that it's at least turning on the high speed options in the new post then there must be a string select table it's using but potentially a correct flag isn't being set. Can you show the phsm_on postblock as well?
  20. This is definitely a nice touch. On a related note the warning that used to pop up when deleting associated entities now shows what entities are associate to toolpaths, solids, etc.
  21. Just ran this through 2020 and got 4:03 - about a minute faster than 2017 on the same machine. Not too shabby.
  22. I've had this issue when trying to migrate posts to 2020, as well. Thankfully it was only for testing and not for all of our programmers using Mastercam, but it was a pain nonetheless. It's been awhile so I can't remember if I even fixed it or not, but it has me rethinking if we should just keep posts stored on each machine like Mastercam defaults to. I know this would make things much less of a hassle. Of course, the whole point of having them on a shared network drive is that you know that all programmers are using the exact same post. A work around here would be to use Group Policy (if your computers are on a domain) to run a logon script that could check if a post stored on the server has been updated and then overwrite local copies with the server copy. This way you would have the benefit of knowing all programmers are using up-to-date posts without breaking Mastercam's file structure.
  23. Something like NC-Base from Cimco will handle all NC file revisions pretty easily. Might be worth talking to your local VAR.
  24. They basically split up Trim/Break/Extend into separate functions. Where you used to be able to trim entities together, trim to a point, extend entities (positively or negatively) all from one dialogue box, you now need to accept and open up a new dialogue box for each function. I also dislike how they change "Extend" to "Modify Length". You used to be able to enter a negative value to shorten the wireframe, now you must select either Lengthen or Shorten and are only allowed positive values in the box. A very good workflow that used to contain a lot of functionality has, in my opinion, been completely neutered.
  25. It seems relatively trivial, but it's keeping me from doing anything significant in 2020. There's a lot of new things I would like to take advantage of but I'm not sure if I want to recommend our shop to switch out of spite.

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

×
×
  • Create New...