There's lots of caching that goes on in the background, so for example, if you generate slices @ X stepover at Y tolerance, they're saved. The collision models and everything else are cached as well. If you make a change where the knows 100% that none of that changes, it doesn't have to get recalculated, so yes, it does take less time

I only check that forum once a week or so at this point.. I have about a 20% chance of getting into it, and when I do, I can only use it for ~3 minutes or so before it errors out. It's not worth my time unfortunately

If you can count that high, you don't meet the minimum....

So I was thinkin' that we had this debate before and I posted something from the museum, and sure enough: Back in 2016 I wrote this: 1983 - Meghan - Apple IIe (It was named after Mark's daughter, who is now our President. Sort of like the Apple Lisa) 1984 - Mastercam V1 - 10 Seats 1986 - V2 - DOS 1990 - V3 - 1992 - V4 - 10,000 Seats 1994 - V5 1996 - V6 1998 - V7 2000 - V8 - Start of Mastercam Certification 2002 - V9 2005 - X - Windows - 100,000 Seats 2006 - X2 2008 - X3 - Start of Mastercam for Solidworks 2009 - X4 - Dynamic Motion debut - 150,000 Seats 2010 - X5 2011 - X6 2013 - X7 2014 - X8 2015 - X9 - 200,000 Seats 2016 - 2017 2017 - 2018 - Coming soon. So, V8 was 2000.

Same problem Parallax had in the thread below this one: I'm guessing there's a new hotkey added? Either way, find it here: File > Options >

Absolutely the same, my man It's just so much easier.

The reality is that the reseller very possibly doesn't have anyone on staff who was around during the parallel-port to USB HASP days.. Gotta figure that V9 came out in, what 2000/1? V8 was 1996? That means that their tech support/applications team may literally not be have any experience solving a 32 bit parallel-hasp issue on a 64 bit operating system... My first try would be to set up an old system running windows 95 and see if you can get it working on there. If I recall, there was an issue with the driver compatability for the hasp key (was it an alladin?) that no one has ever solved for anything older than V9 on a modern OS.

Import it to a level and use Dynamic?

It looks like you chose an STL.. You couldn't adjust the STL's position even in 2022 (I just checked, as I'm working on a file in it right now).

Huh, good question. I don't believe it's possible to retract between passes in Circle Mill. Send it into QC and see if Jamie knows of a way?

Absolutely. Morph is like Frank's Red Hot. I put that <stuff> on EEEVVEEERRRYYTHING.

#1 reason to use simultaneous 5 axis motion - It looks cool #2 is because you have to use it so you don't hit things....

It's a problem that only exists when you post this.. It's called "singularity" when the spindle is perpendicular to the C axis. Basically, because the BC is near 0, it calculates that from one side of the B axis to other it decides that it needs to rotate the C axis nearly 180°. Most likely the transition before/after this move where it crosses B0C0: There's a couple of strategies you can use to solve this, but the easiest way is to simply not let it get vertical. If you limit the toolpath so it isn't allowed to go within, say, 5° of B0C0, you can just avoid the problem. On the tool axis control page, turn on "Limits", then do something like this:

Surface radius based feed optimization & Tool conact based feed rate optimization shouldn't be available in Pocketing to you... If it is, something is wrong Here's what my Pocketing > Feed Rate Control page looks like:

It's a form of feedrate control only for multiaxis pocketing/roughing. Because it's a pattern generated on a curved floor surface, the stepover will end up being inconsistent. That's why the Stepover field on the Cut Pattern page is a "max stepover" unlike, say, Opti, which is able to maintain a really nice tool engagement evenly based on what you say your stepover is. Because of that, there will be passes where the tool can get loaded up. This is an attempt to smooth it and slow down the feedrate when the tool is getting overloaded. Sorry, I thought you knew where to find it in 2022/3, it's on the Feed Rate Control page.

The issue is most likely over on the "work offset numbering." You will want it to "maintain source operations." Right now, in the background, it's rotating the toolpath but then it's assigning a new plane and work offset number, like setting a toolpath to New/New/New. What you really want is the equivalent of you creating a new toolpath on the Top/Front/Front plane, so it knows that the WCS is still "top," but it needs to rotate the output to "front." Here's a really elaborate example: (notes: there's generally not a need to include Origin/WCS/Save Planes when doing this. NCI keeps you from having to duplicate the geometry for your transforms, which I usually don't want to do. It doesn't really affect the output as much as the processing time for the input). = Cheers,

Neat, that must have been improved then

For that fillet - Or turn on "round corners" in on the Cut Pattern page. On the original question of Pocketing. The thing to keep in mind with Pocketing (and Opti, for that matter) is that they're really Volume Removal Tools. They need to have either volume, or try to guess the volume to be removed. Both work better when given stock assuming everything else is equal. There's a few issues with the original file and I want to explain what why they're happening and why Gizmo's changes work: The toolpath offsets from the floor to generate the pattern, which is why the Surface Normal needs to be reversed (Surfaces > Normal > Change). Your containment isn't doing anything because it's not a containment boundary. It's two independent chains that don't form a single area. I'm surprised it doesn't error out when generating with that selected. If you do want to use a containment boundary, then it has to be one contiguous loop. The toolpath expands to cut the entire stock model that's outside of the containment (yours doesn't count because of the above point). If you don't have stock, it will try to figure out volume from the wall height. This works fine as long as the walls are all the same height, but can cause problems if the heights are different height. Another way to control this is not to use a containment, but instead make a stock model that is only the area to be removed.

Keep an eye on https://www.mastercam.com/company/careers/ .

That looks awesome for the right application! I haven't checked out the documentation, but from the video it looks like a standard threadmill operation, plunge to the middle (drill), threadmill upwards climb cutting.

If you shoot over the file, I'd be happy to take a look at it and see if it reproduces on my system, or send it into [email protected] if there's a repeatable problem. I've currently got 5 different sessions of Mastercam open (2022-24), each one sitting at ~1-1.3Gb of RAM (depending on the file, most of the disk file sizes here are ~2-600MB) with no problem.

I'm not sure you understand what you mean when you say " it's still got dos under the hood." I certainly don't. Can you expand on that? Much like James, I've been hearing about a "DOS Kernel" for years.... "So back to the OP," do you mean the memory usage verifying a ~500mb file, or do you mean the the toolpath interface?

Sorry, I was responding to your original post that stated "Trying to verify a part and it basically stopped with Memory usage at a whopping 5,287.2 MB." Apologies if we've moved on from that. It's definitely not a complete rewrite between v9 and X, and I don't believe anyone is saying they are. Think of software more like a car, the components are modular. Sort of like how you can bolt a LS2 engine to a TR6060 transmission, as the interface is compatible. It's a lot harder to go backwards, though! The windows dialogs of the old toolpaths are still components that work fine, so it hasn't been prioritized to update them as there hasn't been new functionality added those individual toolpaths that require new interfaces as the new toolpath engines are the ones that needed interfaces to support the new features.

Well, to start, "new" Verify was written by ModuleWorks and was released starting in Mastercam X7/8, so unless they invented time machines, it'd be reeeeeaaalllll hard to have that the same as the V9 version. If they did invent time machines, it seems like a real waste of potential to be retrofitting Mastercam.... I often have parts where verification/simulation or a complete regen utilizes 24+Gb. That's what it's there for.

I got R-33833 for that one.