MakerCAM v Carbide Create

Finally made some progress in understanding how MakerCAM is able to draw an arc (ellipse section) from SVG code. Per the Readme file with the source code that I found, MakerCAM was written about 10 years ago by the mysterious Pete000 using Adobe Systems Action Script (.as files), which are similar in structure to JavaScript.

I also now know how SVG encodes the ellipse segment in the Arc command. Essentially you provide a start point and end point on the ellipse, and the radii of the major axis and minor axis. The two points and radii define two ellipses. The Arc command uses flags to determine which of the two ellipses to use, and which path on that ellipse to follow between the two points. The following was stolen from the SVG specification, section 9, https://www.w3.org/TR/SVG/Overview.html :

That’s the easy part. The hard part, for which there is little information on the Web, is that for a graphics program or a toolpath generator, the SVG ellipse description is useless. It must be transformed to a math format in which the ellipses are defined by a center point, radii, and the angle through which the arc segment is drawn. The equations to do this are given in Appendix B of the SVG Specification. My understanding is largely due to the explanations and code to implement these equations provided in these links:

Eric Eastwood: https://ericeastwood.com/blog/25/curves ... mentations

Fridrich Strba: https://fridrich.blogspot.com/2011/06/b ... l-arc.html

Eric Eastwood and MakerCAM each implemented the procedure outlined in the SVG Specification Appendix B. The results of the procedure are the formula for the x & y coordinates for points on the ellipse as a function of the angle and the starting and ending angles of the eclipse segment. These calculated points between the starting and ending angle can be used to draw the arc (ellipse segment) on the screen (render) or to generate a toolpath.

When I started researching this, I assumed that MakerCAM would read the SVG code and turn it into some sort of internal representation. I now think what is happening is that some form of SVG code IS the internal representation. When you, for example, draw a rectangle on the screen with MakerCAM, SVG path data is generated for that object. When you select the rectangle and drag that rectangle to another location, the SVG code is updated for the coordinates of the new location. And as you were dragging, the rendering software was desperately trying to redraw the rectangle at the mouse coordinates as you move the mouse. When you save the SVG file, the current SVG code for the latest position and size of the objects is written.

I made a test SVG file in Inkscape, loaded the file into MakerCAM, and then immediately saved the SVG file from MakerCAM. The SVG code for the arc portion of the object is given in the ‘d’ parameter shown in the XML editor. The move (M) command preceding the arc (A) command sets up the ‘current position’ on the screen (100,77). The arc command then draws the ellipse segment with the x radius = 40mm, the y radius = 20mm, ending at (140, 96.99).

(Note: The SVG origin is at the upper left of the page, rather than the lower left. So a move in the +Y direction is a move down the page. Very confusing and tedious.)

The SVG file that MakerCAM produced was much smaller: A lot of re-processing seems to have been done. The units are now in ‘cm’, the three paths from Inkscape are combined into a single path and the order is of the new path is different.

We now have a way to generate the points along an arc segment defined in SVG code. Eric created a function named ‘pointOnEllipticalArc’ in which the ellipse arc segment parameters are provided, along with a variable ‘t’, which can have any value between 0 and 1. This ‘t’ represents the percentage along the path between the starting point and the ending point. The function returns the coordinates of the point that % along the path. The smaller the difference between successive values of ‘t’, the finer will be the resolution of points on the arc. I do not know what Eric is doing with the points his function generates. Another example is the ‘arcTo()’ function in SVG Salamander, written by Mark McKay in 2004.

The source code in MakerCAM for deriving the ellipse equation from the SVG code is found in an include file named ArcSegment.as. The first part of the file defines a function named ‘computeSvgArc’ which returns an Object with the transformed ellipse equation parameters (ellipse.center, radius.x, radius.y, angleStart, angleArc, angleXaxisRotation). The second part of the source file is a function named ‘linearize’ which takes the ellipse segment Object created with function ‘computeSvgArc’ and breaks it into 45 degree segments, calculates the quadric Bezier Curve parameters for each segment, and puts them into an array names ‘seglist’. This array contains the Path data to draw the elliptical arc as a series of quadratic Bezier curves.

The next question is, ‘why the approximation?’, unless it helps in generating a toolpath. Two other questions are ‘how accurate (or in-accurate) is the approximation?’ and ‘in the real world, how accurate do we need to be?’.