OpenSCAD

Line 10:

==<tt>use</tt> vs <tt>include</tt>==

A SCAD file can include other SCAD files with either the <tt>include</tt> or <tt>use</tt> keywords. <tt>include</tt> statements are replaced with the body of the <tt>include</tt>d file (any <tt>include</tt>s or <tt>use</tt>s within the file are expanded). <tt>use</tt> only lifts <tt>module</tt>s and <tt>function</tt>s, and only affects the current file (i.e. recursive <tt>use</tt>s do not escape beyond the file that <tt>use</tt>s them).

A SCAD file can include other SCAD files with either the <tt>include</tt> or <tt>use</tt> keywords. <tt>include</tt> statements are replaced with the body of the <tt>include</tt>d file (any <tt>include</tt>s or <tt>use</tt>s within the file are expanded). <tt>use</tt> only lifts <tt>module</tt>s and <tt>function</tt>s, and only affects the current file (i.e. recursive <tt>use</tt>s do not escape beyond the file that <tt>use</tt>s them). These cannot be used within a <tt>module</tt> or <tt>function</tt>.

It's useful to have a file draw its various modules, so that running it at the top level generates examples etc. Such a file can be imported with <tt>use</tt>, and these examples won't be drawn. The downside is that any variables declared in a <tt>use</tt>d file are unavailable, so you might want to wrap them in <tt>function</tt> accessors.

~~These cannot be used within~~ a <tt>module</tt> or <tt>~~function~~</tt>.

Generally, in each project I'll have a common file in which my base objects (and their geometry) are declared. Then I build up structures from these objects, relating them using the declared geometries. Be sure to declare the geometries of these structures as their own variables (composed from substructure properties). Then, for each print job, I have a file which <tt>include</tt>s this common file, and calls those <tt>module</tt>s to be printed. There shouldn't be any composition in these files, just any <tt>translate</tt>s, <tt>rotate</tt>s, and <tt>mirror</tt>s necessary to distribute the objects optimally on a print tray. Ensure they're distinct, so that slicing software can treat them as different objects (necessary for e.g. multimaterial printing). Finally, I have a file which assembles all the pieces together as they're expected to be assembled, serving as a check on the objects; neither this file nor the common file are exported to STL.

OpenSCAD: Difference between revisions

Dank (talk | contribs)

@@ Line 10: / Line 10: @@
 ==<tt>use</tt> vs <tt>include</tt>==
-A SCAD file can include other SCAD files with either the <tt>include</tt> or <tt>use</tt> keywords. <tt>include</tt> statements are replaced with the body of the <tt>include</tt>d file (any <tt>include</tt>s or <tt>use</tt>s within the file are expanded). <tt>use</tt> only lifts <tt>module</tt>s and <tt>function</tt>s, and only affects the current file (i.e. recursive <tt>use</tt>s do not escape beyond the file that <tt>use</tt>s them).
+A SCAD file can include other SCAD files with either the <tt>include</tt> or <tt>use</tt> keywords. <tt>include</tt> statements are replaced with the body of the <tt>include</tt>d file (any <tt>include</tt>s or <tt>use</tt>s within the file are expanded). <tt>use</tt> only lifts <tt>module</tt>s and <tt>function</tt>s, and only affects the current file (i.e. recursive <tt>use</tt>s do not escape beyond the file that <tt>use</tt>s them). These cannot be used within a <tt>module</tt> or <tt>function</tt>.
 It's useful to have a file draw its various modules, so that running it at the top level generates examples etc. Such a file can be imported with <tt>use</tt>, and these examples won't be drawn. The downside is that any variables declared in a <tt>use</tt>d file are unavailable, so you might want to wrap them in <tt>function</tt> accessors.
-These cannot be used within a <tt>module</tt> or <tt>function</tt>.
+Generally, in each project I'll have a common file in which my base objects (and their geometry) are declared. Then I build up structures from these objects, relating them using the declared geometries. Be sure to declare the geometries of these structures as their own variables (composed from substructure properties). Then, for each print job, I have a file which <tt>include</tt>s this common file, and calls those <tt>module</tt>s to be printed. There shouldn't be any composition in these files, just any <tt>translate</tt>s, <tt>rotate</tt>s, and <tt>mirror</tt>s necessary to distribute the objects optimally on a print tray. Ensure they're distinct, so that slicing software can treat them as different objects (necessary for e.g. multimaterial printing). Finally, I have a file which assembles all the pieces together as they're expected to be assembled, serving as a check on the objects; neither this file nor the common file are exported to STL.