Yeah an update came out Tues/Wed. I don't recall seeing any mention of a problem like yours in the last few release notes but it may have not warranted mentioning. Hopefully it'll fix your problem.

So finally got to run the test file in 2022 (update 2, haven't installed 3 yet) on my new system. Dell 3650 Intel i7 11700, 8 core, 2.5ghz to 4.9ghz (max I've seen so far is 4.8ghz) 32GB DDR4, (2x16 at 3200mhz) Nvidia RTX5000 (16GB) 1TB M.2 SSD System was supposed to be a Dell 3660 with an i9 12900k (8P cores 8E cores 2.4ghz to 5.1ghz) liquid cooled 32GB DDR5 4400mhz (2x16) RTX A2000 6GB 1TB M.2 SSD Not sure how much of a difference I would see between the 2 systems, but overall not horrible. 3min if you all the times up, 2:45 if you go by straight time. One of the other programmers will be getting the 3660 I was supposed to get so once I get it set up for him I'm gonna run the benchmark file. I will say I wasn't on top of it when I ran the benchmark on my pc in setting the multi threading to realtime as I may have missed it by a few seconds but I don't think it would make much of a difference.

I've never had that specific problem with Cimco, but when I 1st went to 2022 months ago there were a lot of problems and just when they fix 1 problem, it seems to create another. I just installed 22.01.45 a couple days ago and so far I haven't seen any issuse and nothing like what you've described. 1st thing is to check for video card drivers. What do you have for a video card?

In central Maine I make just north of $30/hr which on a 40hr week is $65k/yr. I typically get 5-8hrs o/t a week (more is there if I want it) which will get me close to $77k/yr. Been in the trade (same company actually) since '95 and 18-19 of those yrs have been programming. I program and run horizontal and vertical mills (mix of HAAS, Fadal, Fanuc controls and the Mazak vertical mill we bought a few yrs ago) 5x verticals from Mazak and countless slant bed lathes (all with varying generations of Fanuc controls) and a few VTL's. I also do a lot of the immediate repairs if we can't wait for an outside source. In my area my income is pretty good strictly speaking, but how it compares to other programmers in the area I don't know as there are only a couple shops w/in 50 miles of me the surpass us in size and the types of machines we have and I've never tried to get a job at any of them so I could be way underpaid. But I like most of the people I work with and for so that helps.

Oh I know it's been discussed more time then I can count. It was the way Matt worded his comment that made me question it. As to which is better, it's all preference IMHO. You cannot take the human error out of everything and human error can scrap a part no matter which form of comp you use. But some form of comp should be implemented regardless. For dynamic milling we only use regrinds up to .015" under nominal size for that reason. Probably could go smaller but .015" u/s always works. Typically I always add a comp pass to the roughing tool to smooth out the walls regardless just to eliminate the ripple effect on a finished wall.

Not sure how using one over the other leaves money on the table, but to each his own. I've programmed say roughly 18 of the 27yrs I've been in the trade and have never run in to a situation where I couldn't use control comp. To me it's personal preference and is generally decided on by how a shop has handled it in the past.

Now you have me wondering James, I'll have to go back and try it again, but I'm pretty sure I was getting an invalid G code when I tried it. Granted it was a couple years ago. We use G68.2 on our 5x Mazaks exclusively and as long as you keep the machine calibrated it's the best thing since sliced bread.

I will add that it is absolutely crucial that your COR and your primary work offset has to be as good as possible. As if either is off everything after that is off. So typically it's best if you cut a feature at "B0" then measure it and adjust until you get it right. We don't program off machine COR and no need to. We pick a feature on the part to set our origin and program off that point at every rotation. Before we used my macro, the operators had to set the individual work offsets, so usually what we would do is pick a feature at each rotation that the operators could tram or edgefind and program from that point. If there was nothing the operators would put a hole for a tooling ball in the fixture and tell me where it is in relation to the programs primary work offset, then I would tell them how much to move each axis to get to the program origin for a particular rotation.

