I'm pretty sure that if someone were to dig into this file's history they would find that it was not created with a legit seat.

I'm not sure displaying the view ID number (v_idn) is helpful. I think the work offset (woff_n) is what you're after. Aside from that, you're doing more work than you need to. If you use an unordered_set as the container you won't need to check for duplicates. You could also sort and uniquify your vector after adding the data to it. Examples of both techniques on repl.it

My tool axis control is set to 5-axis. I tipped the part 25 degrees and still got numbers I would except. Ref. Z position (Abs.) : 54.378467 Selected Z position (Abs.) : 45.315389 TOS Z position (Abs.) : 45.315389 Depth Z position (Abs.) : 18.126156 Ref. Z position (Inc.) : 10. Sum of drl_ref_z$ and drl_sel_ref$ : 64.378467 I don't remember this changing, but what version of Mastercam are you using? Could you share a part file? I'm curious why this is working for you.

I'm glad you got this working, but you've lost me. Adding the values as you show shouldn't generate a useful position. Consider the below hole; Yellow is the ref point, green is the selected point and top of stock, and red is the depth I setup a drilling postblock to mimic your math pdrill$ "Ref. Z position (Abs.) : ", *drl_ref_z$, e$ "Selected Z position (Abs.) : ", *drl_zdrl_z$, e$ "TOS Z position (Abs.) : ", *drl_tos_z$, e$ "Depth Z position (Abs.) : ", *drl_depth_z$, e$ *e$ "Ref. Z position (Inc.) : ", *drl_sel_ref$, e$ zrefhgt = drl_ref_z$ + drl_sel_ref$ *e$ "Sum of drl_ref_z$ and drl_sel_ref$ : ", *zrefhgt, e$ And that resulted in the following output. Ref. Z position (Abs.) : 60. Selected Z position (Abs.) : 50. TOS Z position (Abs.) : 50. Depth Z position (Abs.) : 20. Ref. Z position (Inc.) : 10. Sum of drl_ref_z$ and drl_sel_ref$ : 70. I don't understand how a value of 70mm is useful.

Do you have the post documentation? The docs the cover drl_ series of variables very well, though in my experience none of them are mapped automatically. Also the formulas don't make much sense to me; seeing as... drl_sel_ref$ is the distance from the selected point to the ref point drl_sel_tos$ is the distance from the selected point to the top of stock drl_ref_z$ is the absolute Z position of the ref point I'm not sure what you are trying to accomplish by adding them together. Also, as this is a 3+2/5-axis application you'll likely have to rotate/map the values depending on how your machine handles tilted work planes. You should contact your reseller or post developer; they will be able to get you sorted out.

As far as I’m aware there isn’t one. If you think about it how could there be. A user can select any combination of arcs or solid holes with varying diameters(points could also be used, so no diameter); they can also select as many entities as they want. If you are looking to determine the diameter of a circle mill or helix bore, this can be done mathematically in the post; but if you’re using a drill op you’re out of luck. I suppose you could also use an add-in to get this information at posting time; it just depends how badly you want the information.

Are you using Mastercam 2018 or later? If so you cannot output a metric pitch in an inch file or vice versa. The only workaround I'm aware of involves using the API to query the tool to determine if it's inch or metric. From the docs...

Not much would change in this example; this... pwrtt$ if (t$ > 0) & (gcode$ <> 1003), [ p_add_to_tool_stack ] ...would change to this... ptooltable$ if tt_count$ = 1, [ p_add_to_tool_stack ]

So I could be way off in the weeds here, but it sounds like you want to use the index position of the tool in the buffer as the diameter offset. Assuming that your buffer / tool list is non-repeating the below should work. First, I set up pwrtt$ so that a tool will only be added to the stack once no matter how many times it appears in the program. I much prefer then enhanced tool table for this, but since you mentioned pwrtt$... pwrtt$ if (t$ > 0) & (gcode$ <> 1003), [ p_add_to_tool_stack ] Next, I defined the stack and associated variables. stack_101_size : 0 stack_101_index : 0 stack_101_result : 0 stack_101_tool_number : 0 fstack 101 1 Then I created a utility postblock to add the tool to the stack p_add_to_tool_stack t$ = push(101, stack_101_result, 1) The below postblock will iterate through the stack looking for a matching tool number to the one passed in. If a match is found, it's index is set to diameter_offset and passed back by reference. If no match is found -99999 is passed back tool_number : 0 diameter_offset : 0 p_get_diameter_offset(tool_number, !diameter_offset) stack_101_index = 1 stack_101_size = pop(101, stack_101_result, 0) while stack_101_index <= stack_101_size, [ stack_101_tool_number = pop(101, stack_101_index, 5) if tool_number = stack_101_tool_number, [ diameter_offset = stack_101_index stack_101_size = -99999 ] else, diameter_offset = -99999 stack_101_index = stack_101_index + 1 ] To use this, at tool change (be it start-of-file, real, or null) do something like this psof$ ptlchg$ ptlchg0$ p_get_diameter_offset(t$, !result) That's it. If t$ exists in the list, it's index will be returned to result in this case. I hope that helps, but if not I'm sure someone more knowledgeable than I will step in.

