Hi all,

Does anyone have a killer file structure for keeping track of OpenSCAD files
in a complex project with multiple component parts, sub-assemblies, imported
libraries of vitamins and input parameters?

I build 3D printers, and have now built up many libraries of component
parts.

Each of my printers is fully parametric - there's no arbitrary measurement
anywhere.

Each can be heavily customised, from a 'global parameters' openscad file.

I have tended to have a single OpenSCAD file for each major sub-assembly of
the machine - say the case, the X carriage, etc.  Within each of these files
may be many modules, and there may be some includes for 'generic components'
such as bearings, etc, that I keep in a central folder separate from my own
modules.

However file sizes are often over 3000 lines, and version control is getting
to be a pain, as I have many different versions of the same file, but with
only one component amended.

What I want to do is make the customisations I've made for each customer
available as a growing library of optional files.

I am considering breaking out each individual part as its own OpenSCAD file,
and having the sub-assemblies and final assembly all as separate OpenSCAD
files.

I am generally using the OpenSCAD text editor but happy to consider other
(Windows) editors especially if capable of diff functions.

Well thought through ideas very welcome!

Cheers

Alex Gibson

+44 7813 810 765    @alexgibson3d    37 Royal Avenue, Reading RG31 4UR

admg consulting

edumaker limited

.        Project management

.        Operations & Process improvement

.        3D Printing

Here is what I use (Not an elegant system)....

Goal 1:  I should be able to pick up the project folder and install it on a
new machine and have everything work OK.*
In my case, I do a lot of work between office and home, so being able to
stuff it in dropbox and it be the same in any arena is good.

1. Any file besides the MCAD libraries are always included in the project
   directory or subfolder therein.
   This means that I can move the master directory and know that all the
   attendant files come along.

so under NameOfProject folder I might have folders named Include,
Components, Assemblies, Resources, Reference, Build Photos.

a) Include - OpenSCAD helper functions, math functions, libraries, etc.
Screw, Sweep, etc.
Components - Nuts, bolts, screws, washers, etc.
Assemblies - Small Assemblies of components
Resources - fonts, bitmaps, png files, dxf files
References - schematic diagrams, reference photos, manuals, etc.
Build Photos - always take pictures of actual builds

b)  If you are using text(), this includes making sure the .TTF is in the
folder too (say, under "Resources").  If you have to wipe the drive for some
reason odd fonts are hard to find again.

c)  Yes, this chews up disk space;  I will have a separate copy of the
assemblies and include files for each project.  Yes, disk space is
essentially free.
This means I know where the libraries are located.
This also prevents updates to master libraries from knackering a part
(depreciated feature, etc.) and prevents dependency issues.

d) Having everything in one folder tree  makes forking very easy - just
copy+paste the tree with a different name.

Goal 2:  Ability to backtrack

2. The current, most recent version of a file has the plain descriptive
   name (e.g. WidgetPart.scad).  Every time I work on a file, I "Save As" the
   date and the name of part before doing any work.  I thus have "2017-02-03 -
   WidgetPart.scad",  "2018-01-30 - WidgetPart.scad", & "WidgetPart.scad") in
   the same folder.  Some days I am not as brilliant as I imagine myself to
   be.... and change a working part until it doesn't work anymore.

a)  In each file I make,  I have a /*  /  Multiline comment.
/

    Purpose:     Blah Blah Blah (one line only)

    Author:       John Doe

    Revision Log  (one line only:   
       2018-02-03 - Adjusted the microfleems by two subradiants
       2018-01-30 - Fixed bug in sprocket  (was +2, changed to *2)
       2017-02-03 - First Functional Version  

   Documention (as needed):

   Sample Usage (very brief):

*/

b) I also try to modularize code if I have to use it more than three times,
I comment all my variables, I clearly designate modules vs. main code, I
drop comments every few lines on what a piece is doing, etc. - basic stuff.

--
Sent from: http://forum.openscad.org/

Thanks Joe, I think we're on the same wavelength and I will check out the
Swindon Makers method.  They are near me!

Cheers

Alex Gibson

+44 7813 810 765    @alexgibson3d    37 Royal Avenue, Reading RG31 4UR

admg consulting

edumaker limited

.        Project management

.        Operations & Process improvement

.        3D Printing

From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf Of Joe
Francis
Sent: 08 February 2018 23:03
To: discuss@lists.openscad.org
Subject: Re: [OpenSCAD] Managing libraries and modules in complex projects

I've been wrestling with this as well, and I think there's actually a few
separate issues wrapped up here.

1. We need a package manager to simplify/encourage reuse of not only one's
   own code, but to allow community library to arise and evolve in a
   decentralized way.  Versioning is a key factor in this, so that we can make
   break backwards compatibility without breaking older code.

2. We need more published information on best-practices.  In a perfect
   world, we'd build linters and other QA tools, similar to Rubocop, to help a
   user identify anti-patterns and improve their code.  At a modeling level, we
   need guidelines on how to orient and place parts generated by library code -
   getting that right can make a world of difference in how reusable a library
   is.  Having all this in place will help libraries "grow up" and become more
   useful to the ecosystem.

3. We need to publish more information on designing complex assemblies in
   terms of file organization, module composition, and tricks to manage
   rendering complexity.  It seems like everyone doing complex things with
   OpenSCAD is doing it their own way, and had to figure it out on their own,
   and it's a shame we don't share that better.

I've been working on a package manager and a couple initial libraries to
release with it.  It's all working great, but I need to finish up the
documentation so I can publish it all.  Coming soon!

That exercise has me working on some guidelines for #2 as well, but it's
certainly not comprehensive nor do I claim to be an expert.  I'll make sure
to publish that once I get the package manager out.

