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?

That was provided just to show the math; you don't actually need it. The below method leverages the provided math stuff and achieves the same result. public Point3D ConvertToViewCoordinates(Point3D point, MCView destinationView) { var destinationViewMappedOrigin = ViewManager.ConvertToViewCoordinates(destinationView.ViewOrigin, destinationView); return ViewManager.ConvertToViewCoordinates(point, destinationView) - destinationViewMappedOrigin; }

ViewManager.ConvertToViewCoordinates only appears to map the point; it doesn't seem to include the origin. Below is a short example showing how to take the shift into account. using Mastercam.App; using Mastercam.App.Types; using Mastercam.IO; using Mastercam.IO.Types; using Mastercam.Math; using Mastercam.Database; namespace pointMappingExample { public class Main : NetHook3App { public override MCamReturn Run(int param) { var selectedPoint = new Point3D(0, 0, 1); SelectionManager.AskForPoint("Select a point", PointMask.Null, ref selectedPoint); PromptManager.WriteString("Select the source view"); var sourceView = ViewManager.SelectFromPlaneList(); PromptManager.WriteString("Select the destination view"); var destinationView = ViewManager.SelectFromPlaneList(); PromptManager.Clear(); var pointService = new PointService(); var convertedPoint = pointService.ConvertToViewCoordinates(selectedPoint, destinationView); var transformedPoint = pointService.TransformToViewCoordinates(selectedPoint, sourceView, destinationView); DialogManager.OK($"Selected point(world)\n" + $" X:{selectedPoint.x}\n" + $" Y:{selectedPoint.y}\n" + $" Z:{selectedPoint.z}" + $"\n" + $"Converted point({destinationView.ViewName})\n" + $" X:{convertedPoint.x}\n" + $" Y:{convertedPoint.y}\n" + $" Z:{convertedPoint.z}" + $"\n" + $"Transformed point({destinationView.ViewName})\n" + $" X:{transformedPoint.x}\n" + $" Y:{transformedPoint.y}\n" + $" Z:{transformedPoint.z}", $"Results"); return MCamReturn.NoErrors; } } public class PointService { //Short method public Point3D ConvertToViewCoordinates(Point3D point, MCView destinationView) { var destinationViewMappedOrigin = destinationView.ViewMatrix.MapPoint(destinationView.ViewOrigin); return ViewManager.ConvertToViewCoordinates(point, destinationView) - destinationViewMappedOrigin; } //Long method public Point3D TransformToViewCoordinates(Point3D point, MCView sourceView, MCView destinationView) { var sourceViewMappedOrigin = sourceView.ViewMatrix.MapPoint(sourceView.ViewOrigin); var pointInSource = sourceView.ViewMatrix.MapPoint(point) - sourceViewMappedOrigin; var pointInTranspose = sourceView.ViewMatrix.GetTranspose().MapPoint(pointInSource) + sourceView.ViewOrigin; var destinationViewMappedOrigin = destinationView.ViewMatrix.MapPoint(destinationView.ViewOrigin); var pointInDestination = destinationView.ViewMatrix.MapPoint(pointInTranspose) - destinationViewMappedOrigin; return pointInDestination; } } public static class Matrix3DExtensions { public static Matrix3D GetTranspose(this Matrix3D m) { var rowOne = new Point3D(m.Row1.x, m.Row2.x, m.Row3.x); var rowtwo = new Point3D(m.Row1.y, m.Row2.y, m.Row3.y); var rowthree = new Point3D(m.Row1.z, m.Row2.z, m.Row3.z); return new Matrix3D(rowOne, rowtwo, rowthree); } public static Point3D MapPoint(this Matrix3D m, Point3D p) { var mappedX = (p.x * m.Row1.x) + (p.y * m.Row1.y) + (p.z * m.Row1.z); var mappedY = (p.x * m.Row2.x) + (p.y * m.Row2.y) + (p.z * m.Row2.z); var mappedZ = (p.x * m.Row3.x) + (p.y * m.Row3.y) + (p.z * m.Row3.z); return new Point3D(mappedX, mappedY, mappedZ); } } }

I think you’ll need to map the point yourself if it’s not in world coordinates to begin with. Try multiplying the point through the transpose/inverse (They are the same in a unitized, orthogonal DCM) of the source view’s DCM (matrix), then multiply that point through the destination matrix. With this method you can convert a point in any view to any other view; the source point doesn’t need to be in world coordinates. Side note; you’re typing too much. Add some using directives so you don’t need to type out the namespaces.

Just so you are aware, this is not an ideal use for opinfo. When you tell opinfo to query an NCI line it searches the NCI file that’s on disc. I’m almost positive you can get the value you are looking from a traditional parameter in memory, have you done a parameter dump? Using opinfo on an NCI line should only be done if the data isn’t available in memory.

