{"thread":{"id":"54934","subject":"Using Git for OpenSCAD and 3D Printing","startedAt":"2021-01-05T10:05:58Z","lastAt":"2021-01-18T23:06:39Z","messageCount":4,"participants":["Mr. Sandor Kunyik","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"413442","messageId":"cee9debaf32b69d793d0b8a3e8d4b2c6@kane-il.us","threadId":"54934","inReplyTo":null,"subject":"Using Git for OpenSCAD and 3D Printing","fromName":"Mr. Sandor Kunyik","fromEmail":"sandor@kane-il.us","sentAt":"2021-01-05T09:57:08Z","receivedAt":"2021-01-05T10:05:58Z","isPatch":false,"sender":{"key":"sandor@kane-il.us","avatar":null},"body":"Greetings,\n\nIf you were to design a new workflow, what key observations would you \nmake in regards to OpenSCAD scripts?\n\nAs a quick illustration: I have a model with cavities to hold hex bolts \nand nuts. I fine-tuned the model to print on PrinterA, using FilamentA, \nSettingsA. Once in \"production\" I need to \"freeze\" all relevant scripts, \nespecially when using multi-file structure. If the modules receive \nparameters I need to \"remember\" those parameters (such as the radius for \nthe hex, and the dept of the cavity), and if they use hard-coded values \nI must remember not to change them. Otherwise I cannot repeatedly print \nthe same model.\n\nNow imagine this for the entire standard set of hex bolts - each of \nthese were fine-tuned, test-printed and verified.\nThe rationale behind this to guarantee that the models trying to conform \nto a standard (such as ASME B18.3) stay put, while models receiving \nnon-standardized sizes such as Nylon 6/6/ (which have bigger hex heads) \nstay separated, and tweaked to work with each supplier.\n\nMy question is, should I just \"hardcode\" everything, set up forks or \nbranches for all past scenarios? So far I only have a few dozen models \nand I'm already having a hard time finding models I printed and used in \nthe past, to print again. How do I structure all this?\n\nI am a mechanical engineer not a coder, new to all these. Maybe git or \nrevision control is not the correct tool for this job?\n\n-- \nThanks for your time reading,\nSandor\n"},{"id":"414043","messageId":"a3e191a0-5c39-fe50-f57e-6b2ddeb4373d@iee.email","threadId":"54934","inReplyTo":"cee9debaf32b69d793d0b8a3e8d4b2c6@kane-il.us","subject":"Re: Using Git for OpenSCAD and 3D Printing","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-01-11T12:28:15Z","receivedAt":"2021-01-11T13:00:08Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Sandor\n\nI haven't used OpenSCAD but I thought it worth mentioning some personal\npoints about using Git for Engineering products, where variants\nproliferate and build-products must be  versioned.\n I had a go with FreeCAD a few years ago to create an insulating spacer\nthat the mech eng had forgotten...\n\nOn 05/01/2021 09:57, Mr. Sandor Kunyik wrote:\n> Greetings,\n>\n> If you were to design a new workflow, what key observations would you\n> make in regards to OpenSCAD scripts?\n\nI'm sure that git is able to store and version all the scripts and\nproducts, but it does need a vision about how to present the\norganisation of the scripts and products, especially for engineered\nitems. Remember that software version control is just drawing office\nprocedure with the hard stuff ripped out ;-) [1]\n>\n> As a quick illustration: I have a model with cavities to hold hex\n> bolts and nuts. I fine-tuned the model to print on PrinterA, using\n> FilamentA, SettingsA. \n\nIs the fine tuning done via the scripts, or is it manual. If it is the\nlatter then it will need the user to record in the commit message for\nthe revision the various what/why/how aspects that aren't obvious from\nthe 'diff'. Does OpenSCAD have an informative 'diff' capability? If it\nis just a 'compile for printerA using known-tool' then it could be an\nautomated commit message as you are storing a build product (If it was\nregular software it's likely it's a binary..)\n\n> Once in \"production\" I need to \"freeze\" all relevant scripts,\n> especially when using multi-file structure. If the modules receive\n> parameters I need to \"remember\" those parameters (such as the radius\n> for the hex, and the dept of the cavity), and if they use hard-coded\n> values I must remember not to change them. Otherwise I cannot\n> repeatedly print the same model.\n\nSo these parameters are essentially a 'configuration file' (inc. the\nhard coded values). If you auto generate such a file then it can easily\nbe stored within revision (commit) - It is important that the scripts\nshould be able to work directly from that config file (idempotent [2])\n\n>\n> Now imagine this for the entire standard set of hex bolts - each of\n> these were fine-tuned, test-printed and verified.\nA library? Hence a sub-module perhaps. \n> The rationale behind this to guarantee that the models trying to\n> conform to a standard (such as ASME B18.3) stay put, while models\n> receiving non-standardized sizes such as Nylon 6/6/ (which have bigger\n> hex heads) stay separated, and tweaked to work with each supplier.\nA configurable library item? Tricky. I remember a project that need to\nchange 20,000 drawing because they changed the paint colour (green to\ngrey), and then the next major order was in the old colour! In software\nterms its like 're-skinning' a GUI, but worse.\nMore likely you'll have a separate sub-module-library for these\n'specials' where the source part is cherry-picked (give give a backward\ntextual reference) and then modified locally giving git level\ntraceability. \n>\n> My question is, should I just \"hardcode\" everything, set up forks or\n> branches for all past scenarios? So far I only have a few dozen models\n> and I'm already having a hard time finding models I printed and used\n> in the past, to print again. How do I structure all this?\n\nThe hard part is to be both the 'design authority' that signs off the\n'release' and also the day to day designer trying things where it's a\n'fingers crossed' hope that this 3d print run will actually produce what\nyou want and expect, but mainly it's a case of realising the mistake and\ncycle it around.\nYou should at least use tags for the good release commits, to make them\neasy to find.\n>\n> I am a mechanical engineer not a coder, new to all these. \nI feel you pain. Some of the above may be more suited for those who\nactually design and contribute OpenSCAD, rather that a user getting\nstarted.\n> Maybe git or revision control is not the correct tool for this job?\n>\nAs an ME you will know that without [good] revision control the world\nfalls apart for anything other than bespoke item home jobs!\n\nGit is great because it give you full control, and local storage,\nwithout taking up too much room.\nGit is a problem because it gives you too much control and too much\nchoice. Start simple, be open to the 'mind-shift'.\n\nAdd any (i.e. more) files that you use to Git. Remove them (one at a\ntime) when you stop using them. They will still be in the history!\n\nCommit often: including halfway through a change - you know you will add\nmore and then more, then more tweaks before you print - have a commit\nfor each. I.e. distinguish between 'Printing' runs, and the act of\n'visualising the part' in the OpenSCAD viewer - both steps get a commit,\nwith concise description. (probably every 5 minutes or less!)\n\nUse the 'git gui' and 'gitk' to visualise how you have developed and\nprogressed. (or a GUI of your choice -> CAD people are NOT terminal\npeople!!)\n\nGit unfortunately lacks a short command to allow you to park a completed\nitems onto a 'Completed' branch that's just an easy quick way of seeing\nthose finished items (Git has the view that they [old software versions]\nare 'gone/left behind', with just a few v# tags), so I don't have any\ngreat solution for that.\nIf you have concise commit subject titles and messages, then it's easier\nto search history for \"print: insulating spacer widget v2.1\" (and before\nthat \"visualise: insulating spacer widget v2.1a\", 1b, 1c, 1d, 1e...).\nYou may want to allow-empty commits for ease of recording!\n\nHope that helps.\n\n[1] Drawing Office procedures allow for non perfect machining, serial\nnumbering, etc. Software generally asserts perfect replication,\nrepeatability and machining.\n[2] https://en.wikipedia.org/wiki/Idempotence\n[3] concise: adjective - giving a lot of information clearly and in a\nfew words; brief but comprehensive. \"a concise account of the country's\nhistory\" (Git: without repeating the obvious changes shown in the diff!)\n"},{"id":"414584","messageId":"f470a4e0483e1e5c3e1961315bec5475@kane-il.us","threadId":"54934","inReplyTo":"a3e191a0-5c39-fe50-f57e-6b2ddeb4373d@iee.email","subject":"Re: Using Git for OpenSCAD and 3D Printing","fromName":"Mr. Sandor Kunyik","fromEmail":"sandor@kane-il.us","sentAt":"2021-01-18T06:07:17Z","receivedAt":"2021-01-18T06:08:09Z","isPatch":false,"sender":{"key":"sandor@kane-il.us","avatar":null},"body":"\nHi Philip!\n\nThank you so much for the details! I am going to read this many times \nover the next couple of weeks.\nI have advanced on this subject, I now have a federated forum dedicated \nto this at https://hubzilla.factoryfouroh.net, and I have a Gitea \nrepository installed - all under YunoHost. I am going to be publishing \nall I print (dimension, material, etc.) OpenSCAD scripts, PNG images, \nprintable models (STEP) and maybe even animation - OpenSCAD has some \nbasic but functional animation capacity.\n\nI stopped subscribing to the git mailing list as I do not want to \npollute with newbie questions, but your answer is really valuable to me  \nbecause now I have some idea about how a pro would go about this.\nGitea it is, thanks!\n\nOn 2021-01-11 12:28, Philip Oakley wrote:\n> Hi Sandor\n> \n> I haven't used OpenSCAD but I thought it worth mentioning some personal\n> points about using Git for Engineering products, where variants\n> proliferate and build-products must be  versioned.\n>  I had a go with FreeCAD a few years ago to create an insulating spacer\n> that the mech eng had forgotten...\n> \n> On 05/01/2021 09:57, Mr. Sandor Kunyik wrote:\n>> Greetings,\n>> \n>> If you were to design a new workflow, what key observations would you\n>> make in regards to OpenSCAD scripts?\n> \n> I'm sure that git is able to store and version all the scripts and\n> products, but it does need a vision about how to present the\n> organisation of the scripts and products, especially for engineered\n> items. Remember that software version control is just drawing office\n> procedure with the hard stuff ripped out ;-) [1]\n>> \n>> As a quick illustration: I have a model with cavities to hold hex\n>> bolts and nuts. I fine-tuned the model to print on PrinterA, using\n>> FilamentA, SettingsA.\n> \n> Is the fine tuning done via the scripts, or is it manual. If it is the\n> latter then it will need the user to record in the commit message for\n> the revision the various what/why/how aspects that aren't obvious from\n> the 'diff'. Does OpenSCAD have an informative 'diff' capability? If it\n> is just a 'compile for printerA using known-tool' then it could be an\n> automated commit message as you are storing a build product (If it was\n> regular software it's likely it's a binary..)\n> \n>> Once in \"production\" I need to \"freeze\" all relevant scripts,\n>> especially when using multi-file structure. If the modules receive\n>> parameters I need to \"remember\" those parameters (such as the radius\n>> for the hex, and the dept of the cavity), and if they use hard-coded\n>> values I must remember not to change them. Otherwise I cannot\n>> repeatedly print the same model.\n> \n> So these parameters are essentially a 'configuration file' (inc. the\n> hard coded values). If you auto generate such a file then it can easily\n> be stored within revision (commit) - It is important that the scripts\n> should be able to work directly from that config file (idempotent [2])\n> \n>> \n>> Now imagine this for the entire standard set of hex bolts - each of\n>> these were fine-tuned, test-printed and verified.\n> A library? Hence a sub-module perhaps. \n>> The rationale behind this to guarantee that the models trying to\n>> conform to a standard (such as ASME B18.3) stay put, while models\n>> receiving non-standardized sizes such as Nylon 6/6/ (which have bigger\n>> hex heads) stay separated, and tweaked to work with each supplier.\n> A configurable library item? Tricky. I remember a project that need to\n> change 20,000 drawing because they changed the paint colour (green to\n> grey), and then the next major order was in the old colour! In software\n> terms its like 're-skinning' a GUI, but worse.\n> More likely you'll have a separate sub-module-library for these\n> 'specials' where the source part is cherry-picked (give give a backward\n> textual reference) and then modified locally giving git level\n> traceability. \n>> \n>> My question is, should I just \"hardcode\" everything, set up forks or\n>> branches for all past scenarios? So far I only have a few dozen models\n>> and I'm already having a hard time finding models I printed and used\n>> in the past, to print again. How do I structure all this?\n> \n> The hard part is to be both the 'design authority' that signs off the\n> 'release' and also the day to day designer trying things where it's a\n> 'fingers crossed' hope that this 3d print run will actually produce \n> what\n> you want and expect, but mainly it's a case of realising the mistake \n> and\n> cycle it around.\n> You should at least use tags for the good release commits, to make them\n> easy to find.\n>> \n>> I am a mechanical engineer not a coder, new to all these.\n> I feel you pain. Some of the above may be more suited for those who\n> actually design and contribute OpenSCAD, rather that a user getting\n> started.\n>> Maybe git or revision control is not the correct tool for this job?\n>> \n> As an ME you will know that without [good] revision control the world\n> falls apart for anything other than bespoke item home jobs!\n> \n> Git is great because it give you full control, and local storage,\n> without taking up too much room.\n> Git is a problem because it gives you too much control and too much\n> choice. Start simple, be open to the 'mind-shift'.\n> \n> Add any (i.e. more) files that you use to Git. Remove them (one at a\n> time) when you stop using them. They will still be in the history!\n> \n> Commit often: including halfway through a change - you know you will \n> add\n> more and then more, then more tweaks before you print - have a commit\n> for each. I.e. distinguish between 'Printing' runs, and the act of\n> 'visualising the part' in the OpenSCAD viewer - both steps get a \n> commit,\n> with concise description. (probably every 5 minutes or less!)\n> \n> Use the 'git gui' and 'gitk' to visualise how you have developed and\n> progressed. (or a GUI of your choice -> CAD people are NOT terminal\n> people!!)\n> \n> Git unfortunately lacks a short command to allow you to park a \n> completed\n> items onto a 'Completed' branch that's just an easy quick way of seeing\n> those finished items (Git has the view that they [old software \n> versions]\n> are 'gone/left behind', with just a few v# tags), so I don't have any\n> great solution for that.\n> If you have concise commit subject titles and messages, then it's \n> easier\n> to search history for \"print: insulating spacer widget v2.1\" (and \n> before\n> that \"visualise: insulating spacer widget v2.1a\", 1b, 1c, 1d, 1e...).\n> You may want to allow-empty commits for ease of recording!\n> \n> Hope that helps.\n> \n> [1] Drawing Office procedures allow for non perfect machining, serial\n> numbering, etc. Software generally asserts perfect replication,\n> repeatability and machining.\n> [2] https://en.wikipedia.org/wiki/Idempotence\n> [3] concise: adjective - giving a lot of information clearly and in a\n> few words; brief but comprehensive. \"a concise account of the country's\n> history\" (Git: without repeating the obvious changes shown in the \n> diff!)\n\n-- \nRegards,\nMr. Sandor Kunyik\nFourOh-LLC Technology Evangelist\n"},{"id":"414636","messageId":"ff318d1a-be96-dfe2-966c-91c177fc489b@iee.email","threadId":"54934","inReplyTo":"f470a4e0483e1e5c3e1961315bec5475@kane-il.us","subject":"Re: Using Git for OpenSCAD and 3D Printing","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-01-18T23:05:35Z","receivedAt":"2021-01-18T23:06:39Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Sandor,\n\nJust confirming details for other readers.\n\nOn 18/01/2021 06:07, Mr. Sandor Kunyik wrote:\n>\n> Hi Philip!\n>\n> Thank you so much for the details! I am going to read this many times\n> over the next couple of weeks.\n> I have advanced on this subject, I now have a federated forum\n> dedicated to this at https://hubzilla.factoryfouroh.net,\nthe home page is rather bare. Others may find these links better\nhttps://hubzilla.factoryfouroh.net/directory/?f=&keywords=3D-Printing\nhttps://hubzilla.factoryfouroh.net/channel/fouroh-llc\n\n> and I have a Gitea repository installed - all under YunoHost.\nhttps://gitea.io/en-us/  Gitea is a community managed lightweight code\nhosting solution written in Go. It is published under the MIT license.\n\n> I am going to be publishing all I print (dimension, material, etc.)\n> OpenSCAD scripts, PNG images, printable models (STEP) and maybe even\n> animation - OpenSCAD has some basic but functional animation capacity.\n>\n> I stopped subscribing to the git mailing list\nIt can be busy with developer discussions. Its archive is at\nhttps://lore.kernel.org/git/ There's a Git user list at\nhttps://groups.google.com/g/git-users/ but again is more git usage\nfocussed, rather than 3d model version control, so may not have any answers.\n\n> as I do not want to pollute with newbie questions, but your answer is\n> really valuable to me  because now I have some idea about how a pro\n> would go about this.\nOne useful example for software version control is\nhttps://nvie.com/posts/a-successful-git-branching-model/ (also web\nsearch for critical reviews of the approach).\n\nKey is to be clear about the design artefacts you need to store as\nrevisions, and what to do about 'compile' artefacts.\n\nAsk questions about revisioning on all the CAD sites, both open & paid\nCAD to get insights. A key one to ask is about the \"diff\" mechanism (if\navailable) for OpenSCAD - maybe they could have an indicator that shows\nhow much deviation from the last revision you've made (i.e. how easy to\ncreate a 'diff') so that once you go past 100% you can commit a WIP at\nthe last undo point (I guess there is at least a 1-step undo, so you can\nhave a diff report)\n\n> Gitea it is, thanks!\nThat at least lets you have your own local store while the design IP is\nunder quarantine.\n\n--\nPhilip\n>\n> On 2021-01-11 12:28, Philip Oakley wrote:\n>> Hi Sandor\n>>\n>> I haven't used OpenSCAD but I thought it worth mentioning some personal\n>> points about using Git for Engineering products, where variants\n>> proliferate and build-products must be  versioned.\n>>  I had a go with FreeCAD a few years ago to create an insulating spacer\n>> that the mech eng had forgotten...\n>>\n>> On 05/01/2021 09:57, Mr. Sandor Kunyik wrote:\n>>> Greetings,\n>>>\n>>> If you were to design a new workflow, what key observations would you\n>>> make in regards to OpenSCAD scripts?\n>>\n>> I'm sure that git is able to store and version all the scripts and\n>> products, but it does need a vision about how to present the\n>> organisation of the scripts and products, especially for engineered\n>> items. Remember that software version control is just drawing office\n>> procedure with the hard stuff ripped out ;-) [1]\n>>>\n>>> As a quick illustration: I have a model with cavities to hold hex\n>>> bolts and nuts. I fine-tuned the model to print on PrinterA, using\n>>> FilamentA, SettingsA.\n>>\n>> Is the fine tuning done via the scripts, or is it manual. If it is the\n>> latter then it will need the user to record in the commit message for\n>> the revision the various what/why/how aspects that aren't obvious from\n>> the 'diff'. Does OpenSCAD have an informative 'diff' capability? If it\n>> is just a 'compile for printerA using known-tool' then it could be an\n>> automated commit message as you are storing a build product (If it was\n>> regular software it's likely it's a binary..)\n>>\n>>> Once in \"production\" I need to \"freeze\" all relevant scripts,\n>>> especially when using multi-file structure. If the modules receive\n>>> parameters I need to \"remember\" those parameters (such as the radius\n>>> for the hex, and the dept of the cavity), and if they use hard-coded\n>>> values I must remember not to change them. Otherwise I cannot\n>>> repeatedly print the same model.\n>>\n>> So these parameters are essentially a 'configuration file' (inc. the\n>> hard coded values). If you auto generate such a file then it can easily\n>> be stored within revision (commit) - It is important that the scripts\n>> should be able to work directly from that config file (idempotent [2])\n>>\n>>>\n>>> Now imagine this for the entire standard set of hex bolts - each of\n>>> these were fine-tuned, test-printed and verified.\n>> A library? Hence a sub-module perhaps. \n>>> The rationale behind this to guarantee that the models trying to\n>>> conform to a standard (such as ASME B18.3) stay put, while models\n>>> receiving non-standardized sizes such as Nylon 6/6/ (which have bigger\n>>> hex heads) stay separated, and tweaked to work with each supplier.\n>> A configurable library item? Tricky. I remember a project that need to\n>> change 20,000 drawing because they changed the paint colour (green to\n>> grey), and then the next major order was in the old colour! In software\n>> terms its like 're-skinning' a GUI, but worse.\n>> More likely you'll have a separate sub-module-library for these\n>> 'specials' where the source part is cherry-picked (give give a backward\n>> textual reference) and then modified locally giving git level\n>> traceability. \n>>>\n>>> My question is, should I just \"hardcode\" everything, set up forks or\n>>> branches for all past scenarios? So far I only have a few dozen models\n>>> and I'm already having a hard time finding models I printed and used\n>>> in the past, to print again. How do I structure all this?\n>>\n>> The hard part is to be both the 'design authority' that signs off the\n>> 'release' and also the day to day designer trying things where it's a\n>> 'fingers crossed' hope that this 3d print run will actually produce what\n>> you want and expect, but mainly it's a case of realising the mistake and\n>> cycle it around.\n>> You should at least use tags for the good release commits, to make them\n>> easy to find.\n>>>\n>>> I am a mechanical engineer not a coder, new to all these.\n>> I feel you pain. Some of the above may be more suited for those who\n>> actually design and contribute OpenSCAD, rather that a user getting\n>> started.\n>>> Maybe git or revision control is not the correct tool for this job?\n>>>\n>> As an ME you will know that without [good] revision control the world\n>> falls apart for anything other than bespoke item home jobs!\n>>\n>> Git is great because it give you full control, and local storage,\n>> without taking up too much room.\n>> Git is a problem because it gives you too much control and too much\n>> choice. Start simple, be open to the 'mind-shift'.\n>>\n>> Add any (i.e. more) files that you use to Git. Remove them (one at a\n>> time) when you stop using them. They will still be in the history!\n>>\n>> Commit often: including halfway through a change - you know you will add\n>> more and then more, then more tweaks before you print - have a commit\n>> for each. I.e. distinguish between 'Printing' runs, and the act of\n>> 'visualising the part' in the OpenSCAD viewer - both steps get a commit,\n>> with concise description. (probably every 5 minutes or less!)\n>>\n>> Use the 'git gui' and 'gitk' to visualise how you have developed and\n>> progressed. (or a GUI of your choice -> CAD people are NOT terminal\n>> people!!)\n>>\n>> Git unfortunately lacks a short command to allow you to park a completed\n>> items onto a 'Completed' branch that's just an easy quick way of seeing\n>> those finished items (Git has the view that they [old software versions]\n>> are 'gone/left behind', with just a few v# tags), so I don't have any\n>> great solution for that.\n>> If you have concise commit subject titles and messages, then it's easier\n>> to search history for \"print: insulating spacer widget v2.1\" (and before\n>> that \"visualise: insulating spacer widget v2.1a\", 1b, 1c, 1d, 1e...).\n>> You may want to allow-empty commits for ease of recording!\n>>\n>> Hope that helps.\n>>\n>> [1] Drawing Office procedures allow for non perfect machining, serial\n>> numbering, etc. Software generally asserts perfect replication,\n>> repeatability and machining.\n>> [2] https://en.wikipedia.org/wiki/Idempotence\n>> [3] concise: adjective - giving a lot of information clearly and in a\n>> few words; brief but comprehensive. \"a concise account of the country's\n>> history\" (Git: without repeating the obvious changes shown in the diff!)\n>\n\n"}]}