G-code generation in a NURBS workflow for precise additive manufacturing

Abstract

Purpose

Non-uniform rational B-splines (NURBSs) are the de facto standard for representing objects in computer-aided design (CAD). The purpose of this paper is to discuss how to stick to this standard in all phases of the additive manufacturing (AM) workflow, from the CAD object to the final G-code, bypassing unnecessary polygonal approximations.

Design/methodology/approach

The authors use a commercial CAD system (Rhino3D along with its programming environment Grasshopper) for direct slicing of the model, offset generation and trimming. Circular arcs are represented as quadratic NURBSs and free-form geometry as quadratic or cubic polynomial B-splines. Therefore, circular arcs are directly expressible as G2/G3 G-code commands, whereas free-form paths are rewritten as a succession of cubic Bézier curves, thereby admitting exact translation into G5 commands, available in firmware for AM controllers, such as Marlin.

Findings

Experimental results of this paper confirm a considerable improvement in quality over the standard AM workflow, consisting of an initial polygonization of the object (e.g. via standard tessellation language), slicing this polygonal approximation, offsetting the polygonal sections and, finally, generating G-code made up of polyline trajectories (G1 commands).

Originality/value

A streamlined AM workflow is obtained, with a seamless transfer from the initial CAD description to the final G-code. By adhering to the NURBS standard at all steps, the authors avoid multiple representations and associated errors resulting from approximations.

Citation

Chacón, J.M., Sánchez-Reyes, J., Vallejo, J. and Núñez, P.J. (2022), "G-code generation in a NURBS workflow for precise additive manufacturing", Rapid Prototyping Journal, Vol. 28 No. 11, pp. 65-76. https://doi.org/10.1108/RPJ-09-2021-0254

1. Introduction

1.1 The non-uniform rational B-splines standard for computer-aided design (CAD) representation

The input data in any additive manufacturing (AM) process consists of a CAD model, typically a boundary representation (Shapiro, 2002) whose faces are trimmed non-uniform rational B-spline (NURBS) surfaces (Farin, 2002). A NURBS-based representation enjoys the following advantages, relevant for AM:

• De facto standard: NURBSs are implemented in data exchange formats [initial graphics exchange specification (IGES), STEP], allowing an exact transfer between dissimilar CAD–computer aided manufacturing (CAM) systems or a unified database in geometric libraries (SMS, 2022).

• G-code support: Cubic integral (i.e. polynomial) curves, the most popular subset of NURBS for free-from geometry, admit an exact conversion into cubic Bézier curves. In turn, these cubics are expressible as G5 commands, available in AM firmware. Circles and circular arcs also admit an exact representation as NURBS and, hence, a direct implementation as G2/3 code.

• Precision: NURBS, based on weights and control points, can express not only free-from geometry but also analytic shapes in exact fashion.

• Graphics Processing Unit (GPU) support: Graphic libraries (OpenGL, DirectX) directly support NURBS, which can, hence, be manipulated and visualized in real-time thanks to the GPU. Furthermore, there exist GPU implementations of some geometric computations, such as area integrals or Hausdorff distances.

Software developers have invested heavily in NURBSs for all these favorable properties, so downstream applications should be adapted to this representation, as Allen (2013) notes. Such applications include AM-related software, but unfortunately, this is not the case. Consequently, the potential of NURBSs has been entirely untapped in AM.

1.2 Conventional additive manufacturing workflow: problems

Recently, AM hardware capable of generating three-dimensional (3D) trajectories has been introduced, which adds flexibility to the specification of AM paths (Ezair et al., 2018). However, as most AM is still restricted to planar paths, the AM workflow proceeds in two steps (Figure 1):

1. Generating a polygonal approximation to the exact NURBS model within a CAD system, typically a standard tessellation language (STL) file, setting a maximum deviation ε_STL.

2. Transferring the polygonal model to a 3D printing software that performs three operations:

   • Slicing the model along horizontal planes Π, which furnishes its contours (sections);

   • Path planning for outer and inner walls, which involves offsetting and infill patterns; and

   • G-code generation, usually based on linear interpolations (G1 instruction).