That’s an interesting idea, but I’m not hot on it. Are you going to implement it?

Thanks! Multiple instances was the driving force behind this add-in, as everything else can be done in Mastercam OOTB. I didn't like programing HMC's TOP-FRONT and wanted a quick way to create any number of views from an existing view and one of it's axes. I actually went a bit crazy the past few evenings reworking the UI to reduce clicks and adding a view name template so the resulting views' names can be customized.

I did something similar awhile back, very cool!

I'd expect the motion on the inside corners to be erratic. Start at the lower right of the below image; notice how the flags (dark purple) are nicely flowing? Once we hit the corner, big swings start to happen. This could be avoided by fixturing the part at an angle, or by smoothing the instability across multiple moves. The result of the latter is shown below.

I'm not familiar with scandic characters, so I grabbed some random non-ascii ones for this example. s_return : "" s_replacement_char : "" flktbl 1 4 "A" "Ä" "E" "Ë" "I" "Ï" "O" "Ö" s_string : "STRÏNG ÖF MÏXËD CHÄRÄCTERS" p_sanitize_s_string s_return = regex("([^\x00-\x7F])", s_string, 0) while strlen(s_return), [ s_replacement_char = flook(1, s_return) s_string = regex(s_return, s_replacement_char, 2) s_return = regex("([^\x00-\x7F])", s_string, 0) ] psof$ "BEFORE: ", s_string, e$ p_sanitize_s_string *e$ "AFTER: ", s_string, e$ Sample output BEFORE: STRÏNG ÖF MÏXËD CHÄRÄCTERS AFTER: STRING OF MIXED CHARACTERS You would have to add all the replacement characters to the look up table, and if the replacements are outside the ascii range the regex would need to be modified; but you get the idea.

I've tried this both managed and native add-ins. The result is the same; MP takes time to spool up the process. Also because of the serial nature of MP, nothing is happing until the called app returns. It's not a big deal if you are doing it a handful of times, but it can get bothersome. In this case (parsing a string) MP's regex function would be very useful and much quicker than sending it out to an external app. Not to derail this, but I think you should look into what inline-ing does.

That would work, but in my testing repeatedly using the launch or dll function will make the posting time much longer. The dll function will allow you to pass three arguments between an add-in and the post; no need to write anything to disk in most cases.

You are out luck on both counts. Strings can’t be passed as arguments. MP post blocks can only operate on arguments; they cannot truly return a value.

Code expert’s highlighting is file dependent; nc files highlight differently than post files. The $ sign is not a problem, a proper regular expression needs to be used to identify the sync points.

A $ in a regular expression asserts the end of a line, so that’s not going to work. Escape the $ with a \. I highly suggest you use a site like regex101.com to help you if you are new to regular expressions.

Not exactly. The CycleTime add-in was created as a simple way to get a variety of cycle time information during posting. The times it provides are not more accurate.

For that to be true the post would have to be configured to build the helical arcs from the linear data. The NCI only contains linear moves with the axis control set to 4 or 5-axis.

The ‘C’ in threadC means contour, so using it with a single entity is not really it’s intended use. Your reseller is correct, a custom post is required; I’m not aware of any CNC post that supports threadC. This is because threadC writes it’s parameters to the NCI and doesn’t fill out the normal threading NCI lines.

If you are using Mastercam 2019 or later, use a regular expression to sanitize the string. s_regex := "[^\x00-\x7F]" s_replacement := "" psof$ *e$ "Before: ", ~strtool$, e$ strtool$ = regex(s_regex, s_replacement, 2) "After : ", ~strtool$, e$ Sample output. Before: Ø12 R0,2 *60 ISCAR After : 12 R0,2 *60 ISCAR

Change fs2 to fmt.

Remove that line, you initialized nos when you set it equal to mi5$

Remove the dollar sign from the nos variable in the format statement.

Part handling operations don't have tool change lines. The lack of a tool change means that opinfo doesn't 'see' part handling operations in it's offset(default) mode. This means that you need to read the operation stream to look at all the operations. If you have questions about this I recommend you contact your reseller or post on CNC Software's forum.

The following regex will match M1000 - M1099 \bM10[0-9][0-9]\b Here is a link to it being checked against common M-codes As far as what language is used; in this case it probably doesn't matter. They all should support what you are trying to do. One difference I'm aware of is the the C++ standard library regex implementation doesn't support lookbehind. I think this goes for javascript also, but google will have a better answer if you care to get into the minutiae.

Shot in the dark. You have an arc format issue; have you tried calling G91.1? Aside from that it sounds like you're asking for a post; have you talked to your local reseller?