Here is what likely happened: You were in a hurry, and had your file (with fixture geometry) open. You saved the file (or thought you did), and go to open a different Mastercam file. As you go to open the new file, Mastercam prompts you to tell you "your current file has changed, do you want to save it", and opens a 'save as' dialog box, in the middle of you selecting a different file to open. You basically end up overwriting your existing file, with a different file you are opening. The solution is to get in the habit of always 'saving your current file', then pressing 'File > New'. Always use File New, before File Open. This will save you aggravation in the long run. It won't, however, fix your current situation. Sounds like you should follow G-code's advice about the separate backup directory as well.

Here is what likely happened: You were in a hurry, and had your file (with fixture geometry) open. You saved the file (or thought you did), and go to open a different Mastercam file. As you go to open the new file, Mastercam prompts you to tell you "your current file has changed, do you want to save it", and opens a 'save as' dialog box, in the middle of you selecting a different file to open. You basically end up overwriting your existing file, with a different file you are opening. The solution is to get in the habit of always 'saving your current file', then pressing 'File > New'. Always use File New, before File Open. This will save you aggravation in the long run. It won't, however, fix your current situation. Sounds like you should follow G-code's advice about the separate backup directory as well.

This is basically what I was going to say before Sticky beat me to it. Rough/Finish electrodes, and be done with it. And yes, drilling Inconel, especially 718, is terrible.

As long as the Rotary Direction and Rotary Axis variables are set correctly, and the Machine Base Matrix is setup correctly, then the likely culprit would be the way you have your Planes setup inside Mastercam. For A(C) on B, you should have something like: #Primary axis angle description (in machine base terms) #With nutating (mtype 3-5) the nutating axis must be the XY plane rotaxis1$ = vecy #Zero rotdir1$ = -vecx #Direction #Secondary axis angle description (in machine base terms) #With nutating (mtype 3-5) the nutating axis and this plane normal #are aligned to calculate the secondary angle rotaxis2$ = vecz #Zero rotdir2$ = -vecx #Direction If you look at the Primary values (vecy and vecx), you'll notice there is no "Z" in the plane being described. This means rotation happens "Around Z" (as it should, regardless of what you label the axis address letter.) If you look at the Secondary values (vecz and vecx), you'll notice there is no "Y" in the plane being described. This means rotation happens "Around Y" for the secondary. And should be labeled "B". If the rotations happen "Backwards", in other words, you are getting "-90.", instead of "90.", all you should have to do is reverse the "sign" of the RotDir variables. (add a minus sign, or remove the minus sign. That's it.) 'mtype' should be set to '0.' Also, and this is important(!), make sure these are both set to Zero, when you are setting up the rotation angles in the Post: pang_output : 0 #Angle output options, primary sang_output : 0 #Angle output options, secondary #0 = Normal angle output #1 = Signed absolute output, 0 - 360 #2 = Implied shortest direction absolute output, 0 - 360

Did you change the Machine Base Matrix? For a Horizontal, it should be: #Machine base matrix (Base matrix to map positions into) matb1$ : 1 matb2$ : 0 matb3$ : 0 matb4$ : 0 matb5$ : 0 matb6$ : 1 matb7$ : 0 matb8$ : -1 matb9$ : 0 WCS should be set to TOP, and A/B Zero should be FRONT tool plane. What is your actual Rotary Configuration? (Kinematically, how are the rotary axes mounted on the machine? Is "A" the primary (platter, perpendicular with Spindle?), and "B" the Secondary? (B Rotates about Machine Y, while A Rotates around Machine Z)

I mean, that's only 13:1, Depth to Diameter, on the finished feature. Piece of cake, right? That would be a difficult slot, in Aluminum. In Inconel 718? oof... I'm with Peter, I would drill out as much of that material as possible, without letting the holes intersect. Then I'd look at getting a .047 diameter endmill, from Harvey Tool, and have them relieve the neck. I would get at least 3 different lengths of tools to finish the slot. If you try to go with a single "length" to rough and finish, you'll be there for days. I'd go with a 5X (.250 to shoulder), and a 10x (.480 to shoulder), and get an additional 10x cutter, that is ground back to .658 to the shoulder. ( 14:1, D2D, on a .047 endmill) I'd look to finish with at least a couple different lengths of tool. For the bottom of the slot, I'd try a 1 mm diameter, with 1 mm length of cut, and 17:1 D2D. You could try something like a 1.25 mm diameter (.051), and try to interpolate a slot that is .0004-.0008 wide, to stay under your .055 width tolerance, but what a pain. You'd be far better served by drilling out as much material as possible, and just sending it off to get burnt out on the EDM. As slow as EDM is, you will get the part finished much faster than trying to dial in a slotting process with multiple tools that are extended way beyond the practical limit.