The first problem stems from the discretization in Step 1, which may generate invalid tessellations, especially for complex models. The STL file may need post-processing to fix errors (Kumar and Dutta, 1997), such as gaps, overlaps or degenerate faces, resulting in slicing failures. The required file checks and manual repairs (Starly et al., 2005) significantly slow the workflow.

Replacing the exact CAD model with an error-free polygonal approximation allows a straightforward computation of the contours (Step 2a) as polylines. However, even trying to reduce the effect of the discretization, the resulting deviation considerably exceeds the geometric tolerance of the machine for complex geometries (Bertacchini et al., 2021). Moreover, a tighter ε_STL could make matters worse by increasing the chances of errors. The discretization leads to downstream problems, as surveys on AM (Gao et al., 2015; Qin et al., 2019) highlight:

• Slicing: As Figure 2 illustrates, the vertices V_i of the polygonal section S_STL (in red) do not lie, in general, on the actual CAD section S_CAD, for the vertical curvature of the surface, which introduces an error. Even if these vertices V_i lie on S_CAD, a chordal error results from the horizontal curvature of S_CAD. Thus, the total error ε between the section S_CAD and that S_STL from the polygonal file could grow larger than the error ε_STL in Step 1, as Jamieson and Hacker (1995) remark.

• Path planning: It feeds on inaccurate polygonal geometry, which leads to downstream errors when offsetting polyline contours and generating the corresponding strands, whose width is determined by the nozzle diameter Ø_n. As depicted in Figure 3, voids between strands may appear, compromising the mechanical integrity of the object.

• G-code generation: As the final trajectory amounts to polylines, they only display positional continuity at the joints, thereby lacking the higher smoothness of circular arcs and cubic Bézier curves available in existing AM firmware.

1.3 Our proposal: adhering to non-uniform rational B-splines at all steps

The conventional AM workflow incurs an error larger than that derived from hardware limitations, hindering the manufacturing of truly functional parts. Our proposal addresses this issue by sticking to a NURBS representation at all steps. Clearly, we have to bypass the polygonal approximation (Step 1) and then proceed as follows:

• direct slicing of the model in the NURBS environment provided by a NURBS-based CAD system;

• path planning, including offset generation, in this NURBS environment; and

• G-code generation in NURBS format; circles and circular arcs (G2/3 code) and Bézier cubics (G5), in addition to polylines (G1).

Thus, the paper is arranged as follows. First, in Section 2, we compare our approach with alternative proposals. Section 3, focusing on slicing and path planning, outlines our implementation in the NURBS-based commercial software (Rhino3D and Grasshopper). Then, in Section 4, we discuss how to exploit the untapped NURBS capabilities of G-code generators. In Section 5, we describe implementation details in existing AM firmware to encourage the reproducibility of our work. We also show a real example of a final part manufactured with a fused filament fabrication (FFF) 3D printer, which corroborates the improvement in geometric quality. Finally, in Section 6, conclusions are drawn.

2. Alternatives to conventional polygonization

2.1 Alternative formats

A first option to overcome the inaccuracies of the STL format is replacing it with a more advanced one. Qin et al. (2019) compare alternative AM formats, concluding that none of them fulfills all the requirements needed. This conclusion applies to the most supported commercial formats:

• 3MF: Although it compares favorably against STL for incorporating data such as color or material, unfortunately, it is still based on triangular meshes. Therefore, it does not tackle the critical deficiency of STL.

• OBJ: It allows meshes as well as NURBS, but AM controllers do not support the latter for its complexity, so once again, it does not provide a practical solution.

• Additive manufacturing file format (AMF): It not only uses triangular meshes, like STL, but also admits curved triangular faces. However, Yu et al. (2017) warn that the tangent definition for these faces results in a slicing error (Step 2a) similar to that incurred by STL and then put forward improvements to tackle this deficiency.

Following the idea of the open standard AMF, a low-degree patch would be a reasonable compromise between a polygonal model and complex NURBSs (Allen, 2007). For instance, Paul and Anand (2015) propose Steiner patches, a subset of quadratic rational Bézier triangles that admits accurate slicing, as any plane intersects a Steiner surface in a NURBS curve. However, Allen (2007) also notes that this strategy would entail rewriting existing software and hamper data exchange capabilities. Other formats exist, but none has gained widespread acceptance, so they do not stand as a viable option.

