Known limitations

The following is a list of known limitations of GCAM SE. It is not meant to list the blatantly obvious (like GCAM SE supporting lines and arcs but not, say, Bézier curves) - instead it aims to state current internal limits that are not readily apparent and will hopefully warn in advance about what GCAM SE is not able to handle. Please note that this is by no means an exhaustive list - new items get added as they are encountered and obsolete ones get removed as is the case.

Tools

• All tools are treated as cylindrical end mills with a constant diameter throughout their entire length; even Gerber isolation milling (normally done using a V-tip engraving stylus which carves a groove with a width determined by its depth) is performed as if the tool has a constant diameter.
• There are no special provisions made to distinguish or protect non-center-cutting tools; all tools are assumed to be able to perform plunges.

Sketches

• There are currently no provisions to attempt to detect or report the tool path generation failing (such as the selected tool not even fitting inside a pocket to be milled) - the tool path algorithm simply does its thing. It's the responsibility of the user to use sane-sized tools for each job and to keep an eye out for anything that might back GCAM SE into a corner it doesn't know how to get out of.
• The contour offsetting algorithm responsible for calculating displacement caused by tool radius and non-vertical extrusions is a rather naive one: it can trim contour segments that get pushed together and reconnect segments that get pulled apart, but it can't handle anything more complex like segments that disappear completely or pockets that close off separating from the main contour as it shrinks and since v2020.05.13 it can also remove segments disappearing completely in certain simple cases, but it can't handle anything really complex like pockets that close off separating from the main contour as it shrinks. This means that offsetting only works reliably when the incurred displacement (via tool radius or extrusion slant) is relatively small compared to the features of the sketch implying that all segments of the original contour are present in the offset one too. Implicitly, pathways that do not incur displacement (milling along contours with a strictly vertical extrusion) should not be affected. Improving this is definitely a goal to be pursued, but for now things are what they are.
• Pocketing does try to keep slightly off the exact pocket contour for the "material removal" raster pass, only following it exactly in the subsequent "contour cleanup" pass. However, due to a particularity of the pocketing algorithm (it's based on a fixed horizontal raster aligned with the edges of the material, not with the pocket to be milled) it's entirely possible that the "roughing" pass for the horizontal edges of a pocket will follow the exact same "Y" coordinate as the "cleanup" one, if the distance from the bottom edge of the material happens to be an integer multiple of the tool radius; in such a case, the first pass would still try to keep away from the edges of the pocket in the "X" direction, but not in the "Y" direction. If this is a significant issue, it can be worked around by slightly repositioning the sketch within the material along the "Y" axis, rotating the sketch to eliminate horizontal edges or using a different sized tool.
• In order to handle contours more intuitively GCAM SE tries to sort segments in a sketch into an end-to-end continuous list so it can appropriately handle contours that are closed, even when some of the segments are flipped or shuffled around and out-of-order. Because the order of the actual list of segments is under the control of the user and is obviously not to be changed arbitrarily, GCAM SE needs to redo the sorting for every change occurring on the display - however, due to the rapidly increasing number of operations involved, sketches with a very large number of un-ordered segments can cause significant slow-down in responsiveness. The solution is to keep sketches ordered in the first place, reducing the required amount of processing drastically; this can easily be done any time via the "Optimize Order" action of the "Edit" menu.

Images

• Depth maps derived from the shade of grey of the corresponding pixels are treated as ideally shallow objects where the tool only connects to the material in the single point being milled - in other words, there are no attempts made to guard against a non-ideal tool removing adjacent material that should not be removed. For a ball nose cutter or an engraving stylus and shallow objects this should be an acceptable approximation, but be advised that the tool will simply walk right up to arbitrarily abrupt "walls" and with deep objects that would likely mean undesirable consequences.

Gerber Import

• The Gerber import parser is not a full implementation of the specification and therefore does not handle everything that can possibly appear in a Gerber file. In particular:
  • Either units of millimeters or inches are supported as declared in the header, but dynamic unit changes (G70 / G71) are not supported (they are also being deprecated in the specification itself).
  • The only supported coordinate notation is "absolute notation"; the alternative "incremental notation" is not supported (it is also being deprecated in the specification itself).
  • The only supported coordinate format is "omit leading zeros"; the alternative "omit trailing zeros" is not supported.
  • The only supported aperture types are "Circle" (C), "Rectangle" (R) and "Obround" (O); there is also a convenience feature that converts "OC" octagonal apertures into circles, and since v2020.05.13 "Rounded Rectangle" pads (in a strictly vertical or horizontal, non-rotated position) are also supported; any other aperture type (such as other types of polygons or macros) is unsupported.
  • Filled areas ("regions") are not currently supported.

Excellon Import

• The Excellon import parser is not a full implementation of the specification (such as exists) and therefore does not handle everything that can possibly appear in an Excellon file. In particular:
  • Only "format two" files are supported.
  • Either units of millimeters or inches are supported; the numeric format is assumed to be XXX.XXX for metric and XX.XXXX for imperial notation. There is also a convenience feature that tries to detect KiCAD-style format clues embedded in comments.
  • The only supported coordinate mode is "absolute mode"; the alternative "incremental mode" is not supported.
  • The only supported coordinate format is "omit leading zeros" (TZ); the alternative "omit trailing zeros" (LZ) is not supported.
  • The only accepted G-commands are G05 ("drill mode") and G90 ("absolute mode").
  • The only accepted M-commands are M71 ("metric measuring mode"), M72 ("inch measuring mode") and M30 ("end of program").

SVG Import

• The SVG import parser is not a full implementation of the specification and therefore does not handle everything that can possibly appear in a SVG file. In particular:
  • Dimension handling is limited to the contents of the "height" and "width" attributes of the <svg> element, which are used to detect imperial or metric units; if neither is found, numeric values are used unchanged in the native unit of the current project, unless "%" is detected as unit, in which case values get rescaled correspondingly. The "viewBox" attribute is completely ignored.
  • Due to differing coordinate systems (SVG origin is top-left, GCAM SE origin is bottom-left) the "height" attribute needs to be accurate in order for GCAM SE to be able to convert coordinates correctly; any difference results in all imported objects being displaced vertically by a corresponding amount.
  • The only currently supported graphic element is <path> (which is, however, fully supported); anything else, including "rect" / "circle" / "ellipse" / "line" / "polyline" / "polygon" is simply ignored.
  • Lines and circular arcs are imported directly, but everything else gets approximated with lines; the number of segments per curve is currently hard-coded by default set to 50 but can be changed since v2020.05.13 via a setting in the file settings.xml.
  • SVG transforms are not supported.