I don't think that's correct. The post writer should be able to read that checkbox and produce a warning/error based on it's state with any comp type.

Yeah, that won't work. The OffsetChain2D method returns the offset chain and you're not using the returned value. Once you get the returned (offset) chain, you'll still need to use the ChainManager to get the geometry in the chain, then commit each entity in the chain. Below is a working example, hope it helps! namespace OffsetExample { using Mastercam.App; using Mastercam.App.Types; using Mastercam.Database; using Mastercam.Database.Types; public class Main : NetHook3App { public override MCamReturn Run(int param) { var selectedChain = ChainManager.GetOneChain("Select a Chain"); var offsetChain = selectedChain.OffsetChain2D(OffsetSideType.Left, .245, OffsetRollCornerType.None, .5, false, .005, false); var offsetGeometry = ChainManager.GetGeometryInChain(offsetChain); foreach (var entity in offsetGeometry) { entity.Commit(); } return MCamReturn.NoErrors; } } }

Can you upload a snippet of your code? Also, what version of Mastercam are you using?

Have you tried the OffsetChain2D method in the Chain class? The chain class is in the Mastercam.Database namespace.

You've probably figured this out already, but the tool description isn't available to MP. The only way I know how to get the description into the posted code is to create a Net-Hook and call it from the post.