2.2 Direct slicing

As concluded in the previous subsection, no format provides a practical alternative to current tessellated approximations. The only option is bypassing the initial conversion (Step 1) to an intermediate format and direct slicing the original CAD model, an idea that goes back almost three decades (Carleberg, 1994).

Slicing a NURBS surface does not yield, in general, a NURBS curve, aside from simple cases, such as transversal sections of swung surfaces (Piegl and Tiller, 1997), which encompass revolution and extrusion surfaces or arbitrary sections of the above Steiner patches. These patches encompass quadrics, which also furnish simple conic sections, admitting an exact quadratic NURBS representation and hence simplifying path planning (Farouki and König, 1996). Although direct slicing is not without its own challenges (Oropallo and Piegl, 2016), it boils down to intersecting the CAD model with a plane, a fundamental operation implemented in existing geometric kernels, which furnish excellent NURBS approximations within the tolerance of the CAD model.

As Pandey et al. (2003) conclude, there is a need for modification in hardware that can drive the output of direct slicing instead of splitting it into polylines. Unfortunately, most previous proposals that advocate direct slicing do not exploit its true potential and incur inaccuracies, as they abandon the NURBS representation at some point in the AM workflow. For instance:

• Contours are not represented directly as NURBS curves but as discrete points (Ma et al., 2004; Feng et al., 2018), slice raster lines (Starly et al., 2005) or bitmap images (Xu and Jing, 2011; Xu et al., 2011).

• Contours are represented as NURBS, but their offsets for path planning are not generated using techniques tailored to NURBS (Patrikalakis and Maekawa, 2002; Elber et al., 1997; Sánchez-Reyes and Chacón, 2015) but via less precise methods.

2.3 Our proposal

A sensible, more practical solution is adapting an existing commercial tool to perform direct slicing and path planning. A first possibility could be using commercial CAM software, adapting it from subtractive to AM and exploiting its functionalities. Actually, CAM software can be used to compute horizontal contours (Step 2a), whose definition does not depend on the manufacturing method. However, it aims at manufacturing by removing material, whereas, in AM, material is added, so path planning (Step 2b) from a given contour S_CAD differs significantly. More specifically, CAM path planning involves outer offsets to S_CAD, whereas AM involves inner offsets. Therefore, as a first step, the original CAD model should be transformed into its negative version, which boils down to a simple Boolean operation (Figure 4). We successfully tested a rear-view mirror housing with SolidCAM (SolidCAM, 2022), using its built-in functionalities to slice the model and offset the contours. Unfortunately, a CAM system is already designed to output G-code, usually as polylines, for a chosen CNC controller, a scheme too rigid for our purpose of controlling all steps in the AM process to maximize output accuracy.

The alternative we put forward is using a commercial NURBS-based CAD system for both direct slicing and path planning and, finally, custom generating the G-code, always in a NURBS framework (Figure 5). This proposal resembles modern approaches to streamline the CAD-to-Print workflow based on developing specific AM kernels. In particular (Dyndrite, 2022), the recent Dyndrite Accelerated Computation Engine tries to do for 3D printing what Adobe’s PostScript page-description language (Adobe Systems, 1985) did for two-dimensional (2D) printing in the 1980s. Our goal is precisely to generate the final G-code for AM instead of printing on paper. The details of our system implementation are described in the next section.

3. System description

Our implementation was carried out by developing two software modules. First, a module in Grasshopper, the visual programming environment for Rhino3D, complemented with the add-on Xylinus (Hoover, 2022). This module performs the following tasks:

• Slicing: For simplicity, we used uniform slicing, that is, at constant vertical increments h (Figure 6), as our goal is not testing adaptive slicing but our proposal of a NURBS environment for AM workflow.

• Path planning: It involves offset generation for external and internal walls as well as generating the infill pattern.

• IGES generation: the resulting trajectories are exported as NURBS via an IGES file.

A second module, implemented in MatLab for convenience, interprets this IGES file and performs three tasks:

1. Trajectory preprocessing: At each layer, we concatenate the trajectories in an orderly manner to avoid non-extrusion movements in FFF by identifying coincident endpoints. This step is mandatory because Rhino3D exports the trajectories not necessarily in a connected way.

