Sorry if I used too many words Correct that Mastercam doesn't (to my knowledge) have a way to create an arc from two tangent lines and a single contact point. Yep, I was going off of the original problem (at the top of this reply). What I'm saying is your second reply where you added the video gave the crucial constraint, at that point you've completed the puzzle. I'm guessing you'll be able to chook it fairly easily now that you've figured out how to do it. It probably hasn't come up enough for someone at CNC to take a look at it, because how often is this scenario encountered?

A bit of a shortcut in your method is that you can skip the "extend the two lines to their intersection point" when you create the circle. Just hit "i" key or AutoCursor > Intersection and choose the two lines, it'll snap to the intersection. ----------- You need 2 pieces of information to create a tangent arc. If you have those two pieces of information, you can calculate the missing 3rd, right? There's a critical piece of missing information to solving this, which is either the tangent point (on the bottom line) or the radius. Without specifying those two, there's an effectively infinite amount of possible answers. When you extend the bisecting angle lines, you're creating the restriction on the radius (1.50881301") so there's only one solution that fits the end point of the slanted line and the center point (Radius), which means you'll get a tangent point on the lower line at X0.57622467". Unfortunately, unless you have a specific reason for choosing the centerpoint you did (i.e., it's called out by the print to find the bisecting angle between these two features and create the radius centered off of that?) it's just really a random point in space that confirmation bias makes look more likely to be correct Note that Tom found the solution in solid works effectively the same way, using Constraints instead of the geometry.. If you use Mastercam's Arc Tangent > Arc One Point, you're now constraining two items: The end of the angled line and whatever tangent position is closest to that line. Mastercam will make an arc fitting with whatever radius you type into the panel. You can make a Arc Tangent > Arc Two Entities, which will do exactly what fillet would do, (in the background) it'll extend the angled line to the intersection and fit an arc of 1" (or whatever you specify). ----------- Basically, you're not asking the right question. For two lines of N angle, you can ask: What radius fits between these lines? Any of them, pretty much. What radius is a fillet? How many windows are in a house? If I give you a point and a line, what radius fits between those two? Any of 'em > the distance between the closest point to line. See above. If I give you a radius, where does that fit from this point to a tangent point on this line? THERE YOU GO! That's the right one ----------- I can't imagine that any CAD/CAM system can give you what you're asking for, as you're not giving complete information.

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