Thanks for taking the time to let me know. It is strange in that Microsoft has all these requirements for MS certified software, and I write to those just because people want consistent behavior between applications. Why it is that the devs went to the trouble of allowing main menu config, and even pulldown menu customization, but didnt just replace the tool bar in the Ops manager is beyond stupid. It leads to breaking changes. And it is so unnecessary. How long would it take to replace that bar with a standard control- they already have the object (MFC or internally developed, whatever- they have it for the main menu etc)... Spend 2 hours to migrate this one over, and you dont have this problem of a really ugly mistake 5 pixels away from a super-common command icon. Anyway- thanks again, Ill just setup my backup strategy to every 1 minute with 200 saves deep... Silly the workarounds we have to do for a very expensive piece of software... Best, Rob

Sorry in advance if I have missed a post on this. I would like to alter the position of several toolbar buttons within the Operations Manager/Toolpaths ribbon. I don’t see any obvious way to make that happen in MC2021. By convention, most Windows applications permit control over ribbons via drag or pulldown menu. And, that exists for the main ribbon bar, but not (so far as I can tell) for the Ops manager. The reason for the need may be obvious- but if that is the case, Im not clear as to why such a simple change would not have been implemented long ago. In my environment, we tend to favor using toolpath subgroups as blocks which can be included or excluded from post. This helps for a scenario where we have different hole patterns in a generic mount plate for example. In larger projects, we may have a subgroup that handles different ornamentation (surface milling patterns), and we may have different pocketing depending on the material in use etc. I can end up in a situation where I have several toolpaths showing in determining what config Im posting, and if I want to clear them- I might do a select all and then toggle that Show/Hide toolpath button. An accidental click on the Ghost and I end up will all ops set to the same post state, and there is no undo on that command. So yea, I know I can setup an F-key/macro for the hide/show toolpaths, but Id prefer to have the option to simply move the Ghost button to the far right of the command ribbon etc. This may be possible via registry edit- Ill have a look. But if there is some direct method via the GUI- that makes it easier in case of a reinstall/update that may overwrite the registry mod etc. I hope the week is starting out well for you all- Best, Rob

Colin- When I get a bit of time, Ill setup a test as you defined. Right now im treading water with a bunch of things and the workaround re: lock at least allows me to see the output I would expect. Im doing some very fine patterning- more or less just pinstripes on subsection of an American football- large radius for the X axis curvature, and smaller radius for the Y relative to the part . The challenge is just that even a tiny error in rotary synch.backlash comp is dead obvious, since the pinstripe is shallow cut with a 3/32 ball; any inconsistency changes the width of the scallop, and since that seems to happen in a few places along the path, consistently for each pass, you see these weird patterns/shift of depth of scallop etc. Its very intolerant of error. I will have a look at the NCI though; that is quicker for me anyway, and if the output from MC is locked at 20, but the post is altering that- OK. I expect this is MC, because I have seen these biases trend, where the deltas seem higher (i.e. 20.01) near the extents of travel on the X axis vs the center of the part where I see these tiny errors. If this is just a .000x rounding error, I would not expect to see this change. I just dont understand the order of precedence in how MC generates the path. If the 'angle' definition is early in the flow, and there are other components like damping or whatever that apply later, I could see how this could happen. It seems to me impossible to have damping or other smoothing/filtering have effect if the output can just be clamped at the final phase of the process. But, the table lock thing works- so I assume this happens at or near the end of flow where it will simply clamp a value. Not clear to me how this impacts coordinated motion- if X/Y/Z are filtered and coordinated with A upstream, and then A is changed later... So maybe it is all being handled before the motion coordination logic happens, but 'angle' is upstream of 'lock' to the extent that some other factor can exist between the two... Best Rob

This does work for me. Strangely, even with the axis lock/limit set (i.e. at 70/70) I still see the NC file with the initial A position at A20.001. I may step through the post and see what the NCI is saying vs if the post is doing something unexpected. But yea, thanks for the suggestion- it does seem to work for multiaxis parallel at least. Have a great weekend everyone- thank you for the help. Best Rob