2. Geometric processing of trajectories: Rhino3D resorts to different NURBS curve geometries (polylines, circular arcs, quadratic or cubic integral B-splines). These different curves must be sorted out to take different actions that may include degree-elevation and splitting into Bézier cubics for the next operation.

3. G-code generation: In addition to geometric data (points and trajectory lengths) required in G-code commands, we add a header with the appropriate parameter settings (such as feed and flow rate or nozzle and bed temperature).

In the first module, Grasshopper takes care of all geometric operations, so there is no need to program complex routines for slicing or offset generation. In particular, offsetting (Elber et al., 1997; Maekawa, 1999; Patrikalakis and Maekawa, 2002) is a challenging geometric problem in path planning, which in addition involves trimming (Figure 7), also handled by Rhino3D. The add-on Xylinus includes a Curve to G-code component, but unfortunately, it transforms all paths to polylines, as G1 code. Hence, there is the need for a second module for generating our customized G-code to avoid the error of these polyline approximations and replace them by exact conversion into G2/3 and G5 commands.

4. Geometric processing of non-uniform rational B-splines trajectories and G-code generation

4.1 Transforming IGES entities into G-code commands

As Rhino3D is a NURBS-based package, the IGES file it generates describes all trajectories as 2D NURBS curves (i.e. IGES entity 126). We checked out that all the trajectories have degree n ≤ 3 and fall into one of these categories (Figure 8):

• Polylines: Polynomial NURBS (unit weights) are of degree n = 1. They are used for linear contours and infill patterns.

• Cubic polynomial spline: these include cubic NURBS with unit weights. They provide a unified representation to accommodate curves resulting from different geometry processing operations (in particular, offsetting).

• Parabolic polynomial spline: these include quadratic NURBS (n = 2) with unit weights. These curves are also used for offset approximation.

• Circles: these include quadratic NURBS (n = 2), with non-unit weights. They are used to represent holes, circular walls and fillets.

All this geometry admits an exact translation into a G-code command (G1, G2/3 and G5) without any approximation. However, aside from the simple case of a polyline, the geometric data the G-code needs do not coincide with the NURBS description provided in IGES (in terms of control points). Consequently, some geometry processing is required to translate the NURBS description into G-code. In addition, with FFF and a Marlin firmware in mind, the G-code requires a field with the accumulated length e of the extruded filament, which implies computing the arc length of each segment.

4.2 Splitting a cubic polynomial non-uniform rational B-splines into Bézier cubics via knot insertion

A cubic Bézier curve is implemented exactly as a G5 command. For a cubic with control points {bi}i=03, this command requires the endpoint b₃ = {x₃, y₃}, as well as the vectors u = {u_x, u_y} and v = {v_x, v_y} defining the end control legs u = b₁ – b₀ and v = b₃ – b₂, following the syntax:

G5 Iux Juy Pvx Qvy Xx3Yy3 Ee.

However, free-form curves resulting from geometry processing are represented as cubic polynomial NURBS d(u) instead of cubic Bézier curves. Consequently, to find the Bézier points b_i, the spline curve d(u) must be split into its cubic Bézier components by inserting all inner knots (Hoschek and Lasser, 1993). A general polynomial B-spline curve of degree n (order n + 1) is defined by a knot vector u = {u₀, …, u_i, …, u_K} and N + 1 control points (de Boor points) {di}i=0N, N = K – n–1, N ≥ n. In the IGES file exported from Rhino, B-spline curves have a nonperiodic knot vector (aka clamped or open), which means that the end knots have multiplicity n + 1, following the widespread convention in the CAGD community, as in the treatises on NURBS (Piegl and Tiller, 1997; Rogers, 2001) and the textbook on CAGD (Hoschek and Lasser, 1993):

u={u0=…=un,…,uK–n=…=uK},

We adhere to this notation, warning that the Rhino3D command Analyze > Diagnosis > List shows only multiplicity n at the end knots, as in Farin’s books on NURBS and CAGD (Farin, 1999; Farin, 2002).

Next, we customize the general knot-insertion algorithm to our particular goal for cubics (n = 3), namely, taking an already existing inner knot u_i and inserting it up to multiplicity three:

