That's not really a concern. The collision detection only works to tilt the tool. Actual motion (the fact that this will cause the B to tilt) is only really a function of the post & machine definition. The part itself is stationary from the toolpath calculation side, which is why when you backplot it (not machine sim!), it shows the tool tilting. If you have the A Axis setup modelled, you can simply select it as part of the Collision Control > Avoidance Geometries selection and it'll be fine.

Took a quick look and it seemed easier to make a video than to write it all out (plus, I'm pretty much out of space to upload pictures and files!), hope that's okay:

I haven't heard of 'em.. Their aircraft wing/surface panel tech looks really cool!

Right, but that would be the 2022_12 release since Mastercam 2024 is the latest version on there This new feature isn't in my copy of that doc..

If you have google The official channel is behind a login/password, but you can often find the quarter or two previous releases posted on various CAM forums. They always do their documentation with 202x_yy, where it's the year and the quarter release. Since Mastercam always has the last of the previous year (note: This is an assumption that this is still the case), you can search for ModuleWorks End User Documentation 2023_12 to find the build that this year's Mastercam will use. I found this in a 2023_06 on a gibbs forum. edit: I will say that I couldn't find the 2023_12 with <10 minutes of googlin'. That'll be available on the Mastercam portal when 2025 is officially released. If you stumble across a link, I'd be interested

I had to search for the latest release of MW documentation: ------------------ Automatic - Contact lines are placed in a way primarily minimizing the undercut to the target geometry and secondarily minimizing the allowance to the target geometry. In case the target geometry forms a ruled surface, this strategy will try to create a toolpath with neither undercut nor allowance. In case the target geometry is no ruled surface, it will try to create the toolpath with the least undercut and allowance possible. This strategy is intended as the default, first-shot strategy. It contains a number of heuristics to create a reasonable tool axis tilting on a wide range of input geometries. Optionally, users can define tilt lines to fine tune the tool axis alignment in specific areas ----------------- Automatic(legacy) - tries to place the tool on the swarf surface in a way that minimizes the area between the contact line from the lower to the upper curve and the swarf surface. Since the swarf surface is sometimes a parametric freeform surface (with double curvature), the area is not necessarily zero. ----------------- Sounds like they improved a some of the cases where automatic choked up, but are acknowledging that it might break some other situations they couldn't test for?

For 90% of people, the CIMCO add on will be way less setup pain and get you there faster, cheaper, and easier utilizing the I+ macros already set up on the machine. For 10% of the people, I haven't seen anything else on the market give the ease of use of setting up complex logic (multiple nested If/Then/Else logic) like P+ can do. Inspection+ are the macros that ship with the probe on your machine. If you use the GoProbe app on your phone (or the Renishaw manual) to enter, say, G65P9901M2.D0.5S54. to probe a .5" bore, that's Inspection+. Productivity+ was developed by Renishaw as a stand alone program (yes, you can buy just P+, not integrated into Mastercam!). The problem was they can't trust the I+ macros to be the same everywhere, that no one edited them, and that they could support all the logic they wanted so they developed the P+ macros. You'll have two sets of macros loaded onto your machine, two sets of calibration data in the parameters, etc. P+ coming out of Mastercam will ONLY use P+ macros.

I don't have a file handy, but did you make wireframe around your cylinder, use UnWrap on it to get a flat pattern, toolpath that and then just use Axis Sub inside of the toolpath?

Like all good answers It depends... It appears that for everything other than simple parts, there's still a lot less overall time invested in getting a CAM program to output the code, it's just that I haven't talked to anyone who figured out a way to take out the manual fiddly part of it (all the syncing and labels/comments). It's more that on the syncing part, CAM doesn't really offer much of an advantage. It still offers the normal advantages everywhere else.

I'm not trying to give anyone the run around or make excuses.... I'm just trying to help some guys out on the forum using past connections if I can. I'm just a dude, playing the dude, disguised as some other dude My synopsis was just for everyone playing along at home to understand the environment. There's a lot of peeps here on the forum that I know are always curious what the actual problem is. I was trying to help everyone understand. If I didn't do a good job of that, I apologize. Collision control is all $P_WORKAREA_CS_ variables, cycle shapes just need a few special characters to open in the graphics menu. I believe this is all working fine. Syncs aren't magic either, they just aren't the same as an M-code. INIT,START,WAITM,SETM and CLEARM - took an m$, buffer and a pretty short post block to sort out. The syncs come out perfectly fine. The whole system works okay. It's just tedious because you have to manually set the syncs on each toolpath. Just like your MI$ solution (only syncs happen in the Code Expert window on an MT environment, but basically the same thing). On a "normal" machine, you don't have to to do that. After you sync, the machine will chill there until given an additional command. It appears on these machines that each operation requires a sync whether it's objectively "required" or not. That's means there's a lot of alignment PITA to manually sync everything. If you've figured out a set of rules that allows auto-syncing without manual intervention and a set of labels that can be auto applied, that's what appears to be missing from the puzzle.

I've been around some of 'em in a low-end job shop. The newer ones I've seen looked like normal quality imported machines, consider them a store-brand version of a lot of your better advertised flavors. The older stuff used a lot of proprietary control parts (think of them as a competitor to someone like Centroid), but they've mostly discontinued that line and focused on being a integrator/machine tool sales channel with Siemens or Fanuc controls. I wasn't terribly impressed by the old lathe control software, but those machines were quite old and it survived a while which is worth something. Those controls are no longer available but Fryer still seemed interested in servicing them, so that was nice to see. The Siemens integration version seemed well done from Fryer's side. The mills themselves were pieces of crap, but it was also ordered to be the absolute cheapest bottom-of-the-barrel vertical mills you can imagine with absolutely no maintenance done on it ever, so, ya know, I'm not really blaming fryer on that one. I'd imagine the linear rail versions are as fine as any other Taiwanese imported iron (it's hard to screw up linear rail machines), and if you get the box way machines plan on doing normal box maintenance to keep 'em in that <.003" range. I've never been around one of their 5 axis integrations, however, and as we all know with a Siemens or Fanuc, 100% of your results depends on your integrator and how well they set up the parameters.

I've been having some conversations on the side, and I think I have a fairly complete picture of the situation now, at least. I'm putting this out here so that everyone playing along at home can understand the problem as I see it. It seems like the problem lies in disconnect between workflows using a Structured Language output (not the standard ISO/G-Code) using a CAM system (Mastercam/Partmaker/etc.), vs. the onboard programming language, and how they get the end goal. From talking to a few people, it seems like all of the structured code itself coming out of Mastercam is correct. It's all the stuff around it that's a problem and it really makes it tedious to get running. DMG wants everything ran on the machine in structured format, which is apparently really good at what it does. It will wrap up all of the kinematics into it, so collision avoidance, easy edits at the control, etc. are all enveloped in this which makes it way safer for the operator and way easier for the DMG techs to help with. The downsides are a lot of the things we take for granted in the ISO/G-Code world (i.e., only needing a sync if you specifically call it out) don't apply. Being Das German, ya, there are rules and structures that exist for the sake of rules and structures existing One problem here is that there are very few DMG techs who are familiar enough with the machines and can really help diagnose issues that are related to structure/workflow. Once you leave their conversational programming world, you're in uncharted waters as far as they're concerned. ------------------- The main problem talked about in this thread seems to be related to the "weird" syncing that you have to do in Mastercam MT environment (and, it sounds like Part Maker/Esprit/(possibly?)SolidCAM as well, I have limited experience with PM & E here), where you end up in a bunch of post-processing work manually syncing things and getting your tokens & labels set up correctly. If you were to use the onboard programming environment, then you would get things synced as you went (i.e., make a toolpath, sync it up, make the next one, sync it up). That doesn't really exist that way in Mastercam, as there's nothing to force you to sync it before moving on the next, or sometimes you can't sync yet, because you haven't made whatever it's going to sync to yet, etc. ------------------- Expanding on this last point, there's also not a good way that you can programmatically describe a solution because it's very much part dependent so you can't really even wave a magic wand and get something that's even 75% of the way there by defining a set of rules, e.g., Always sync Approach of Upper Turret before Motion of Lower Turret. That makes it a really tough nut to crack from the programming side as without those rules, it's hard to express to a programmer how to fix the issue. ------------------- So, pragmatically for now, the best way to work in this environment would be to always have the Code Expert window open, and as you work through toolpaths hit the ol' G1 button and make sure that each toolpath is synced & set up as you go. It's the same amount of effort overall, but at least you're doing it in bite sized nibbles instead of having to make the whole pie at once. If there's a set of small, discreet changes that could be made after you're up and running with that, perhaps changes to MT can be made to support it Mastercam can be given a set of "rules" to follow. I.e., All operations with Upper/Left get automatically labeled SP4 and the Lower/Right get labeled SP3? Make an option for this machine only to automatically sync all unsynced Upper channel if there is a single operation on the Lower Channel, etc. Coming up with this list would be daunting. Another option, although significantly less likely, would be to run this up the chain far enough that DMG/Mori sees a problem like this and gives them an option of turning off the requirements to have syncs where they shouldn't really be required to, or accepting that no labels are okay. Does that seem like at least a good summary? Many thanks go out to @scottm085, the "prefer to remain unnamed" customer I talked about earlier, and a few anonymous CNCers and Resellers that I talked to.

Seriously though, I have forwarded this thread on to a few people to see if I can help get those guys some support

I'd be happy to help out Rusty if he needs and I can, but I don't have any real experience flying those machines.. For some reason, whenever I call my Mastercam friends, they all say, "New number, who dis?"

Ah, okay, sounds like you're on the latest stuff, then. As Newbeeee says, be sure to work your contacts on that side! Keep them accountable

I would recommend calling into the Mastercam post department if you haven't recently. I know that there was some work done by the German resellers in collaboration with DMG/Mori on these (I saw it on LinkedIn), so they might be able to give you some updated information?

Thanks for the additional info! Again, I'm not a DMG pilot... I just helped a customer out with the Mastercam side, then handed it off, luckily I know they're quirky machines, especially with that weird canned language.

Yep. There was a few setup issues on your part (Machine Properties > Job Setup). I added a spindle toolpath for you and added the syncs. You can download my updated file here: DG-C31-TSD-S_rev_A - With Sub.zip One thing to note is that each of those Syncs need to have a comment, or it'll give you an error on posting:

I don't have a CTX handy, but I just did some MT programming for an NTX (to be honest, I'm not sure what the difference is ). When I posted out the code, it will generate a "-upper" and "-lower" version. For example, here's a file 0009 posted: Unfortunately, that's where my knowledge of 'em ends, as I never actually ran one. From what I can tell it was out being output correctly, though, the setup guy/operator I was working with seemed happy enough? If you could post a sample file (zip2go so we have the machine def), we might be able to help specifically. You may already know this, but it chooses the "stream" to output based on the individual toolpaths' "Axis Combination" selection, i.e.: So anything happening on the lower stream has to be programmed to Lower Left/Right. I've seen a lot of old school lathe guys getting into MT forget to check this, as they just set everything up to the Upper Left all their lives.

Ah, gotcha, thanks Bird! Unchecking Check Against In Process Stock (on the Collision control page).

It is supposed to, as long as you use the offset pattern type. It looks like it's not being enabled correctly? It does in 2022, at least (I had that opened already, so I checked there :)).

Undercuts only work when set to Offset instead of Dynamic Type, however, it looks like in 2024 it doesn't enable it at all. Looks like a bug to me? I'd report it to [email protected] with your file.

Also https://www.mcmaster.com

Pretty easy in Unified, so I wouldn't try harder getting it with a 3d if I had 5 axis available, but I admit that I am biased These are the only two settings you need to make it work:

This matches my settings, although I generally enable XZ & YZ arcs as well. Also, for something like this, a Flowline toolpath works great.