Hey guys Ive run into an annoyance with my 4th axis moving a bit in an operation where I want it fixed. The operation in question will mill a simple pattern into a shallow domed surface. Analogy would be pistol grips or knife scales, where maybe I want a pinstripe or crosshatch pattern on a shallow curved surface. The goal with the rotary is to put the work at 20deg rotated on the X axis, so that Im cutting with the side of a ball mill- and not with the tip. Im running a simple multiaxis parallel op- where I have the 4th axis set to 70 for tilt angle and 0 for rotary angle. 5th axis is locked at 0. Problem is, the post is outputting what seems to be some noise- where in 10 lines I might see A20, A20.001, A20, A20.002. This matters- since it will trigger backlash comp and I can see negative effect on the finished surface. What is puzzling to me, aside from the system not observing the 20deg rotation value defined, is that this output is never < 20, and it always reverts to 20 between non-20 values. There is no A20, A20.001, A20.003, A20. It would be A20, A20.001, A20, A20.003 etc spread over whatever- 20 lines or so. Seems to have rotational change at start, midline, and end of each pass. These things suggest to me this isnt rounding noise- but it is hard to understand why if 20.003 is a valid/required tilt to achieve some other geometrical constraint that I never see A19.997. Any idea if there is a way in multiaxis parallel to force A20 as the output? Thanks all- Rob

Hi Colin I can do that in CAD. Im not very comfortable with MCAM’s Cad functionality, so modifying the part enough to not violate NDA, while maintaining enough of the problem to be useful for an example, is outside my comfort zone within the MCAM environment. Some details, including the shape of the island in question, are uniquely identifying, and that would all have to be obfuscated. If I cant get something to work a little better than Ive got the opposing face cutting, it may well be wort the effort to build a model up which demonstrates the same core problems, and post something up so perhaps someone could have a look. For the surface, normally Im just roughing, and it doesn’t matter if there are cusps etc because the patterning (which it typically ball mill) cleans all that up. And that is why I have not encountered this problem until now- I knew there were some cusps being left from the 5x Rough, but I didn’t realize how bad they would get at the corners when I started removing more material (read: creating a tighter radius). Now it isnt just a few thousands error- it is a hundredth or two... For this particular variant, the handle is to be smooth, with a much less dense pattern applied (more like an engraving). So, Id like to get the surface close to final both to save time in hand sanding, but also to keep tolerances tighter. If Im +.001 mid body and +.01 near the 4 corners- it is difficult to sand that such that the patterning doesn’t give you away. Best

Hi Colin As always- I appreciate your insights and support here. Thanks for the clarification on the Triangular Mesh stuff. I don’t know why this is placed in the Multiaxis- though I suppose the ‘tilt’ avoidance benefits of those paths can only be realized on a 4+axis machine. For this particular project, the setup has 3 billets along the Y axis. That offsets 2 of the billets from a conventional rotary definition, since the surface cannot be defined by a radius from the axis of rotation. But I suppose I could replicate the cylinder you mention by the same offset seen with the billets, and re-use the path approach? I don’t know if the cylinder must be on the axis of rotation or if it just serves to generate vectors for the tool which are later resolved in 3D space. I have had some difficulty getting the multi-axis patterns to leave the island alone. They don’t seem to respect the idea of a check surface- at least not very precisely. Is there a particular pattern/strategy you think I might be better off applying? Flow works fairly well for the opposing handle which is absent that island- but I just have nothing but trouble trying to apply it to the example here. The Roughing Multisurf creates a very nice-looking path- but yea, it just is stuck in 5-axis mode and there is no way out of that it seems. If I can get the island to be left unscathed- really neat idea about doing an offset chain from the edges of the island top (mine is flat/parallel with the table/raw stock). I have had great luck with Project in applying textures to shapes like the handle in question- and it had not occurred to me to leverage that as a 3D fillet cleanup method for the island… Kind regards

The part is aligned lengthwise along the X axis of the machine. It is running as Top plane where the handle is parallel with the table as X/Y. The rotary allows me to do far more efficient cutting in this orientation, since most of the radius/material removal can be addressed in that orientation. Attached is a generic example of the model. The handle in this example is basically domed in one axis. In the model Im working on, there is a slight amount of radius over its length also- so it is slightly more thin at the midline of the tail as the midline of the center of the handle. As you can see in the example here, there is an island which is proud of the rest of the body. This is very similar to the island in the model here- and poses a bit of a problem. For the opposing side, there is no island, so a Flow toolpath seems to work quite well. Flow has given me a ton of problems with this island, so I was looking for an alternate pattern/strategy. And all I have tried seem to be really unhappy with this slightly domed surface in the longitudinal axis. They are all fine if this is just a pure 4-axis (i.e. a cylinder). So maybe I just need to really focus on Multiaxis Flow to try to get it to work better with the island. But it just seems like a very open surface like this with no hollows, no sharp notches etc should be very simple to toolpath. But- nope.