• If the existing knot u_i is simple (i.e. of multiplicity one), then replace the original de Boor point d_i–2 with three new control points d_A, d_AB, d_B [Figure 9(a)], computed as barycentric combinations of the original points d_i–3, d_i–2, d_i–1:

  dA=(1−αA)di−3+αAdi−2, αA=ui−ui−2ui+1−ui−2,dB=(1−αB)di−2+αBdi−1, αB=ui−ui−1ui+2−ui−1,dAB=(1−αAB)dA+αABdB, αAB=ui−ui−2ui+1−ui−2.

• If the existing knot already has multiplicity two, so that u_i–1 = u_i, then insert only the new control point d_AB = (1–α_AB) d_i–3+ α_ABd_i–2 on the segment d_i–3d_i–2, where α_AB denotes the quotient above.

The sought consecutive Bézier segments, making the original cubic spline, span between pairs of consecutive distinct knots and have Bézier points b_i coinciding with sequences of four consecutive de Boor points. Figure 9(b) shows an example, a cubic B-spline d(u) with original knot vector u = {0,0,0,0,1/3,2/3,1,1,1,1}. Inserting the internal knots, up to multiplicity three, furnishes the three Bézier segments I, II and III making up d(u), which meet at points d₂, d₅ of the refined B-spline representation. Thus, segments I, II and III have Bézier polygons {d₀,d₁,d₂,d₃},{d₃,d₄, d₅,d₆} and {d₆,d₇, d₈,d₉}, respectively.

4.3 Transforming quadratic polynomial non-uniform rational B-splines

Some geometry processing operations in Rhino3D yield a quadratic (n = 2) polynomial B-spline instead of cubic. To transform this curve into Bézier cubics, we proceed in two steps:

1. Insert all simple inner knots u_i, from multiplicity one to multiplicity two, to split the curve into quadratic Bézier segments. As in the cubic case, we insert a new de Boor point d_C between the original points d_i–2, d_i–1 [Figure 10(a)]:

   dC=(1−αC)di−2+αCdi−1, αC=ui−ui−1ui+1−ui−1.

2. Take triples p₀, p₁ and p₂ of consecutive de Boor points, making up each quadratic Bézier (i.e. a parabola) and degree elevate it up to degree n = 3 [Figure 10(b)], to obtain the Bézier points b_i of its cubic representation:

b0=p0,b1=13(p0+2p1)b3=p2,b2=13(p2+2p1)

4.4 Circular arcs

Circular arcs are implemented exactly as a G2 (clockwise) or G3 (counterclockwise) G-code command (Figure 11). For a circle centered at C = {x_C, y_C} and traced from the current point A = {x_A, y_A} to the endpoint B = {x_B, y_B}, the I, J form has the following syntax:

G2/3 XxB YyB I(xC–xA) J(yC–yA) Ee.

In contrast, in the IGES file that Rhino3D generates, circular arcs are represented as quadratic NURBS, with all inner knots of multiplicity two, that is, a piecewise rational Bézier form. Thus, we compute the required data as follows:

Points A and B: They coincide with the first and last de Boor points A = d₀ and B = d_N, respectively. Center C: Given by the intersection between a pair of lines Li and Lj through points d_i and d_j (i, j even) and orthogonal to control polygon, which is tangent to the circle at these points. Two consecutive lines are guaranteed not to be parallel in this piecewise rational Bézier form (with positive weights).

4.5 Computing the length of the extruded filament for fused filament fabrication

As already observed, all G-code instructions considered include a field with the accumulated length e of the extruded filament, which means computing the incremental length Δe of the filament consumed. Figure 12 depicts the geometry involved in extruding a strand of length L and layer height h, consuming a length Δe. A constant density of the deposited material implies that the volume V of the filament consumed equals that of the layer between endpoints. Assuming constant sections S_f and S_L of filament and layer, Δe turns out to be proportional to the trajectory length L:

V=SfΔe=SLL → Δe=LSLSf

The values S_f and S_L are obtained as follows:

• S_f = π·Ø_f²/4 (circular section of a filament with diameter Ø_f).

• S_L = kh is proportional to the layer height h, where the constant k must be estimated in terms of nozzle diameter Ø_n and printing parameters (Hodgson, 2022).

