Just ran the benchmark on my new laptop last night. Using the original metric I got just over 5 minutes, which is almost twice as fast as my desktop I had been using.

I just got this MSI from HID Evolution. I was originally looking at Dell and Lenovo workstations, but their cooling configurations look really wimpy compared to a gaming-type laptop, like the MSI. I also liked the fact the HID also adds some custom build touches to mitigate heat like CPU delidding. Cost about the same as a similarly spec'd Dell or Lenovo, but I actually the think the processor is better in the MSI vs the options you get with the other two. I've been putting it through its paces today and I'm looking forward to running the benchmark on it tonight.

I just recently used it on a series of stacked counter bores. I set my initial Z-height to a clearance height above the part then I milled the deepest one first. At the end of that operation I set my retract height to the bottom of the next counter bore and finished that one, and then repeated the process for the last. These were all roughed out, so I didn't just plunge into the deepest counter bore first. It was nice because the tool didn't have to come all the way out to the typical retract height and back in.

...are awesome. I've been using Mastercam for almost three years now and I am just starting to really figure out how slick they are for keeping a tool down between operations. Any other tips/tricks specifically for Home/Ref Points that we should know about?

As far as I know, you can build your own machine for regular mill/lathe Machine Sim, but not for Mill-Turn. As Colin pointed out, it is literally a complete Machine Environment that is built by CNC Software and not customize-able by the end user (at least that's what I was told by our re-seller), which is the reason for the associated maintenance costs. If something needs to be updated or fixed, only CNC Software can do it.

Just went to a seminar on this from our local reseller yesterday, and it's completely different than regular machine sim or verify and absolutely necessary if you want to get the most out of your mill-turn with the least amount of headaches.

Someone else just had this problem the other day. I'm almost certain it has to do with your post's "sopnotehst" string select table. Download the latest version of the MPMaster post and compare the same string select table to your post. I'll bet they are different and all you'll need to do is update yours from MPMaster's. Mastercam is outputting data for the operation comment that is out of your string select table's range. It shouldn't be hurting anything with your code, but it's definitely annoying.

You're talking actual time spent in front of the computer programming, not verification time, right? If so, then I don't think there's any hard and fast rule. It really depends on programming style and the overall goal of the program. If you're running one-off R&D stuff, you might not be so concerned about cycle time. However, I know I've spent a solid week just trying to squeeze every last second out of short cycle production parts with low margins. Just curious why you're asking. Is this for quoting purposes? Finding some kind of benchmark or standard to hold programmers in your shop to?

Wow, that's pretty impressive. I'm still over here using 2017, so I'm sure I'll be pleasantly surprised when making the jump to 2020.

I think I can answer this one, as Colin helped me with this not too long ago. This has to do with the newer high speed surface toolpaths and the string select table for outputting the toolpath name in the comments. What he had me do is download the latest version of MPMaster and update my post with the "sopnotehst" string select table. What I believe is happening is Mastercam is putting out a value that is greater than what your current post's string select table is setup for. Try that and see if it solves the problem. I always used to get this error in our posts and while Vericut never showed any issues with the code, it was still annoying.

Let me know how this works for you. Is it a 7530/7730 by chance? I was eyeing that one but some review said that heat could be an issue for it so I'm also looking at Lenovo's P-series mobile workstations.

Dang, I should have known there was any easier way. I never took the time to understand how the planes for the stock model worked. I'll definitely try this out next time.

Is there an easy way? Not really. What I'll do for moving a Stock Model around a tombstone for different OPs, is run the first OP through verify and save the cut stock as an STL. I'll then merge that STL into Mastercam and it should just line up with the OP1 model position that I just verified. After that I'll select the STL and x-form it using the solid edges from the OP1/OP2 model positions. Once it is in that new OP2 position you can save it as an STL in that position to use for a new stock model or verify STL. Using this method, I've been able to verify many operations/positions around a tombstone before I get to Vericut. Hope that helps!

This is more of a general question about PCs, albeit related to processors: Are most of you guys building these PCs yourselves or buying off the shelf? I'm trying to spec new computers for my shop and I doubt they would want to have home built PCs, so I'm using Dell's workstation configuration tool. From what I can tell, all that I can spec for a desktop are Xeons, though a few do have clock speeds around 4.0 GHz. Mobile workstations can be spec'd with some i7s and i9s but the best base clock speed of those is 2.9 (Turbo up to 4.8). Based on the CPU Benchmark single thread rating, some of the available Xeons don't look too bad. Am I losing out on that much performance by going with Xeons, even if they appear to have good performance based on those benchmarks?

Unless you're doing really simple programming work, you're most likely losing out on a lot of productivity. Even my desktop workstation, which is 4 years old and was built with pretty good components at the time, is costing me probably an hour or two per week of productivity.

Not trying to jack this thread, but it's very closely related to my own dilemma: trying to spec out a new mobile workstation off the shelf from Dell. As far I can tell, I've only been able to spec Xeon chips for their mobile workstations and the E-2176M had a pretty decent single thread rating. Here is a comparison between the E-2176M and the i9-8950HK. The single thread ratings are fairly comparable (2624 for the i9 vs 2505 for the Xeon), but I have no grasp of how much performance difference that really is. All other comparisons between the two do not show much of a difference. I understand the biggest Mastercam loves clock speed, but would it be all that bad to get a Dell mobile workstation with the Xeon? Edit: I spoke too soon about being able to spec a Precision Mobile Workstation with only Xeons. That same i9-8950HK is available for them off the shelf. I guess my question still stands though: If the two chips are that close in performance, would a Xeon be more durable over the lifespan of the computer?

Right off the bat I'm seeing that both problem lines are using sgcode string variables so I would look at that string select table first. What version of Mastercam did this post originate from? You might need to get the latest version of MPMaster and compare the string select tables for that variable to see if yours needs to be updated. I had the same problem with some of my posts, except it was just for the newer High Speed surface toolpaths, so nothing that would wreck the post, but it was annoying to see them all the time.

While I'm sure this can be done with the post, the easiest way would probably just to split it up into two different operations. Copy that toolpath below itself and make the first one roughing only with computer compensation and make the second toolpath the finish passes WITH wear compensation. That should easily do what you want it to do.

Probably the best way to open .pst files is with the Mastercam Code Expert because it has built in recognition for predefined variables, operators, etc. that make it really easy to edit the post.

This is great to know. It would definitely be best to use an existing software vs trying to implement something completely new. Thanks guys.

We also have Solidworks PDM, which is primarily used by our engineering team. As programmers we also have access and I wondered whether or not that might be a viable option to handle all of our manufacturing data. Might have to look into that a little more. Do you have all of your Mastercam files in the vault, as well? I thought about even putting our Mastercam posts and machine/control definitions in there, but I worry about that being more trouble than it's worth.

I've heard good things about Cimco's products and NC Base sounds like it would really help us out. I just wish it could also handle tool management. We're leaning towards Wintool to handle our tooling and they also have a file management module which we would probably add as well (since I would hate to have two different databases to manage). That's actually a great idea that I may have to integrate into our posts to ensure the operators are aware that they're running new code. We've also worked hard to get our posts dialed so that there's no hand editing of code so that we can backup and compare what the operators ran and if any changes were made during production. Being able to cleanly compare and see the minute differences in files has saved A LOT of headaches.

I absolutely agree that a server-based solution is the way to go and it is our end goal, however budgeting restrictions are putting that on hold for now. I don't like program changes being handled on the floor either, which is why we've also starting implementing a program change request protocol where the operators need to bring any issues to their immediate supervisor before any changes are made or before it comes to programming for support. Trust me, I would like to see all of this locked down and running much more smoothly. Like I said, short of going full on with a server-based manager I just wanted to get a feel of how other might be handling things under similar circumstances.

In a way, yes, old-revision code has found its way into machines at some point. It drives me up the wall and we're going through some growing pains at the moment, which is why I would like to figure out the best practices to implement going forward. If a program needs to be updated, it is usually backed up and deleted from the control. Changes are made by the programmers and then when the job needs to run again the operator needs to get the newest revision code. Our current file organization makes this process cumbersome and not all the operators know exactly where to go to get the correct files. This is what I want to streamline. I agree with the permissions side of things. If all the NC files are in one area, the shop floor computers need only have access to that one folder and everything else is off limits. Part of the problem is also just driving home best practices to all the employees on the floor. Everyone has to be on-board or the whole system falls apart.

Good morning everyone, I wanted to get some different opinions on the best way to manage NC files in a medium sized production shop. The way we do it now is by grouping ALL of the relevant files for a part together (Mastercam file, NC files, Vericut files, Source files, etc.). While we've been able to keep things fairly organized, I feel that it has its limitations, especially when the operators need to grab the most up-to-date code for a particular job. Short of going with a full blown file management system (we've looked at Wintool to manage our tooling as well as their NC File Manager), what has worked, in your experience, to handle this just in the basic Windows Explorer environment? I've been thinking of having ALL of the NC files in one main folder that is then sub-divided by machine to make it easier for the operators, while retaining our traditional organization on the back end for us programmers. Any input would be greatly appreciated. Thanks!