You can use a NET-Hook to do this, below is a basic example. The NET-HOOK - namespace QueryViews { using System.Linq; using Mastercam.App; using Mastercam.App.Types; using Mastercam.Posting; using Mastercam.Posting.Types; using Mastercam.Support; using Mastercam.Database; public class Main : NetHook3App { #region Public Override Methods /// <summary> The main entry point for your QueryViews. </summary> /// /// <param name="param"> System parameter. </param> /// /// <returns> A <c>MCamReturn</c> return type representing the outcome of your NetHook application. </returns> public override MCamReturn Run(int param) { var postArguments = GetPostArguments(); var view = GetView(postArguments.Argument1); if (view != null) { SetPostArguments(view.WorkOffsetNumber.ToString(), view.ViewID.ToString(), view.ViewOrigin.ToString()); return MCamReturn.NoErrors; } else { SetPostArguments($"-99999", $"{postArguments.Argument1} NOT FOUND", $"{postArguments.Argument1} NOT FOUND"); return MCamReturn.ErrorOccurred; } } private PostProcessorArgumentsType GetPostArguments() => (PostProcessorArgumentsType)PostingManager.PostProcessorArguments; private MCView GetView(string name) => SearchManager.GetViews() .Where(v => v.ViewName.ToUpper() == name.ToUpper()) .Select(v => v).FirstOrDefault(); private void SetPostArguments(string argumentOne, string argumentTwo, string argumentThree) { PostProcessorArgumentsType returnArguments; returnArguments.Argument1 = argumentOne; returnArguments.Argument2 = argumentTwo; returnArguments.Argument3 = argumentThree; PostingManager.PostProcessorArguments = returnArguments; } #endregion } } The post - #region Numeric Variable Initializations dll_return : 0 #endregion End Numeric Variable Initializations #region String Variable Initializations sdq : '"' # " sspace : " " snone : "none" sinvalid : "-99999" sdll : "QueryViews.dll" sdll_args : "" #endregion End String Variable Initializations #region Query Views sview_name : "TestWCS" fq 1 sview_name "Enter a View's Name to Query" pquery_views q1 sdll_args = sdq + sview_name + sdq dll_return = dll(sdll, sdll_args) if spost_arg_0$ <> sinvalid, [ sview_name, "- Found!", e$ " Work Offset ->", spost_arg_0$, e$ " View ID ->", spost_arg_1$, e$ " Origin ->", spost_arg_2$, e$ ] else, "ERROR -", spost_arg_1$, e$ #endregion Query Views psof$ pquery_views Output - // TestWCS - Found! // Work Offset -> 59 // View ID -> 52 // Origin -> X0.0000 Y0.0000 Z0.0000

The NCI will only contain the view/plane information for the posted operations. You can call a Hook from the post to interrogate the Mastercam file and get the view objects. What exactly are you trying to do?

A minimally tested post block using regular expressions below. Keep in mind that the regex function is only in Mastercam 2019 and beyond sinput : "980-1000001258-56286_A_OP1.nc" sregex : "^(.{0,16}).*?_(.*?)_(.*?)\." spart_number : "" srevision : "" soperation : "" pparse_string spart_number = regex(sregex, sinput, 10) srevision = regex(sregex, sinput, 20) soperation = regex(sregex, sinput, 30) "The first 16 characters of the part number is:", e$ " ", "->", spart_number, e$ *e$ "The revision is:", e$ " ", "->", srevision, e$ *e$ "The operation number is:", e$ " ", "->", soperation, e$ //Output: // The first 16 characters of the part number is: // -> 980-1000001258-5 // // The revision is: // -> A // // The operation number is: // -> OP1

That sounds like a job for regex!

I may be misunderstanding, but it appears from your example that you just want the first 16 characters of the string. If you're using Mastercam 2019 you can use a regex to only grab up to the first 16 characters in a string, below is a simple example ^.{1,16} Prior to 2019 you cancheck the length of the stringwith the strlen function. If the string is less than 16 characters do nothing, if it's greater than 16, use the brksps function to break the string 16 places in.

That list appears to be from the Version 9.1 post docs (Volume 3, chapter 4); that's why I wanted to bring it up, it's quite out of date.

Just so you are aware, that list of tool_op$s is not for the current release of Mastercam.

The control is different, but nothing about it is hard. Have you have training yet? GF used to offer training at their facility for free; if that's still the case take advantage of it. Also, call GF! Their apps guys are second to none in my experience and really know the machine and control inside and out. Take that last part with a grain of salt... I used to be a Mikron Apps guy for GF.

Hi, I know nothing about the capabilities of the VB script dll. But, if you swapped over to a NET-Hook this is easily done with the EnumerateFiles method and Linq. var mastercamExtentions = new List<string> { ".MCAM-CONTROL", ".MCAM-MMD", ".MCAM-LMD", ".MCAM-RMD", ".MCAM-WMD", ".PST", ".PSB", ".PSM", ".MCPOST", ".MCBPOST", ".MCDPOST", ".MACHINE", ".MCAM" }; var allFiles = Directory .EnumerateFiles(folderPath, "*", SearchOption.AllDirectories) .Where(file => mastercamExtensions.Any(file.ToUpper().EndsWith)) .ToList(); You can read more about this here.

Did you copy and paste that code from your editor? If so you have some extra junk after the 15332, see below. Once I removed the extra characters everything worked as expected.

The post linked to Mill Default (mpfan.pst) is a 4-axis post.

The force operator (*) only works on variables, prdrlout is a postblock call. I'd use the force function on the variable that's in prdrlout before calling it.

You can call a NET-Hook from the post and use the NET-Hook to interrogate the Mastercam file. If you wanted to use a system plane for this I think you could do it in the post without creating a extra toolpath, provided you are in 2017 or later (I realize that a system plane is limiting) .

I don't think you need to use LN to support different axis combos; AC code in M128 will run on an BC machine. I think you mean TX, TY, and TZ for the tool vector.

I think you're out of luck; that value doesn't appear to be written to a parameter.

That makes sense. Under some circumstances (the enhanced tool table being one of them) populating a parameter table uses opinfo; so rather then typing opinfo a bunch of times, you can use a parameter table to minimize typing. The NCI line should be your last resort. The parameters are stored in a table and that makes it very quick to obtain the data. When you query an NCI line you are starting the the top of the file and reading every line until the data is found. On top of searching the NCI file, in most cases you need to parse the resulting string, adding more overhead to the process. Though it may work, -99999 is not "-99999" I'm surprised that they work. The enhanced tool table works much differently then pwrtt$ and I didn't expect it to write that data.

Why write everything to buffer one? It would be much more efficient to handle all the output in the ptooltable$ post block. A few other notes that may be helpful... Using opinfo to query an NCI line should only be used as a last resort. This is because when opinfo is used to read an NCI line, it searches the NCI file rather then using the table built during the binary to text NCI conversion. #sparameter$ = opinfo(1013, 0) #b1_ToolDia = rparsngl(sparameter$, 2) #b1_ToolCornerRad = rparsngl(sparameter$, 3) #The ^^^ above ^^^ is slow, it's faster to use parameters when they are available. b1_ToolDia = opinfo(10005, 0) b1_ToolCornerRad = opinfo(10006, 0) The below comparison shouldn't work. When opinfo is used on parameters that are strings, it returns a string, even if the return is invalid. #if opinfo(20001, 0) <> -99999, s_ToolName = opinfo(20001, zero) # The ^^^ above ^^^ Should not work if opinfo(20001, 0) <> "-99999", s_ToolName = opinfo(20001, zero) For the same reason as described above, it's faster to use parameter 10094 as shown below. if opinfo(10094, 0) <> "-99999", s_ToolName = opinfo(10094, zero) I wouldn't expect zmin$ and zmax$ to be calculated during the enhanced tool table processing , it would be better to use parameters 16 and 19 as shown below. b1_Zmax = opinfo(16, 0) b1_Zmin = opinfo(19, 0) You can use tt_count$ to determine if a tool has been output ptooltable$ if tt_count$ = 1, [ result = fprm(101, zero) sopen_prn, *tt_tool$, sdelimiter, ptool_name, sdelimiter, *tt_tlngno$, [if comp_type > 0 & comp_type < 4, sdelimiter, *tt_offset$, sdelimiter, *scomp_type, sdelimiter, *tool_dia], [if not(drilling_op), pget_stock_to_leave_tt(tt_tool$)], sdelimiter, pget_tool_z_min(tt_tool$), sclose_prn, e$ ] Rather than using opinfo multiple times, consider using a parameter table and populating it with fprm. # Enhanced Tool Table Parameters fprmtbl 101 2 #Table Number, Size # Param Variable to load value into 10005 tool_dia 15346 comp_type Hope that helps!

If you use Mastercam 2017 or later, there is a much better (easier/cleaner/faster) way to do this. I would recommend you explore the new options CNC Software has introduced before implementing the code snippet in this thread.

The below ran on grbl 1.1. I think you'll need a G49 to cancel the G43.1, but I'm only hooked up to the board so I can't tell too much G0 G53 Z0. M01 G0 G90 G54 X-1. Y.5 S5000 M3 G43.1 Z.51 G1 Z.23 F50. X1. F350. Y-.5 X-1. Y.5 Z.49 F300. M5 G0 G53 Z0. G0 G53 X0. Y0. M30 % I

I think the best way to disable the tool change is to use the auxiliary file stream and generate a new file for each tool. I have an example of this but I'm not sure if it will work in V9. If I have time tonight I'll flash grbl and see if I can get out put that works.