Regarding L, straightforward trigonometry yields it for linear (G1) or circular arcs (G2/3). For cubics (G5), the exact arc length L_b of a Bézier segment b(u) involves integrating the module of its derivative, a quadratic curve b′(u) = q(u) with Bézier points q_i:

Lb=∫01‖q(u)‖du, qi=3(pi+1−pi), i=0,1,2.

Unfortunately, this integral incurs high computational cost (Guenter and Parent, 1990). Thus, for practical purposes, Gravesen (1997) puts forward a simple approximation, namely, the average L = (L₀₃ + L₀₁₂₃)/2 between the length L₀₃ of the chord b₀b₃ and the length L₀₁₂₃ of the control polygon (Figure 13). We checked that his approximation suffices for the short Bézier segments we are dealing with, making up the paths Rhino3D generates.

5. Implementation in commercial firmware and experimental results

5.1 Implementation in commercial firmware

The practical implementation of the proposed approach requires some customizing of the firmware controlling the 3D printer. This software reads the G-code commands and translates them into the electrical commands for the stepper motor driving the print head, among other tasks. We focus on the commercial firmware Marlin (2022) for its popularity and, more importantly, open-source character, allowing customization by editing the configuration files Configuration.h, Configuration_adv.h (header files in C++).

We used Marlin 1.1, supporting not only G2/3 (circular arc) but also G5 (Bézier cubic) commands. However, by default, these commands may not be activated, but this is fixed by editing the configuration files in the following way (Dorado-Vicente et al., 2019):

• If an editable version of the firmware provided by the printer’s manufacturer is available, in the file Configuration_adv.h, then simply check out that the following lines are activated by removing the comment tag (double forward slash) if necessary:

//#define ARC_SUPPORT

//#define BEZIER_CURVE_SUPPORT

• If not, then download a generic Marlin firmware and adapt it to the specific machine. This customization involves activating not only these two lines but also the more complex task of setting several parameters in the files Configuration.h, Configuration_adv.h.

Once the configuration files have been edited, recompile to generate the executable firmware, for instance, using Arduino IDE and upload the firmware in the 3D printer. We have implemented procedure a) using BQ WitBox 3D and CreatBot PEEK-300 printers and procedure b) with Ultimaker 2+.

5.2 Experimental results

We tested our proposal with free-form printouts using PLA filament, feed rate 50 mm/s and constant layer height h = 0.15 mm. As tolerance distribution (Ma et al., 2004), we opted for a mixed tolerance, that is, slicing the model at the middle of each layer. This choice corresponds to the recommended middle setting of the slicing tolerance parameter in the Cura slicing application (Ultimaker, 2022).

The example of Figure 14, a rear-view mirror housing designed with SolidWorks and printed with CreatBot PEEK-300, compares the traditional method (via STL file) and our direct NURBS-based approach. We generated in SolidWorks both the STL file and the .SLDPRT (SolidWorks) CAD file imported into Rhino3D for slicing. Table 1 lists the corresponding file sizes, along with those of the resulting G-code files fed to the controller and the number of G-code lines they contain. For STL and CAD files with comparable sizes, the G-codes have roughly the same number of lines, albeit the file size for NURBS doubles that of the STL case. Note that the G5 instruction (Bézier cubic) is longer than the G1 (line segment), as it requires three pairs of coordinates instead of just one.

As Figure 14(a) shows, the STL facets are visible, whereas the NURBS-based approach results in a noticeable improvement in surface quality. In large-scale printing (Roschli et al., 2019), these artifacts would be even more noticeable, and large STL files would be needed to achieve a precision comparable to that of the 3D printer. Figures 14(b) and (c) depict the dimensional deviations d between the outer surface of the STL/NURBS model and that of the theoretical CAD model, with a common color code. We display a 3D plot [Figure 14(b)] as well as two partial horizontal sections z = constant [Figure 14(c)] with magnified errors, showing that the NURBS printout enjoys a notably smoother error distribution. The models were measured using a Hexagon GLOBAL-S Blue coordinate measuring machine. The sensor was a Hexagon HP-L-10.10 laser scanner with an 8 μm probing form error capturing up to 600 K points per second. The Hexagon PCDMIS 22021.1 scanning software was used to obtain the 3D color map and sections.