G68 is usually a paid option for Fanuc controls and requires the center of rotation be set up in certain parameters. If you "bump" the machine you have to verify the COR hasn't changed and change it if it has. Our Mazak 5x mills have a program that I use combined with an Excel sheet to tell me which parameters to change and to what as it's based on the previous values. Works slick. Since none of our machines came with G68 option, I created a macro that can mimick G68. You just need to set the COR (X&Z on a horizontal mill) in a fixture offset you typically don't use and my macro can calculate the new X,Y,Z origin of any B rotation at store it in any fixture offset you want. I currently have it set up so it increments the work offset by 1 for every rotation and each rotation is programmed with it's own fixture offset.

There is nothing wrong with self teaching, but too verify you're doing it the way that is least likely to cause problems with other machinists/programmers is needed. I will bet this is how every guy running machines at your shop learned things, but they never asked questions if what they was doing makes sense or "Best Practice". If you cannot convince the powers that be that your way is better (provide examples) then as John said, cut bait and run. They don't want to improve, they just want to keep status quo. To me changing a program every time you need to adjust the size of a part, by reposting a toolpath then pulling the program out of the control, update it with new toolpath, then loading it back in to control and dry running new toolpath (I assume this is done after any/every edit as it's SOP here) is way more of a headache and more likely to scrap a part. How much time does it take for you to make an edit to adjust a dimension from the time you are told you need to make a change to when a part comes off that is now correct? What control is on your Mazaks? We have the Smooth series on all of ours so there may be some differences if you have a previous generation, but probably not much difference. As for trying to help with productivity, see my last sentence in my 2nd paragraph. If you have a tool probe on your machines setting tool offsets is super easy. Even without there are ways to make it simpler and I'd be willing to explain how we do it on machines with tool probes.

In agreement with John on this. Any bad habits you pick up now will only make it difficult for you in other shops. I will say that there isn't always just "one" right way. Sometimes the "right way" is whatever way is needed to get the job done if you're in a time pinch. Had to do some things a little crude on occasion, but only when in a time crunch. Which will happen. Exactly! Your problem seems to be that you're in a shop that is full of button pushers will no knowledge to give except for the "How they've always done things here in the past" advice which isn't always very useful. Like yesterday, my supervisor pulled me from programming to go set up a simple task of programming a polishing wheel for c'bore face on our HAAS and setting it up and getting a part off. I did the program at the control, used an existing vise and clamped up on the part. All I had to do was tram a bore to set the work offset, qualify a tool and go. I trammed the bore, set the offset then handwheeled the indicator away from the bore. Then in MDI I programmed the indicator to rapid to X-.1Y-.1 of the workoffset, then programmed it to feed to X0Y0 at 20ipm. My supervisor asked my why I did that. Told him I always do that (been in the trade for 27yrs), it's to check the accuracy/repeatability of the machine and take any backlash out. If I have to move the offset I repeat the process. This is my own .02c so take it for what it's worth.

You need to use those offsets! Once you are comfortable using them, tell your boss you need an hour or so to train the boys how to use them then start spitting out those codes. You may get a lot of questions that 1st week, but after that it will be smooth sailing. We have 2 Mazak 5x vertical mills, 1 Mazak vertical mill with a 4th axis, a Mazak HQR 100 (dual spindle, dual live turrets), 5 horizontal mills (multiple brands) all with Fanuc controls, 2 vertical turret lathes and 7 slant bed lathes, and 1 old HAAS vertical mill. We currently have 3 programmers, but we handle some fairly complex parts as well. When I was the only programmer we had 4 vertical mills, 2 horizontal mills, 4-5 slant beds and 3-4 vtl's. Granted we usually had repeat work that would keep at least half of the machines out of my hair, but not always. Mazak mills can be a little tricky when using CDC, well in adjusting them in the control and you want to make sure they are all set up the same way. If you have some Fanuc controlled mills you'll want to make both controls behave the same as much as possible. We don't use wear comp and only use diameter comp instead of radius. Hence CDC and not CRC. Any questions with the Mazak's give me a holler, I'll help any way I can. A couple of the guys here have shops with Mazaks and I'm sure will help with any questions.

We have a Mazak VC-500 and an I-600, both 5x vertical machining centers. Other then table size the only major difference is the VC-500 is a B,C axis machine vs A,C on the 600. Both have the smooth G control. They are accurate for what we need. Both machines have part probes so if you're concerned with growth you could probably measure every so many parts (shouldn't meas. the part with the same axis used to machine the feature) and have the machine adjust size's and such as needed, but ours seem pretty stable. We looked at Mori's and DMG's but liked the trunion setups better.