Hi Motor! Yea, sorry, it is tough to balance too much with not enough info for a new thread post… So the actual part is a knife handle- in 3D. It has a very shallow radius- about 5”. It has a protrusion flat/island to support a pocket clip. The op is simply to convert a 2D waterjeted blank so a shallow dome, for later texturing. There is a tiny amount of radius in the lengthwise direction- call it a 10” radius or so. This seems to be the aspect that is causing trouble. The machine is a 3-axis VMC with a 4th axis trunion oriented along the X axis. The handle being cut is oriented in the same way- to permit 4th axis work on the primary radius of the dome- The goal is to try to get the handle smooth-enough to sand, where I can live with some cusps, but not with leaving 0.01” material on the extreme corners so that the mid-body can be cut to within a few thousandths. The material is 6AL4V, so hand-sanding it sucks. Multi-axis roughing seems to work about the best of anything I can get to work. It seems to care a whole lot about the geometry of the containment boundary, which seems to like to be elevated (as with a more typical 5 axis Flow op). I don’t know what that is- perhaps it is limiting the A axis rotation and also the X/Y travel to a good average… It just seems really weird to me that there may not be a basic multi-axis surfacing routine. It seems that I should be able to just define a 3D surface, define keepouts in whatever way is required (collision geometry, chains, whatever), and then define a pattern where the cutter remains as normal/tangent to the surface as possible, without a whole lot of effort otherwise. Thanks so much for any insight you can share- Im 2 days into trying every trick I know, and it just seems all those tricks are pocket-related! Best

Hey guys Im having a heck of a time with a 4-axis surfacing path that ‘should’ be simple. The part is NDA so i cant post an image, but conceptually, in the spirit of Superbowl weekend, it is very similar to just a rectangular section of a football, 6" x 3" by about .5" thickness, which includes the laces mid-body. So, yea- I have a 3D smooth surface with an island that has fillets around it. I am just not able to find a baseline toolpath approach that works, where I can run it 4-axis with a bull endmill for clearance (speed and smoothness), and then deal with the normal cleanup of the periphery of the island later. My understanding of the Multiaxis Triangular Mesh is near zero, having little experience with it. I read several posts here which imply it is a 3axis path, so Im confused as to why it is listed under Multiaxis Pattern, and why it has options for 4-5 axis output. Regardless, even with it- just not having a lot of luck. I can get 3 axis output from it which looks wonderful- constant cusp is about a nice as you could hope for. But, the only time the output will call an A axis move is if the collision control is enabled and tilt is required to prevent a gouge at an edge of the part etc. It doesn’t cause the tool to run tangent to the surface, even when Tool Axis Control is set to 4-axis set to ‘Surface’ for its 4th-axis bias… Multiaxis Application->Roughing works reasonably well but it seems I cannot lock the 5th axis to 0, so I end up with nasty gouges as the surface (tangent) bends further and further away from the XY place. Any ideas/direction? I have not really had to deal with a 5axis surface before- but it just seems to me that if I can emulate it via 3-axis, I should be able to emulate it better with 4 axis- reducing cut time at least for that section of the part which is more or less concentric with the axis of rotation. Thanks guys! Always appreciate the help.

Yea, I had already set all feed options to ‘use inverse.’ I mentioned that in my initial post- sorry I wasn’t clear with that. But yea, I had expected that when all mill options were defined as ‘use inverse,’ that is all you should see from the post. It seems as if perhaps the MPMASTER implementation doesn’t function quite correctly in this regard, or perhaps some edit to the post in the past has caused it to not apply to certain motions, but apply to others. For now, I have just modified the controller itself to better deal with the mode changes- just tweaking some acceleration values and buffering etc, and that seems to make it able to swallow these rapidly changing modes. But if anyone comes across a solution for this- where if all Mill feed options are set to ‘use inverse’ and you still see unit/min outputs for 5-axis linear motions, Id be happy to know the trick- Thanks guys

