Yes I agree that it is being made more complicated by the design of the part. Fundamentally the entire datum structure of the part is driven from a feature that is located at B90, the part can only be held in an orientation that puts said feature at B90. Datum feature A must also align with feature B which sits 180 degrees opposite, and so the part must be machined in a single holding. Not to mention a bunch of other planes that require features as well. This is where the issue of CAM freaking out comes in. The machine has no limitation on correctly setting the part up in this way and executing it, it is merely within the CAM side where issues have arisen. The reason it must be held in such a way is because we're dealing with a near-net casting type part. If this was billet i would just slap g54 on the top of the part and create planes. We have to use the features that exist on the casting as setup. The only features that are acceptable as G54 is this datum at B90. So when it machines the first side, and tries to rotate around 180 degrees on C axis, CAM is not allowing that code to even post because it basically thinks that the tool is trying to drive straight through the table. The table in CAM is not rotated 90 degrees initially during verification and this is a rather big issue. Unfortunately I can't share any code because it isn't really a code issue necessarily and I can't post screen because of NDA As I say the solution we have works it is just completely bypassing the CAM side of things to fix the problem. This CAMplete pamphlet basically describes what I am trying to do and it is also convoluted. Also we don't have CAMplete currently. I hope I am descriptive enough and thanks! If I had my way the part wouldn't be design so annoyingly... CAMplete-TruePath-Working-With-Tilted-Probing.pdf

I wanted to post this to get some general feedback regarding a problem. Is it possible to set G54 on a tilted workplane? If you have your A or B axis at 90 degrees, can you then set your G54 with that A/B tilt and still have workable code from a CAM system? The issue I see is that CAM will rotate the part correctly in space, but the table will not show that in simulation. The software inherently expects that the table be perpendicular to Z at it's G54 origin. There are also problems posting workable code doing this. A solution has been reached but I wanted to know if others have seen this. Before you ask, yes the G54 has to be tilted Thanks

Yes I have noticed this fixing it but this definitely did not occur back in previous versions. I use ctrl+T alot in the graphics window to toggle transparency on and off. Ctrl+T in the toolpath manager toggles on and off toolpath display, which is weird.

I am the OP...I never did switch to NCSimul. There was a commenter asking aobut how I thought that NCSimul was more expensive than Vericut....we are an educational institution and the Vericut edu package was much cheaper than what NC could offer us. Anyways, Vericut is still great. I still like using it and I still trust the output in that I can feel confident my machine won't get damaged if the simulation is good. It would be nice to have a world where the post was linked to the simulation, but as it stands CAMplete is the only one who does it fully integrated. Sounds like Chipmaker says NCsimul does do post work? Would love to hear more about that.

For sure, there was another part I was doing that was "stay inside" so I will try messing around with it more. Thanks

Hi... I am having this issue wherein Automatic Chaining regions will not work no matter what the geometry looks like or anything like that. Shown below is an example of the error I receive whenever I choose "preview chains" Any ideas about this?

We finally got around to fixing this....something regarding something something something that I don;t know. Doesn't matter, the thing finally actually works.

Yes I have dipped my feet in the Post Edit water with Colin's videos and they are very good and super helpful. Also getting MPost documentation is helfpul

Good morning, I am trying to output the stock to leave values whenever there is a tool change. If stock to leave = 0 then no comment should be output. I have the place in the post to mess with but I cannot figure out how to add these parameters into the tool change comment section....because this is a Boolean statement I am not sure what to do. Any ideas? It makes sense to me to have the stock to leave values output with the tool change comment and NOT in the header as it currently is. I have tried copy pasting the "if then" logic into the ptoolcomment lines and it outputs Stock to Leave comments, but not the correct stock to leave values.

I dunno, I feel like this exact same thread gets pulled up out of the heap of ashes every single Mastercam release since I have been a part of. People freaked out when 2017 came along. In the end everyone adapted and it is arguably a better piece of software. Prove me wrong. Anywho, the main enhancements I look for when updating software is ENHANCEMENTS. If a few things get broken along the way then so be it, report them to QC and they will get resolved when they push the first update. OR be a BETA TESTER so your input is actually taken into account, I dunno, before a worldwide release of the software. I get it, things should just work and when they don't work as we expect them to then we get pissed off and say "mastercam is the worst piece ever"...but it isn't. Lets look at this objectively. Mastercam 2022 is a major release IMO and it is well worth the cost of admission to upgrade. For example, Unified Multiaxis is now my go to strategy when creating multaixis toolpaths. It just makes life easy. That is a massive efficiency gain. There might be some small niggles in the software that are frustrating or broken but not enough to make me consider going back to 2021. Same thing with Multiaxis Deburr. I no longer even bother creating a custom deburr or 5-axis chamfer toolpath because Deburr now allows me to add true fillets and chamfers. And it automates the crap out of it so that I am saving countless programming minutes by NOT having to create a morph or parallel with a custom tool axis control strategy. It just works (mostly). What else...all the massive enhancements to 3D high speed linking. All the control I have always wanted in those parameters are now there. Thank god. Makes programming those toolpaths way more effective and less air cutting. Something else I haven't even dipped my toes in but know will be huge is Automatic Chaining Regions. That one looks promising but I haven't had time to dive in yet. Even just the basic 2D Contour enhancements make it worth it to upgrade. Things like toolpath manager colors...yea they changed it finally and I think it is way better. Now the colors and icons actually mean something to me. But someone who is used to the "old style" toolpath manager might hate it but it might just take some getting used to. Anyone can find something to complain about if they look hard enough. Am I being too optimistic here? I really feel like 2022 was a very good upgrade that added a heck of a lot of functionality

THanks, I will check this out today. Either way they finally got tired of listening to my complaining about how TF is this now broken...need it for my workflow...etc so finally IT will be actually investigating instead of just throwing their arms up and saying "we have no idea". Thanks, me neither!

Possibly. My experience is likely not the same even though I store my critical files and folders on a network drive. Intranet, so it isn't like I am running through OneDrive or Google Drive services to generate the file. I do however sometimes run part files from a Google Drive. No way in heck I would want to have my config file or machine ladder files stored on GDrive for the reasons you are intimating. Getting settings to stick is hard enough without adding that massive variable. Issues? I haven't had any. I could probably change this to be a local copy now that I do 99% of my work on a single workstation and I am close to the machines now.

Theyre taking a look at it now. I forgot to mention (pretty importantly) that Vericut does work on its own, it is merely the Mastercam interface causing issue.

Basically when you try to run the interface, nothing happens. Initially it was throwing an error about the location of some system variables. We set the LSHOST variables correctly and now it does absolutely nothing when you click "run" It only happened when I moved from 2022 Mcam and Vericut 9.2. Clicking that interface run does nothign! Also on the backend IT side, they moved to a new server situation which I claim caused the issue. Of course IT geniuses say that is simply impossible even though it was working before.

Hey guys I am having trouble with teh Mastercam to Vericut interface, which is causing headaches. Our IT can't figure it out, and Vericut can't figure it out. Either way, the interface ain't playing nice. Is there any way to import Mastercam tooling data into Vericut manually, so that I don't need to build out a tool library in Vericut. Has anyone ever done this? Thanks as always.