No, chamfer drill cannot produce a canned cycle.

I’m riffing this (I don’t have access to a PC till next week), so I expect it to be about 80% correct. Get the next tool number using opinfo, if you want the next operation, use a 1 for the number of ops to look ahead. Compare that to the current tool number, if they are equal (or the next tool number is -99999) do nothing. If the next tool number is different than the current tool number (and not -99999), get the next tool’s description and output it. You always want to look ahead to the next operation, and there is no easy license plate setting to get the next operations parameter if the tool changed.

The tt_ variables are only numeric if I recall correctly. The opinfo function is the way to go here.

You don’t need a buffer. Search the documentation for opinfo, you can query the next operations tool description easily.

You do not need the op_id$ in this case; your only concern is how many operations are between the current operation and the next physical tool change. In the below example, I set up a postblock to populate the s_next_20002 variable; p_get__s_next_20002. This postblock takes one parameter by reference and loops through the upcoming operations looking for the next physical tool change. Once the next physical tool change has been found, the lookahead_index variable contains the number of operations needed to look ahead for the next 20002. The parameter p_get__s_next_20002 modifies is a bool telling the caller if a valid 20002 was found or not. This is as much as I can help; your reseller and the official forums are great resources if you have follow up questions. Implementation example: lookahead_index : 0 next_tool_change_gcode : 0 invalid := -99999 s_next_20002 : "" s_invalid := "-99999" is_valid_arg : no$ p_get__s_next_20002(!is_valid_arg) lookahead_index = 1 next_tool_change_gcode = opinfo(92, lookahead_index) while next_tool_change_gcode <> invalid, [ if next_tool_change_gcode = 1002, [ next_tool_change_gcode = invalid ] else, [ lookahead_index = lookahead_index + 1 next_tool_change_gcode = opinfo(92, lookahead_index) ] ] s_next_20002 = opinfo(20002, lookahead_index) is_valid_arg = (s_next_20002 <> s_invalid) Calling example: psof$ #Start of file for non-zero tool number p_get__s_next_20002(!result) if result, "Next 20002->", s_next_20002, e$ ptlchg$ #Tool change p_get__s_next_20002(!result) if result, "Next 20002->", s_next_20002, e$ Output Example: ( T1 | 0.5 FLAT ENDMILL | H1 ) ( T239 | 1/2 FLAT ENDMILL | H239 ) Next 20002-> Tool code 2 N100 G20 N110 G0 G17 G40 G49 G80 G90 ( FINISH OUTER WALLS ) N120 M8 N130 T1 M6 ... N280 G91 G28 Z0. N290 A0. Next 20002-> Tool code 1 N300 M01 ( CONTOUR 2 ) N310 T239 M6 N320 G0 G90 G17 G56 X-2.8424 Y-.789 A0. S1069 M3 N330 G43 H239 Z.25 ... N570 G91 G28 Z0. N580 A0. N590 M01 ( MANUAL ENTRY TEXT COMMENT ) ( FINISH OUTER WALLS ) N600 M8 N610 T1 M6 N620 G0 G90 G17 G56 X-2.8424 Y-.789 A0. S15000 M3

That’s far too much for what you want to do. Create a loop to look for the next tool, and keep track of how far forward you looked for it. Then use that as your look ahead to grab the next tool’s 20002.

The 20002 data is only written to the NCI when there is a physical tool change. Post this on the official forum so someone from CNC’s post team can have a look.

At this point it really is a proof of concept; I had a few hours last weekend so I decided to take a whack at it.

Can you use json or xml, or do you need a csv? For fun, I took a quick look at exporting a csv this weekend (importing from a csv doesn’t seem practical), and this proof of concept is what I came up with.

If you only want to extract information and you're using Mastercam 2022 a script can do this. You'd want more information, but here is an example. #r "C:\Program Files\Mastercam 2022\Mastercam\ToolNetApi.dll" using System.IO; using System.Linq; using Cnc.Tool.Interop; var filePath = Path.ChangeExtension(FileManager.CurrentFileName, ".csv"); var tlMgr = TlServices.GetTlMgr(); var isHeaderWritten = false; using (var writer = new StreamWriter(filePath)) { foreach (var tlAssembly in tlMgr.GetAssemblies() .Where(t => t.GetMillTool() != null)) { if (!isHeaderWritten) { var header = $"TOOL NUMBER, " + $"OVERALL DIAMETER, " + $"OVERALL LENGTH, " + $"NAME"; writer.WriteLine(header); isHeaderWritten = true; } var millTool = tlAssembly.GetMillTool(); var outputToolData = $"{millTool.ToolNumber}, " + $"{millTool.OverallDiameter}, " + $"{millTool.OverallLength}, " + $"\"{millTool.Name}\""; writer.WriteLine(outputToolData); } }

Ok I’m taking a shot in the dark without knowing how the data is represented, but this may get you started. In order to move the positions between coordinate systems you need move the point to world, then move the point to the new system. This can done by multiplying the point through the inverse (same as the transpose if the matrix is orthonormal) of the original coordinate system’s matrix (that will put the point in world; X=1,0,0; Y=0,1,0; Z=0,0,1), then multiply the point in world through the new matrix to put it in that space. It sounds like the new matrix will be a rotation matrix based on the machines angles, but again; this is a shot in the dark. Hope that helps get you going.

I know enough to be dangerous, but I don’t understand what you are trying to do. Can you provide an example?

Correct. I’m not sure what the original intent of this setting was; but I don’t think it’s done anything in recent releases. In Mastercam 2022 it has been removed.

It counts all tool changes, not just the physical ones. A stack is my preferred method for tracking the number of times a tool has been used.

Segment length / radius should give you the angle in radians. The file you uploaded has 40.365 degrees between the close holes; my math lands at 39.4261degrees. 1.18699992 / 1.725 = 0.6881158956521739 radians or 39.4261366 degrees. I used the roll function to confirm, what am I missing?