Are you trying to uniquify the buffer? Side note, I'd consider using a stack for this. Buffers are limited, and only really make sense if you need to read or write to disk.

Implement a modulo post block in your post, something like this should get you started... modulo_result : 0 int_a : 0 int_n : 0 remainder : 0 p_modulo(int_a, int_n, !remainder) modulo_result = int_a / int_n modulo_result = int(modulo_result) modulo_result = modulo_result * int_n remainder = int_a - modulo_result Then call it passing in your spindle speed as int_a, 10 as int_n, and use any numeric value for the returning value (the remainder) p_modulo(ss$, 10, !result) If the remainder returns 0, your spindle speed is evenly divisible by ten, so it ends in zero. Here are a few test cases p_modulo(20000, 10, !result) "->", ~result, e$ //Output // -> result 0. p_modulo(123456, 10, !result) "->", ~result, e$ //Output // -> result 6. p_modulo(45000, 10, !result) "->", ~result, e$ //Output // -> result 0. p_modulo(1776, 10, !result) "->", ~result, e$ //Output // -> result 6. p_modulo(1852, 10, !result) "->", ~result, e$ //Output // -> result 2. p_modulo(105, 10, !result) "->", ~result, e$ //Output // -> result 5.

I recommend looking online for some resources about regular expressions. It’s a vast topic, and it’s not one I’m qualified to cover; but I’ll do my best to break down the key parts of the regex. Starting off we have a word boundary \b. Next we match ‘M’ literally. The open and closing parentheses define a match group. The numbers between the braces define a range of values to match. So [1-9] will match 1, 2, 3, 4, 5, 6, 7, 8, or 9. The pipe ‘|’ means or, and with the two other patterns we can range check from 101-999. Again, I really recommend Googling regular expressions; you’ll find tons of resources.

Can you provide a screen shot of what you entered in the text box? It's working for me, see below.

The above regex has some holes in it. Here is a better one... \bM([1-9][0-9][1-9]|[1-9][1-9][0-9]|[2-9][0-9][0-9])\b ...and here is the regex being tested against some common M-codes.

Give the below regex a try. \bM([1-9][0-9][1-9]|[2-9][0-9][0-9])\b

Correct(ish) you can have as many stacks as you'd like, but they exist in memory. If you want to write them to disk you must use the pop function with mode -1 Or you could use a different file stream to write the data to disk, but it's not as automatic. You should contact CNC's post department. Sort of, here is a Knowledgebase article that shows how to reuse a buffer, but as far as I'm aware you can't redefine it at runtime. Something can be done for sure, but without more detail it's hard to know what options to present.

Use a stack? But, to write a stack to a file you need a buffer so it may not work for your application. I’m not sure why stacks aren’t used more often by post developers.

This can happen when Mastercam is run as Administrator.

The docs cover this pretty well, but here is an example of both methods being used. insert_cr_pnci20000 : 0 pnci20000$ if prmcode$ = 20104, [ insert_cr_pnci20000 = rparsngl(sparameter$, 4) ] insert_cr_opinfo : 0 lsof$ sparameter$ = opinfo(20104, 0) insert_cr_opinfo = rparsngl(sparameter$, 4) ~insert_cr_opinfo, e$ ~insert_cr_pnci20000, e$ #// Output -> #// insert_cr_opinfo .03125 #// insert_cr_pnci20000 .03125 On thing to note; pnci20000$ will not run if the pparameter$ postblock is present in the post.

pnci20000$ is the preferred way to access the 20xxx and 30xxx range of parameters with the enhanced tool table. You can also use opinfo and parse the returned string, but that method isn’t quite as efficient.