I see what you did and it looked good except right at the very end it drove the tool thru the surfaces. I'll have to go back and and finished model to the file and see if I can fix that with collision or something. Also looks like it might be tipping the part to far and slam holder in to part, but you wouldn't know that because you don't have a completed model. I'll adjust the tilt angles in collision control to restrict how far Mastercam can rotate the trunion. Appreciate the help on this.

This is the zone I'm looking at. As you can see near the end of op#2 the tool is cutting on the tip.JUNK1.ZIP

I am thinking it would be a kin to how Mastercam calculates toolpaths for "Accelerated Finishing" tools. Knowing the shape of the tool and specifying the contact angle Mastercam will orientate the part so the drive surfaces stay at the proper orientation.

I'm using a tilt angle of 30º right now John. Which for the majority of the area I'm machining is fine. But there is a spot in that section where the 30º makes the ballnose cut on the tip or at a dia smaller then Ø.2. When I've used lead/lag angle before Mastercam still ends up cutting on the center of the tool a little bit. Now maybe I'm being to demanding on not wanting to cut on the center at all and that there's no way I can completely eliminate it. I was just hoping there was a way to get Mastercam to recognize what the effective cutting dia of the tool is (in relation to drive surfaces and not the stock) and tilt the tool so it can maintain the minimum effective dia.