Hey guys- Running 2017 and MPMASTER for a 4 axis machine. My controller is having some trouble swallowing a bunch of interleaved G93 and G94 lines in a complex 4 axis cut- perhaps a buffering thing- where it seems to believe some of the G93 F commands are G94 IPM feedrates- and things lurch about. Anyway, I wanted to just pin the code into G93 mode, but it seems that option isn’t fully controllable via the Control Definition for MPMASTER. If I set all options under ‘Feed/Mill’ to Use Inverse, I would expect to only see G93 output. But I still get G94s intermittently through the file- perhaps 10% of the lines in a given 4-axis op. I know that in MPMASTER there is under pfcalc a commented line which is itself commented as ‘G93 rotary / G93 linear’. And, if I enable that line, and comment out the default G93 Rotary / G94 linear, I do get only G94 output. But I also get an error message in the post process: PST LINE (3834) - The formula/boolean failed (general message), , Label has not been defined[85] And with that, a series of errors like: 09 Jan 2019 06:54:09 PM - RUN TIME -PST(3834)- The math calculation/formula has an error 09 Jan 2019 06:54:09 PM - RUN TIME -PST(3847)- The math calculation/formula has an error Line 3834 is the as-stock logic: if not(use_frinv) & (abs(fmtrnd(cabs)-prvcabs) <= 0.001 | index | not(rot_feed) | opcode = 3), pfcalc_u_min # G93 rotary / G93 linear So, I don’t quite know what is going on. The output appears to be valid, but its hard to know is the math calculations warning is real (and yielding invalid output), or just some oversensitive whatever. Any ideas on how to pin the post into G93 mode for this type of file? As always- thanks guys- very grateful for your insight.

Hi Jeff That seems to work well- at least on a couple of basic trials. Thank you so much for this. Im not a C++ guy, but at least I have the source now so i can browse though it and see how the calls work, in the case I need to do something a little more strange (i.e. elliptical stuff- not sure if that can be called programmatically, I assume so). Again- thank you- huge time saver for me. I hope others can find application for it also- Best

Hi Jeff Yes- that is correct. So for any value < 100% and greater than 0%, you have a decreasing incremental change in radius increase per instance. For >100%, you have the existing scale function. Im very sorry to have been so delayed in response- had some other things come up which kept me sidetracked a couple weeks. But yea- if you can implement this approach, it will yield a capability that I dont believe can be forced via any native function, and it would be very helpful for pattern generation. And, it would save people like me who are looking to do patterns/texturing natively a ton of time. Maybe the programmers will at some point include a dialog box to permit this capability in the existing scale function- Best regards-

Hi Aaron I doubt it is a linking setting I control- not only have I tried basically every variant, but they are all conservative (i.e. all in testing were set to retract to rapid distance for any gap etc). And, the fact that it works for 98% of the 50 splines that define the pattern suggests to me there is something awry. I did find that changing (removing) the 3D/2D containment did often help, but not always. For my application, the goal is just to be able to define any sort of winding river type pattern of lines along a handle- where the inter-line gap is not fixed (i.e. it might expand out- as with a river flaring at a corner, etc). At present, the pattern is defined by 2 splines and a surface in a single plane parallel to the top plane- connected by a loft, which then serves as a surface for a wireframe->Curves->Curve Flowline path, with 50 curves defined. That is then the pattern for a Project Curves path onto a 3D surface (a surface created in MC as a create-from-solid from the imported solid- to make sure this was all native geometry). I suspect this has something to do with the body geometry being a shallow dome, where the system determines that even a ballnose will have more engagement on the right/climb side if the body is sloping upwards on the right side of the cutter, I notice that the toolpathing is always +X to -X on the near side, and -X to +X on the far side, and that midline it zigzags. This seems to be related to the probem, because the drag tends to be related to this segmentation along the Y axis (3 regions). That is, the origin always seems to be at a transition of these regions on the -X side of the body, and exits at some max or min Y position mid X along the body. I dont know if there is a way to just force the toolpath to always move from +X to -X for each curve in the sequence. I cant seem to force this, even by screwing around with the direction or side of the chans in the chain manager... Any idea on if this is possible to implement in 2017? Ill look at parallel, but I dont know if that allows me to apply a pattern which has a source component which fans outside the physical body to be cut... Regards