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?

6 minutes ago, jmk021083 said:

Thanks for the replies.  I was just curious for some of the reasoning being that you can build your own machine.

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?

1 hour ago, pullo said:

Matsrecam 2020

 

3 minutes 47 sec Metric 1

 

Very good news from 2020 testing . Calc times have improved by 5% compared to 2019 .  My initial result looked like 2020 might be slower , but I was just sloppy. 

All other Mastercam sessions must be killed off as they seem to influence the end result. 

Compared to 2018 that makes it a whopping  26% improvement in calc times .

 

Gracjan

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.

27 minutes ago, Programinator said:

Ended up getting a Dell mobile workstation.  I need to be able to travel otherwise I would get a desktop. 

Now I just need to get a duel monitor setup.  Any suggestions. I'm thinking the 

Dell U2417H UltraSharp 24'' LED

These are the Specs of the dell laptop:

• Windows 10 Pro x64 Operating System
• Intel i7-8850H, Six Core 2.6GHz, 4.3GHz Turbo, 9MB Processor
• 32GB NECC RAM 2666MHz
• 4GB NVIDIA Quadro P2000 Video Card
• 256GB PCIe M.2 Solid State
•  

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.

1 hour ago, Matthew Hajicek™ - Conventus said:

The easy way is by setting the plane for the 2nd op stock model.  On a fresh level I create a handed gnomon at the origin of the first WCS and make a copy of the part.  Then I rotate and translate the part and gnomon together until the part is positioned for the next op.  Then create a plane by geometry from the moved gnomon, and set it as the plane for the next stock model.  Then everything remains associative and any changes you make to op1 will show up in your op2 stock model.

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?

1 hour ago, Grimes said:

you guys are buying computers my boss would have a heart attack buying. my comp which i picked out personally doesnt have anywhere near the specs youre speaking of

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.

36 minutes ago, JParis said:

It is...

You might need some API development but in a past life around SW2006, we were using it then to manage all files related to programming

13 minutes ago, Goldorak said:

Post , machine and control def need to be outside of the PDM, but the MCAM files are in 

we manage files like 

C:PDM

>Client

>>part number

>>> inspection report, drawings, SW and MCAM files, setup sheets and NC files 

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

4 minutes ago, Goldorak said:

we use Solidworks EPDM here, the nicest things is that you can implant an approbation process via a work flow , plus you can filter the extensions  rights to evrey users 

 

Programmers can see all the files 

operators can only see the latest NC and PDF files that went through the complete approuval process 

 

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.

35 minutes ago, Newbeeee™ said:

My company ran a folder called customers/part number and issue/

Then everything within but it was a small company so it was controlled.

A customer of mine had cimco and i got the oportunity of a big project for them so spent some time on their site using it.

I can confirm it rocks.

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).

3 minutes ago, Ewood42 said:

We keep MCAM files separate from NC code. Our parts are all given a unique assembly # when they're drawn (all of the parts I program are our own), and are sorted according to that #, broken up into groups of 1000 #s. Then subfolders separating the type of operation (milling, turning, MT, drill, etc.), then another set of sub folders for the specific machine. My post adds a "M00 (CODE UNPROVEN)" line to the top of every file I post to flag it as a new file. New files are only sent when requested by the production supervisor. After a program is finished (and this is what I find trips up most people on revs) the files are saved back and compared to the original code from MCAM, I determine what changes stay, merge/edit the file, then overwrite the unproven code... then IMMEDIATELY remove the file from the control (that's the goal anyway...).

 

At my last shop the operators were pretty bad about keeping common program files in the machine, and when a rev came around, I would have new code ready to go, but was never told when the part was up to run so they'd end up making old rev parts. Made for some pretty fireworks when stock size changed with the rev...

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.

26 minutes ago, JParis said:

Cimco DNC-Max with NCBase can help with file control revisions and serving only the latest revisions of programs.....

Some kind of database server is really the best way to go....sure, you can use permissions and such, the time overhead to really keep things up to date can become onerous...

Even with a DB program there will still be some overhead required....

I am not a fan of program changes on the floor....too many times I have seen that get WAY out of control....

 

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.

6 minutes ago, RaiderX said:

keeping source and nc files seperated helps with user permissions and lends itself to AS9100 and MBD requirements.

I must ask what you mean operators need to grab the most up to date code. is old rev. code available to them? if so big no-no.. IMHO

only latest greatest verified or proven files should be made available to general population in a shop.

we do it old school, but am currently in a one man show at this point. doesnt set up well for the future but management needs to drive that.   ??

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!