Add an extra numeric variable to your Buffer File. During "data capture", when you are filling the buffer, add the value of Parameter 15240 - Mastercam Operation Number. The other option, if you tend to use Transform Operations, is to capture 2 different variable (NCI variable) values: op_id$ - Unique (integer) value, representing "operation data tag". Will be a unique number, that only repeats during Null Tool Changes, for the same Operation. (So "Contour #10, might have 'op_id$': '55'. This would still be '55.' for every Depth Cut, and/or Multi-Pass. The value will only change when you process a "new" operation from the Toolpath Manager.) xform_op_id$ - Parameter #17 from the NCI Gcode 1016 Line. This is the 'parent' op_id$ of the Transform Operation itself. (So if you are processing a Transform, you can key on "are we still processing the same Transform Op, or not"?)

if tool_op$ = 3 | tool_op$ = 5 | tool_op$ = 37 | tool_op$ = 201, [ # do something] ] else, [ # do something else ] If you want more "types", just add a condition 'tool_op$ = xxx |' (notice the pipe symbol is the OR condition.

The variable 'op_id$', will only contain a unique Integer value, which acts as a 'creation ID', but there is no guarantee the value is in sequential numeric order. The values get jumbled every copy/paste. I would use 'opcode$', or 'tool_op$', if you want to allow or disallow Toolpath types.

if IncAbsOperationDepth = 1 & opcode$ <2, [if mprint(sIncAbsOperationDepth, 2) = 2, exitpost$] opcode$ <2 Your 'opcode$ is equal to 1 or 2 , when processing a contour. ( 1 = 2D Contour, 2 = 3D Contour)

What machine? On mills: G84 is output (by default) for tapping, when you select the "Tap" cycle in the "drill parameters" page. G84 typically uses a "floating tap head", which allows a tiny bit of axial "float". This is used when the machine reverses the spindle at the bottom of the hole. More modern machines use a function called "Rigid Tapping", where the spindle rotation uses an encoder (and orients, typically with M19) to track the rotation position of the spindle, and the machine synchronizes the Z-Axis motion, so that it will tap successfully with a rigidly mounted tap. Many machines will have different codes to indicate "rigid tapping" vs. "non-rigid tapping". For example, G84 for non-rigid (standard), or G84.2 for Rigid Tap. Some machines have the same "G84" canned cycle call, but precede the G84 G-Code line, with M29 and the Spindle Speed for the tap. For example: M29 S350 In all cases, you must synchronize the Spindle Speed (RPM) with the Feed value. However, there are two ways to do this: Your machine can be in Feed per minute (Inches per Minute on an Inch Machine [G20], or Millimeters per Minute on a Metric machine [G21]). Feed per minute is typically indicated with G94. When you are in Feed per minute mode, the Feed value will always be: Thread Pitch x RPM. The calculation for Thread Pitch is 1 / # of Thread Per Inch. If you are in Feed per Revolution mode, then your "Feed value" may be specified as "E", instead of "F", or it may remain "F", but the value will always "equal the pitch of the thread". Because you are in G95 mode, you get better ability to adjust the actual cutting speed, because all you are doing is modifying the RPM value. Since RPM is always an integer value on machines, Feed per Revolution gives you the easiest ability to adjust to a "true pitch" value. Be careful when using Feed per Minute, as you can pick combinations of Feed and RPM, where the Feed value is "rounded or truncated", because the number of digits of precision allows for the "F" value, is not precise enough to give an accurate feed value. Example: Pitch of .08333333, where the F value is rounded to 3 decimal places (.083) is not an accurate pitch value. Where possible, I increase the F output to 4, 5, or even 6 decimal places, if the machine allows it.

Quick Answer: Kind of. I know that is a crappy answer, so allow me to "sum up" what's going on. The Mastercam 5-Axis Posts, in all their glory (and they do quite a bit), are not "kinematically aware" of how your machine's axes are stacked on top of each other, nor how the machine is physically built. All of the "rotation" is pure mathematics at work, which includes the Rotary Travel Limits. All of the math at work is Vector and Matrix Math (Linear Algebra). With the way the math works out, a curious thing happens when the Secondary Axis is at Zero Degrees. When this happens on a trunnion machine (the platter is sitting "perpendicular to the Spindle (tool) axis", we reach what is called a "Singularity". In this case, literally any 'Primary Rotary Axis Angle' will work to keep the "tool vector vertical". ---------------------- To back up a tiny bit - if you look at the NCI output from Mastercam, all Tool Motion is either "tool plane based" or "vector based". There are zero Rotary Axis Positions output in the NCI Data. So this means all Toolplane based motion is relative to the "plane" that it was created on, and the 5-Axis Post must use the "Z-Axis Vector of the Toolplane Matrix" to calculate the Rotary Angle output. ---------------------- So what is happening is the Post is actually doing the "Secondary Axis Rotation Calculation", 1st. Then it "checks" the Tool Axis value, to see if it is aligned (within a tolerance) to the Machine Base Matrix. Since "any Primary angle" will work, the post just uses the last "B-Axis angle", and recalculates the XYZ positions, to account for that rotary value. ---------------------- The solution is basically this: You have to use "Force Tool Change" switch, so that the "new Operation" flags the post, to tell it to call 'pretract'. (Null Tool Changed don't call 'pretract') Inside 'pretract' there is some code (protretinc) that looks to "return the Rotaries to Zero", but only if the "Force C-Axis Initialize" switch (frc_init) is enabled. So you have to have 'frc_cinit' enabled, and throw the 'Force Toolchange' switch in the individual Operation. ------------------------ That's what exists "by default" in the Generic Fanuc 5-Axis Mill Post. But... There are also some additional features that are built into the 5-Axis Post, which allow us to control certain output. These are set by the Miscellaneous Values variables, at the Operation Level. We have 10 Misc. Integers, and 10 "Decimal (Real) Numbers". These integers and decimal numbers allow us to "pass data" to the Post, and have the Post "do things" based on these values. The important ones (in this case) are: MI4 and MI5. Misc. Integer #4 is the "Primary Bias" switch. Misc. Integer #5 is the "Secondary Bias" switch. Both of these Integers allow you to pass an integer value to the Post, and have the Post "attempt to Bias the rotary" to whatever value you enter. These are typically used to "pre-wind" the head on a Gantry Mill or Router, but can be used to control a specific rotary position in many cases. By Default - It is not read for Null Tool Changes. You have to enable it with the Variable: 'bias_null'. (bias_null = yes$) Once 'bias_null' is enabled, you can enter a Primary or Secondary value, but... '0' (zero) is basically "Off". So I would suggest trying "360" to see if that will keep your Primary at 0. or 360. (same position mathematically...) Other important MI values (just not for this particular case) are: MI6 = Output from Center of Rotation (WCS Zero), or Toolplane Zero (allows the use of multiple Work Offsets, but not for Vector Based Paths, "toolplane only"). MI7 = Global "on/off" switch for "retract behavior". Actual "retract behavior" is controlled by a combination of 'MI8', and in certain cases MR6 and "stock type" settings. MI8 = Auto Generate "retract and approach" motion. (explained more below) MI9 = "Temporary Secondary Axis Rotary Limit Restriction" for Vector-Based (5-Axis) Toolpaths (only) MI10 = "Temporary Secondary Axis Rotary Limit Restriction" for Toolplane (3-Axis) Toolpaths (only) I think "MI10" is one of the most useful, as it allows you to "temporarily" restrict your Secondary Axis Travel Limits, to either "positive only" or "negative only". This is typically used on machines with a larger "secondary axis travel", to keep the Secondary either Positive or Negative. This is most often used on Trunnion machines to keep the platter "towards the operator", when the secondary has the ability to go +-90 (at least). For example, you might want to keep it "A-90." for all Ops. The "approach and retract" behavior is based on a function in the Post which allows you to define a "Safety box" around your part. This was often used for Gantry style machines, so you can make a cut on one side of the part, and only enter (for example) a 2" approach and retract from the feature you are cutting. Then use a similar approach/retract on the next toolpath, on the other side of the part. Internally (and based on the values of MI7, MI8, 'use_stock_typ', and 'clear_stck'), the Post will then add moves to "retract the tip of the tool towards the boundary (either defined with upper/lower XYZ values inside the Post), or based on your Stock Definition (method I use!!!), the tool will then go "over the top" of the box, then rotate to the new position, and finally will approach the new cut from the safe transition position. If that wasn't confusing enough, there is also the "MR6" (Safe Retract in Z) option. This is basically only used on Trunnion style machines, but it is what your coworker is probably using. MI8 acts as the "when do we generate a Retract/Approach move" switch. There are 5 different options (0-4), plus there is an option to "sign the value negative", which does something, but I honestly never dug deep enough to figure out what the "signing the value negative" actually does. Sorry for the long-winded answer, but I always try to err on the side of "more knowledge of how the system works" allows you to make more informed choices about which path to take.

This might be of help...

I get what you are saying Tyler. Something about the Migration Wizard will define the file paths in that list "automatically" during the update process. I have no idea where or how that file list is stored. For anyone who doesn't see their updated files in the list, you must manually "browse" to those machines, using the Manage List... function. When you select 'Manage List...' the 'Machine Definition Menu Management' dialog box appears. By default, it will point to 'C:\Users\Public\Documents\shared Mcam2020\CNC_Machines\'. (Where 'shared Mcam2020' represents "the current Mastercam version's 'shared folder'.) If your machines are located in a different folder, you must browse manually to that location by pressing the 'folder tree icon' button in the upper left corner of the dialog. When pointed to the correct folder, you must then select each machine in the list ( CTRL + Click, OR, SHIFT + Click to select a range of machines!), and press the "Add" button. That adds each machine to the list, so that you can then select each machine.

The culprit is probably 'protretinc'. This Post Block uses this switch: 'frc_cinit' (force 'c' initialize), as a 'global switch' to force out the 'Rotary Zero' calls. Try turning off 'frc_cinit'. frc_cinit : no$ #Force Rotary Zero at Tool Change? The comment after the 'yes$' might say something different, but it is the same switch. Also, it might have a '1' instead of 'yes$'. They are functionally the same. So use a '0/1' or a 'no$/yes$' value to indicate if the function if off or on.