6. Conclusions

The traditional AM workflow, involving an initial polygonization of the object via STL, does not meet the requirements for truly functional parts regarding quality and precision, especially in large-scale 3D printing. This software limitation wastes the possibilities of existing AM hardware and precludes them from furnishing such functional parts. As Dyndrite (2022) highlights, modern hardware has outpaced software. The situation epitomizes a case of technological lock-in (Arthur, 1989), whereby a well-established standard becomes obsolete yet remains in use for compatibility reasons and the reluctance to change, trapping an industry (Farrell and Saloner, 1985). In the long term, the savings of switching to a modern standard would outperform the initial investments required in updating existing software. To break out of the locked-in STL and ease the transition process, we propose switching to the current NURBS standard, already used in the initial description of the CAD model.

The fundamental tenet in our proposal is the avoidance of multiple representations in the AM workflow by adhering to the NURBS standard at all steps, namely, slicing, path planning and G-code generation. Both slicing and offsetting, the most complex geometry operation in path planning, are already available, in a reliable way, in any NURBS-based CAD system. Therefore, there is no need to develop ad hoc procedures, as we can access these capabilities through a suitable programming environment. Direct slicing and offsetting could also be accessed by interacting directly with an existing commercial kernel, like the already mentioned Dyndrite Accelerated Computation Engine (Dyndrite, 2022), built with AM in mind.

Our main contribution is sticking to the NURBS standard at the last step of AM, namely, G-code generation, a possibility overlooked in both the literature and commercial applications. To this aim, we exploit the possibilities of exact conversion of NURBS trajectories into G2/3 (circular arcs) and G5 (cubic Bézier curves) commands, available in existing firmware controlling 3D printers. As these NURBS trajectories are usually restricted to polynomial cubic or quadratic splines and quadratic circles, the exact conversion is readily performed via standard NURBS geometry processing (knot-insertion and degree-elevation). General NURBS curves, of arbitrary degree and weights, could be handled with high-fidelity approximation techniques (Piegl et al., 2007), which incur negligible errors. Remarkably, this idea of accommodating non-linear trajectories to either circles or Bézier cubics resembles that implemented in the PostScript page-description language (Adobe Systems, 1985), yet it also admits ellipses, a geometry not available as a G-code. PostScript triggered the 2D printing revolution in the 1980s, whereas NURBS-based geometry at all steps of the AM process may help consolidate the current AM revolution.

We have implemented our ideas using the popular NURBS-based Rhino3D package as a testbed platform, with Grasshopper as a programming environment, but other combinations allowing customization would be feasible. As commercial firmware supporting the required G-code commands, we used Marlin. Preliminary examples manufactured with different 3D FFF printers corroborate the feasibility of our proposal and the resulting improvement in part quality.

Figures

Figure 1

Conventional generation of G-code for additive manufacturing, based on an initial polygonal approximation

Figure 2

Errors incurred by slicing a polygonal approximation through a plane Π

Figure 3

Path planning: Offsetting polygonal inner and outer walls

Figure 4

Generating a negative version of a CAD model for additive manufacturing path planning using a CAM system

Figure 5

Our approach for generating accurate G-code for additive manufacturing

Figure 6

Slicing a CAD object with a horizontal plane Π

Figure 7

Offset trimming in path planning

Figure 8

Transforming an IGES entity 126 into G-code commands

Figure 9

Cubic polynomial B-spline curve

Figure 10

Transforming a quadratic B-spline curve into Bézier cubics

Figure 11

Circular arc

Figure 12

Extruding a strand of length L and layer height h, consuming a filament length Δe

Figure 13

Bézier cubic: Exact arc length L_b, Chord L₀₃ and control polygon length L₀₁₂₃

Figure 14

Example (CreatBot PEEK-300) comparing traditional additive manufacturing via STL and our non-uniform rational B-splines-based workflow

Table 1

File sizes for the STL and non-uniform rational B-splines models of Figure 14 (rear-view mirror housing)

Model	File size and type	G-code commands	G-code size
STL	205 KB (*.stl)	646 KB	20.8 MB
NURBS	320 KB (*.sldprt)	586 KB	41.2 MB