SlaveCam got it. You need to reset the main tool to the cloned assembly for the changes to stick. void OperationService::SetToolCoolant(int opID) { auto op = TpMainOpMgr.GetMainOpList().OpByID(opID); if (op != nullptr) { auto toolSystem = Cnc::Tool::GetToolSystem(); auto toolAssembly = Cnc::Tool::TlAssemblyCPtr(); if (toolSystem->Find(op->tl.slot, toolAssembly)) { auto toolAssemblyClone = toolAssembly->Clone(); if (toolAssemblyClone->HasMainTool()) { auto millTool = toolAssemblyClone->GetMillTool(); Cnc::Tool::TlCoolant tlCool; tlCool.SetFloodState(0); tlCool.SetFloodTime(1); tlCool.SetMistState(0); tlCool.SetMistTime(1); tlCool.SetToolState(0); tlCool.SetToolTime(1); millTool->SetCannedTxtCoolant(tlCool); toolAssemblyClone->SetMainTool(millTool); toolSystem->Update(toolAssemblyClone); } } } } The TlCoolant class is much more friendly than a vector. Sadly I knew about it less than a year ago; my memory isn't what it used to be. Makes me think that there has to be a friendlier way to update the operation coolant.

Have you tested this? I had the below function for setting a tool's coolant, but no matter what I do the coolant won't stick. void OperationService::SetToolCoolant(int opID) { auto op = TpMainOpMgr.GetMainOpList().OpByID(opID); if (op != nullptr) { auto toolSystem = Cnc::Tool::GetToolSystem(); auto toolAssembly = Cnc::Tool::TlAssemblyCPtr(); if (toolSystem->Find(op->tl.slot, toolAssembly)) { if (toolAssembly->HasMainTool()) { auto millTool = toolAssembly->GetMillTool(); std::vector<short> cannedTextCoolant(20); cannedTextCoolant[0] = -3101; cannedTextCoolant[1] = -4103; cannedTextCoolant[2] = -5105; millTool->SetCannedTxtCoolant(cannedTextCoolant); toolSystem->Update(toolAssembly->Clone()); } } } } I'm also totally wrong about the right most digits. They do have something to do with on and off; new theory below. 01 and 02 sets ON and OFF for Coolant 1 03 and 04 sets ON and OFF for Coolant 2 ...skip a few... 19 and 20 sets ON and OFF for Coolant 10 So to set Coolant 5 to ON and Before, use -3109.

Are you trying to modify the operation's coolant? If so, new style coolant is handled by canned text... void OperationService::SetOperationCoolant(int opID) { auto op = TpMainOpMgr.GetMainOpList().OpByID(opID); if (op != nullptr) { op->cantxt.cantxt[0] = -3101; op->cantxt.cantxt[1] = -4103; op->cantxt.cantxt[2] = -5105; DB_LIST_ENT_PTR dbPointer = nullptr; auto isSuccess = false; operation_manager( op, OPMGR_REWRITE, &dbPointer, &isSuccess); } } The values are a bit of a mystery to me but as far as I can tell... The left most digit will be a 3,4, or 5 corresponding to before, with, after The two right most digits are the coolant; 00 is coolant 1 off, 01 is coolant 1 on, 02 is coolant 2 off, 03 is coolant 2 on etc. For example, -5105 would mean coolant 3 on, after.

Yes. Here you are.

Yes, you can pass a struct, see below File: OperationService.h #pragma once namespace OperationServiceNative { public value struct OperationData { System::String^ Comment; int ID; int Type; int ToolNumber; }; public ref class OperationService { public: OperationService(); OperationData^ GetOperationData(int opID); bool CreateOperation(OperationData% opData); ~OperationService(); }; } File: OperationService.cpp #include "pch.h" #include "OperationService.h" OperationServiceNative::OperationService::OperationService() { } OperationServiceNative::OperationData^ OperationServiceNative::OperationService::GetOperationData(int opID) { OperationData^ opData = nullptr; auto operation = TpMainOpMgr.GetMainOpList().OpByID(opID); if (operation != nullptr) { opData = gcnew OperationData(); System::String^ commentString = gcnew System::String(operation->comment); opData->Comment = commentString; opData->ID = operation->op_idn; opData->Type = operation->opcode; opData->ToolNumber = operation->tl.tlno; } return opData; } bool OperationServiceNative::OperationService::CreateOperation(OperationData% opData) { //Code to create an operation with the OperationData struct return false; } OperationServiceNative::OperationService::~OperationService() { } File: Main.cs namespace MyNetHook { using Mastercam.App; using Mastercam.App.Types; using OperationServiceNative; public class Main : NetHook3App { public override MCamReturn Run(int param) { var opService = new OperationService(); var opData = (OperationData)opService.GetOperationData(1); var newOpData = new OperationData() { Comment = "A new op", ID = 2, Type = 1, ToolNumber = 1 }; var isSuccess = opService.CreateOperation(ref opData); return MCamReturn.NoErrors; } } }