Been doing a lot of work lately using 5x parallel toolpaths. As everybody knows near the tip of any ballnose a 4flt becomes 2 effective (approx. Ø.2 on a Ø1/2" ballnose). What I'd like to know is if there is a way to get Mastercam to automatically tip the tool so the effective cutting dia of the tool on the part is larger then Ø.2? I know I could break down every section and change the tilt angle of the tool to whatever angle I need, but on the part I'm doing currently I'm looking at having to make 50+ sections to control this. Would be pretty sweet if Mastercam could do this. I would think it would be a fairly simple function, but that's in my head. Thanks.

So you're on a 5x mill and the surface you need to start machining on puts the trunion at B90. C0. and you want this orientation to post as G54? Then you're rotating the C 180º to machine features on Datum A side of the part and I assume using another fixture offset for this rotation is ok? Is there a reason you can't/don't want to use tilted work planes? Here is sample code I posted right out of Mastercam with no editing on our Mazak VC-500 5x mill. I started with a block at machine B90.C0. G54/G55 X0 is left side of my block, Y0 is the centerline of the block and Z0 is the face of the block at it's specific rotation. I can put X0,Y0,Z0 anywhere I want at either orientations. N1T1M06(3/4" INGERSOLL 4D DRILL) M01 M46M43 G00G90G54B0.C0. M47M44 X4.8654Y.0445S1222M03 G43H#3020Z4. G98G81Z-2.R.1F2.93 G80 G91G28Z0. G90G55B0.C0. X.9111Y-.0388 G43H#3020Z4. G98G81Z-2.R.1F2.93 G80 G00G91G28Z0.M05 G28X0.Y0. M46M43 G28B0.C0. M47M44 M30 The motion looks just fine in Backplot and Verify, but it's not good in the machine simulation as it doesn't show the B axis being rotated. Now I haven't tried this but I believe that if you really want this to work in machine simulation you can edit the stl file that is for your "B" axis and rotate it 90º so it's at the orientation you want it at "B0". However I don't know if it will respect the C axis motion. Honestly you would only need this if you think the head of your machine will hit your fixture or table. Is this what you're looking for?

Start to call me crazy? Bud, people have been calling me crazy for a few decades now. I don't complain about MC much as compared to when I 1st started on 5.5 back in the late 90's things are so much better, but I just don't see anybody (let alone thousands of users) asking for this kind of setup. It just doesn't seem to make sense, and what new functionality they added probably could have been added to existing methods and allow resources and time spent in other area's that need the work. For me the tool side of programming is one of the least significant steps in comparison to toolpaths/options that don't work right and you have to find a work around for. Personally, when MC went to committing to putting out a new version every year back in the early/mid 2000's things started to slide. This kind of motto drives the "lets get new features out, and worry about fixing things later" motto. Lets get all the bugs worked out before we worry about "new" features, but what do I know. Only been in the trade for 27yrs.

I think I get what you mean now. I agree that how you can add extensions to your holder w/o creating it as a complete holder is nice, except I didn't see a way to shorten the ext. in the holder, but I could have missed something as I only experimented real quick. Yeah, how MC instantly adds a holder now is a pita unless you create it in the tool tab. I always wonder who vets new versions out and such because sometimes when things come out I'm like HTH did this get by QC. They way MC sends out new "options" knowing there's a problem or quirks would be like a programmer sending out code to a machine and telling the operator "Yeah it's gonna crash, so you'll have to find a way around it until I decide it's worth my time fixing it". MC has come a long ways from ver. 5.5, but some things are like .

"Splits up holders"? Not sure what you mean. Until about 2018 or so I used to have my holders in one library (actually 2 as I had one for CT40 and another for BT50), and another library with all of my tools. Right around ver. 2018 or so I put all of my CT40 holders in the same library as my tools because we only have one BT50 machine so when I set my default mill tool library it automatically pulled in my CT40 holders. If there was an option to set the default holder library I wouldn't have combined them. Until ver. X (I think, it could have been later) you didn't even have a holder library. Mastercam only used one file for the holder so if you needed to check your holder against the toolpath or fixture you had to create a mastercam file with a 2d sketch of the holder you wanted to use and name it holder.default (or something like that after renaming the default file to something else) then when you backplotted/verified the tool path you saw the holder you were gonna use. When I was done, I would delete my holder file and rename the original back. A lot of work, so yeah it's come a long ways, but I'm just not sure why they added this function. I can list other reasons why I don't like this new layout but I'll stop here.

How many like the new Tool Manager and the splitting up of the tools, assemblies and holders in the lower half of the manager? I do not like it, and the fact I can't save a tool to the library right after I created it w/o making 4 other mouse clicks because MC in it's infinite wisdom automatically assigns the "Default" holder to a tool as soon as the tool is created. Which prevents you from using the down arrow to save the tool, so why even have the down arrow even there, or even have the Tools tab in that case because you cannot save a tool to the tab from what I can tell.

We allow it, but frown upon it. They prefer no more then 1 week at a time and only allow so many people from each dept to be out at the same time. Between programmers and process engineers we have 5 people and they prefer to have no more then any 2 of us out at the same time. Same applies to the operators, no more then 2 mill guys and lathe guys at the same time, but no more then 3 total between departments. We do pay out vac. at employees anniversary date, but prefer not to and don't like more then a week. Our max vac. time is 4 weeks which takes 20yrs to get which myself and the owner are the only ones that have 4 weeks and I believe one of our process engineers will get his 4th week next year. We were bought out by another company last fall and all of their facilities are jealous of our vac. The other 12 plants only get 2 weeks/yr after 1yr and they never get any more. Fortunately they allowed us to keep our vac. the way it is.

The files were already there and had been for a few years. I didn't change the machine def's at all, but I checked them when I installed MC on Win10 and all of the paths were correct. As they should have been. I didn't give much thought to resetting the paths to what was already there until I happened to do it yesterday, and when Colin put his post up it jogged my memory. Yeah, all of those paths stayed the same and are correct. Just re-doing the post processor fixed my problem.