As far as #3 goes, the only thing I've seen published is
https://github.com/swindonmakers/snhack.github.io/wiki/OpenSCAD-for-Machine-
Design Some of what they do there (and similarly, what nophead does with his
automation around 3d printer design) is super cool.  At the same time, I
think there is a lot of potential for making the actual modeling experience
in OpenSCAD easier to manage.  I guess that's a 3rd blog post I owe.

I think there's an awful lot of untapped potential here just begging to be
unlocked.

Joe

On 02/08/2018 03:38 PM, Alex Gibson wrote:

Hi all,

Does anyone have a killer file structure for keeping track of OpenSCAD files
in a complex project with multiple component parts, sub-assemblies, imported
libraries of vitamins and input parameters?

I build 3D printers, and have now built up many libraries of component
parts.

Each of my printers is fully parametric - there's no arbitrary measurement
anywhere.

Each can be heavily customised, from a 'global parameters' openscad file.

I have tended to have a single OpenSCAD file for each major sub-assembly of
the machine - say the case, the X carriage, etc.  Within each of these files
may be many modules, and there may be some includes for 'generic components'
such as bearings, etc, that I keep in a central folder separate from my own
modules.

However file sizes are often over 3000 lines, and version control is getting
to be a pain, as I have many different versions of the same file, but with
only one component amended.

What I want to do is make the customisations I've made for each customer
available as a growing library of optional files.

I am considering breaking out each individual part as its own OpenSCAD file,
and having the sub-assemblies and final assembly all as separate OpenSCAD
files.

I am generally using the OpenSCAD text editor but happy to consider other
(Windows) editors especially if capable of diff functions.

Well thought through ideas very welcome!

Cheers

Alex Gibson

+44 7813 810 765    @alexgibson3d    37 Royal Avenue, Reading RG31 4UR

admg consulting

edumaker limited

.        Project management

.        Operations & Process improvement

.        3D Printing

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

I have no real solution, but as far as version control goes, it really helps
a lot to have one version only, the current version. If a change breaks old
implementations, I refactor the old implementations, och provide two
different versions (usuallt only most recent version, and an simple module
that calls the recent version, but makes some backwards compatibility fix).

It's a little bit more work, but, on the other hand, a fix fixes alla
projects. For example, I found a bug in my code for generating a chain,
fixed it, and suddenly, all old projects looked better as well.

Apart from that, group by part type/function type.

--
Sent from: http://forum.openscad.org/

This is very similar to what I use.... then I get a static snapshot of dependent libraries for each project.... I don't need to worry about breaking changes etc. However, if a library needs updated on one or more project, you have to just work through it... update the project library and deal with issues from the update. Since I keep all my projects in both Dropbox and SVN (SVN only via one computer - main computer), then I can start refactoring there... if things get too deep or I run into a deal breaker on the update, then I simply revert my library back to the previous project version and Im back to where I was.

I feel that while this may seem archaic in comparison to packages, it is certainly flexible, allows minimal work stoppage and supports a workflow to upgrade libraries in a planned manner.

Shadowwynd.... thanks for typing all of that out, I don't think it is that inelegant personally. 😊

-----Original Message-----
From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf Of shadowwynd
Sent: Thursday, February 8, 2018 8:56 PM
To: discuss@lists.openscad.org
Subject: Re: [OpenSCAD] Managing libraries and modules in complex projects

Here is what I use (Not an elegant system)....

Goal 1:  I should be able to pick up the project folder and install it on a new machine and have everything work OK.* In my case, I do a lot of work between office and home, so being able to stuff it in dropbox and it be the same in any arena is good.

1. Any file besides the MCAD libraries are always included in the project directory or subfolder therein.
   This means that I can move the master directory and know that all the attendant files come along.

so under NameOfProject folder I might have folders named Include, Components, Assemblies, Resources, Reference, Build Photos.

a) Include - OpenSCAD helper functions, math functions, libraries, etc.
Screw, Sweep, etc.
Components - Nuts, bolts, screws, washers, etc.
Assemblies - Small Assemblies of components
Resources - fonts, bitmaps, png files, dxf files
References - schematic diagrams, reference photos, manuals, etc.
Build Photos - always take pictures of actual builds

b)  If you are using text(), this includes making sure the .TTF is in the folder too (say, under "Resources").  If you have to wipe the drive for some reason odd fonts are hard to find again.

c)  Yes, this chews up disk space;  I will have a separate copy of the
assemblies and include files for each project.  Yes, disk space is
essentially free.
This means I know where the libraries are located.
This also prevents updates to master libraries from knackering a part (depreciated feature, etc.) and prevents dependency issues.

d) Having everything in one folder tree  makes forking very easy - just
copy+paste the tree with a different name.

Goal 2:  Ability to backtrack

2. The current, most recent version of a file has the plain descriptive name (e.g. WidgetPart.scad).  Every time I work on a file, I "Save As" the date and the name of part before doing any work.  I thus have "2017-02-03 -
   WidgetPart.scad",  "2018-01-30 - WidgetPart.scad", & "WidgetPart.scad") in
   the same folder.  Some days I am not as brilliant as I imagine myself to be.... and change a working part until it doesn't work anymore.

a)  In each file I make,  I have a /*  /  Multiline comment.
/

    Purpose:     Blah Blah Blah (one line only)

    Author:       John Doe

    Revision Log  (one line only:   
       2018-02-03 - Adjusted the microfleems by two subradiants
       2018-01-30 - Fixed bug in sprocket  (was +2, changed to *2)
       2017-02-03 - First Functional Version  

   Documention (as needed):

   Sample Usage (very brief):

*/

b) I also try to modularize code if I have to use it more than three times, I comment all my variables, I clearly designate modules vs. main code, I drop comments every few lines on what a piece is doing, etc. - basic stuff.

--
Sent from: http://forum.openscad.org/

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org