I have this happen all the time, but I know exactly why it does in my case. We keep the tool library, machine def, post, on a network drive so all our workstations are using the same settings and info. It's slow because the network and server hardware is trash ( workstations are connected to network with wifi), and I'd be hard pressed to convince the company owner to put SSDs in the server and put the whole LAN on a 10Gb switch.

This is what I use. Every now and then a manufacturer step file is supplied with the solid positioned wrong, but that's easy to fix and save over the original step file.

I use these Harvey DA chamfermills all the time. Here's what I do for all double chamfermills, I define them as a chamfermill with the length of cut from the tip to the point of largest diameter. Then in the toolpath I use the chamfer variant of Contour, I set offset type to top with a value of zero, and a chamfer width of zero, then I if I am cutting a chamfer with the front of the tool I set +.02 for floor stock to leave and -.025 for wall stock to leave. If I am cutting a chamfer with the back of the tool the only difference is I set -.02 for floor stock to leave and -.025 for wall stock to leave. One further recommendation for anyone doing this is to use entry point chaining to drop cleanly through the hole before making the backside cut. Only downside is I need two separate toolpaths, on for all the fronts, and one for all the rears.

He doesn't have a rotary axis, he only has a rotary indexer where the rotational movement is stored in a separate program inside the control box attached to the indexer. He needs gcode in machine control to ping the box via the M21 output signal, whereupon the box will advance the indexing program one step and return ping the machine control to allow the program to continue. Cave man simple solution is most probably just building a manual entry with the requisite safe moves.

They're the same thing, VC is the ISO standard abbreviation for the speed at which the metal is going by the tool or vice versa, same as DC (cutting diameter), APMX (max depth of cut), and Fz (feed per tooth).

Truly magical

Was gonna say something else, but then I did a double take and saw the .0002 tolerance. This reminds me of when the company I work for quoted a job without looking at the fine print and seeing that the drawing incorporated by reference the customer's internal standard which stated that all such parts and resultant assemblies had to be machined and assembled in a cleanroom, three different and excruciatingly detailed cleaning processes, and finally put through an autoclave.

The other one that makes my eye twitch is when people use tool length offsets calculated from machine zero, and leave the WPC Z at machine zero to make it all work. Actually, wait, I just remembered something perhaps even more cursed, I was told, that by switching the control tool offset mode from radius to diameter that it would "make the machine twice as accurate".

I'd do it all in one operation, part it off to length with a slitting saw

Yes, I mentioned that I found out about that a few days ago, and it made a massive difference when computing dynamic rest mill operations. Out of the box, mastercam seems to be set at 4 threads only.

So, following that link I see mill MD/CD/Post packages only. Is lathe in the works and just not available yet?

Okay, that makes sense. So mastercam wants all the clock speed you can give it. I had a sneaking suspicion that it wasn't really engineered to heavily multithread to the true extent of such hardware.

That sounds almost preposterous, as all top end workstations are Xeon only, But on the initial subject, today I found out about the multithreading manager settings, and that appears to be where most of my bottleneck was. Mastercam by default was only using 4 threads

Was told several times that the most efficient use of a tool was to run it until it exploded, by the company general manager, his technical background is as an accountant. He shut up about it once I showed him the parts and toolholders that were being wrecked from such methods, and explained to him that tool life and load monitoring could reliably predict that these "still good endmills", he had rummaged out of the carbide bin to show me, were in fact most likely going to fail halfway through the next pocket. Expensive option is buy a presetter with a good camera, I believe they use infrared to make tool wear easily seen. Cheap option is one of those electronic "microscopes" off of ebay.

How utterly horrifying

As we all know, there is a difference between minimum specs, recommended specs, and optimal specs. As I get more into 3D heavy toolpaths and rest mill computation, I notice huge computation times, and while watching my resource usage my CPU (Xeon E-2286M) cores are nowhere near maxed out, my GPU (Quadro RTX 5000) is basically idling, disk access is idle (Samsung 970 Pro), RAM (128GB DDR4-2666) usage is steady at around 10 to 20GB. So what is bottlenecking mastercam, or should I say, what does mastercam really want?

Yeah, I've used that strategy before. Sometimes I just run my chamfering before my finishing, usually when I'm concerned about a burr being pushed by the chamfermill, such as into a finished bore.

Well, I just always use climb, mostly out of ingrained habit. But I've been thinking that with the shallow DOC and over 50% stepover of highfeed machining the conditions that benefit climb vs conventional are not really present, so why not go both ways and truly maximize cutting time.

This all depends on the ratio of flute length to diameter, and hardness of material, softer materials can be machined with higher stepovers. With a tool of 2.5xD or less, I run around 10 to 12%. Over 2.5xD and I run more toward 7 or 8%. Two examples of this would be 6061 Aluminum and 1018 Steel. In aluminum I usually use a 1/2" 3FL 1.25LOC endmill at 15% stepover, 7500RPM, and 135IPM. In steel I usually use a 1/2" 7FL 1.25LOC endmill at 10% stepover, 5300RPM, and 120IPM. Also, remember, tool holder runout is your enemy in HEM, not only will it sound like hell, it will prematurely destroy your tool.

Never used them, I just looked at their website and it is terrible, but that is all too common in the tool industry. The company I work for uses a mixture of Imco for HEM roughing, Fullerton for finishing, and Garr for general purpose

I was taught by cranky old machinists to always make my Z zero the face of the part, thus all negative numbers are cuts and all positive numbers are clearance.

>new thing is proposed >we don't currently have new thing >we've never needed new thing before >therefore new thing is self evidently bad and dumb >I and my main co-conspirator scrounge together a working example of "new thing" >usual suspects are predictably baffled that such sorcery is even possible Round and round it goes, the only reason I work for these fools is that I have a good manager, a couple good coworkers, and all the nearby shops are somehow even worse.

I'd like to have Axis Combinations able to be mass edited via "edit common parameters"

Yep, form taps are a glorious thing. Only major thing to worry about is thinwall bulging, which is easily solved by getting the tapping done before final wall finish in the relevant areas

Another solution is to utilize a G10 to zero out the radius geometry register of the relevant tool numbers utilized in the program. I have put these in particular programs where a certain tool under no circumstances should have rad geometry values going on, although that depends on the guy at the machine not being a caveman who uses the wear and the geometry registers interchangeably. Ultimately, yes, macros are the only way to be sure, but also tend to induce equal parts awe and severe consternation in the superstitious villagers.