My Varco Reports opens in the whatever window size I last left it in.

Yep... Another company making stupid naming decisions, too.. It used to be easy "Just make sure you get a Quadro!" Now, it's "Make sure you get an RTX, not a Geforce RTX!" "In terms of how this affects product naming, NVIDIA GeForce GTX and NVIDIA GeForce RTX GPUs are separate product series from NVIDIA RTX GPUs." Yes, I had this link handy because I've sent it to three people in the last two weeks. Sharles - Any idea what video card your coworker has?

Just to be clear/pedantic - When you say slow down, is it the simulation itself slowing down or the interface (opening menus/changing translucency, etc.?).

There's a chance this could work for you.. I just learned about it today (thanks again JP!), but it sounds like it might flag a warning when you open the file (if you have it turned on to check at file open). That might be enough...

I'm guessing this is not robust enough to solve the problem for you. It can only tell you when there's a similarly named file in the watched folders as the one you manually added to the list. You'd still be better off with a version control system such as SVN, Vault, etc.

Oh, I'm trying it in 24... If you're saving new revisions with different file names (i.e., Part1, Part1 v2, etc., etc.) you want your list to look like this: Note that I have "file name & extension must be an exact match" set to off. Then, when I ran it, i get this: It does not tell you if one of the .step files you used is deleted, though. It has no knowledge of that.

I just tried it over here, and I had to run "Check All Tracked Files": If I just "check current file" it only changed the Mastercam version of the file. Which I guess is useful if someone changes the Mastercam file while you're working on it?

Cool! Me Too! Thanks JP!

I completely agree. All of the toolpaths I looked after are stock aware (hole making and multiaxis)

Ah, okay, that's a different problem and changing the CD wouldn't be it. I've never had a tool change T/H/D on me unexpectedly.. I know that you can change the H or D offset # in toolpaths > Tool page without it throwing up a warning and it's only saved with that toolpath: I've accidentally filled out the wrong field due to fat fingering when using tab to move between fields? If you can catch in the act, I'd send a file over to QC to see if there's anything logged against it.

Have fun!

Can you post your model up? It might be as simple as choosing the solid face of the hole instead of trying to snap to an edge.

As Ron Said, it's probably this: I have that set up on my Robodrill for example, where it's old enough that it doesn't understand a diameter offset for tool #5. I have to use offset #5 for the length, so I have the Diameter offset set to 100 so it will give me 105. Also, make sure that nothing changed about using head numbers.

Absolutely. The 2d toolpaths are not stock aware, so you'll need to create wireframe that represents your stock if you want to use them manually program that in. That's why this is 100% Opti.

You can try to run the "check solid" function ( Home> Check Solid) The problem has to do with how the solids are stored in their files. Often these solids were saved with too loose a tolerance from the CAD system, and when they have organic shapes (like multiple fillets intersecting), they round the numbers due to the tolerance. That gives you a theoretically fine (it fits within the tolerance so no errors reported) but obviously broken situation like you're dealing with. The worst I have ever seen came from Catia.. You can customize the output so much from that program that you can get some really, really funky stuff. They've made the defaults better in the past decade, at least! -------------------- Another trick to fix it is to try to model prep or boolean features together to wipe out the problem area, then remove the changes with model prep. I don't have any good broken models handy that I'm allowed to show, and it's almost impossible to create a situation like this in the native CAD/CAM system due to the aforementioned tolerancing issues that aren't a problem in the native format. If you can share a model, I'd be happy to see if that method is applicable. It's basically making a big cylinder/sphere around your problem area, boolean add them together, remove history (so it's all a new solid), then, use Model Prep to push/pull or Modify that cylinder away.

Huh, me too... That's really odd!

Looks like you're trying to write it back to a MCX-5 file? You're not saving it to a tooldb file, and I'm guessing that you're not still using X5?

Yeah, I don't think that's a 2023 thing... I'm guessing the model has corruption. I'd be happy to try to open it in 2024 for ya, though.. [email protected] if you want to send it over.

I believe you're having that issue because the centerline of the two arcs isn't the same when are offset by .010 (your stock to leave for the first pass), and with Damping turned on, it can't really contour to the corners well anyway. When you offset by .010, the radius is exactly the same size as your cutter, which is going to always cause a bit of issues with the collision algorithms. This is exagerated since you're using a bull nose cutter and causing gouges around the floor that will be cut out. Also, agreed with Ron on using tilt lines here, especially because you're so close to your cutter size. Just changing to lines and the "Pattern Layers" Distance to .008 will give you this: Oh, one more thing with this toolpath... If you're near the limit of where the tool is at the same radius as your corners, don't be afraid to really crank up (down?) the tolerance. Right now you're at .0002 which is going to be way better than stock, but don't be afraid to try .00005 or .00002 (note the extra 0), that will give it way better data to calculate fit with.

Yep, Unified and Pocket in Multiaxis, and all of the 3d high speed stuff (equal scallop/waterline/etc.).

I believe those just stay on whatever you have set when you exit the program..

Nice job Mike! Welcome to the forum! Great shop, and cool machine

You have to figure out why they're in use. If you right click on the plane (hold down CTRL while clicking to select multiples), you can choose "Report" and then view the Selected. For example, here's a plane of mine in use for a view sheet as well as three toolpaths: *** Plane Usage *** Used in view sheet : FP - Op30 Active : WCS Active : Cplane Active : Tplane Machine group : Machine Group-1 Used in machine group's system views: WCS Used in machine group's system views: Tplane Used in machine group's system views: Cplane Toolpath operation : 51 - G83 - Peck Drill - [WCS: FP - Op30] - [Tplane: FP - Op30] - No 7 Drill .201 Used in operation WCS Used in operation Tplane Used in operation Cplane Used in NCI Toolpath operation : 53 - Thread Mill - [WCS: FP - Op30] - [Tplane: FP - Op30] - Thread 1/4-20 Threads Used in operation WCS Used in operation Tplane Used in operation Cplane Used in NCI Toolpath operation : 52 - Model Chamfer - [WCS: FP - Op30] - [Tplane: FP - Op30] - Chamfer .25-20 holes Used in operation WCS Used in operation Tplane Used in operation Cplane Used in NCI In order for me to delete this plane, I would have to change my view sheet, the currently active W/T/C, as well as reassign or delete the 3 toolpaths.

In general, the i9s are going to have a higher "boost" Ghz as well as potentially more cores. The higher boost speeds seem to be resulting in faster processing. In practice, like all things Intel and modern computing, it really depends on exactly the processors you're comparing, as a lot of the i7s and i9s are either equivalent or worse. As a note, the i7s generally have a lower power consumption (a result of the lower base & boost Ghz), so it's often a good trade off if you need to be mobile more, but in practice, you really want the i9, you're not programming long away from a power source! Unfortunately, I don't know that anyone has done any back-to-back comparisons, say, take a comparable i7, then swap in an i9, but last I checked, the i9s were handily beating the i7s in the benchmark threads.