I have my initial design of a schematic and a produced pcb.
Obviously, things have evolved.
I have partially redrawn the schematic.
I am working on a copy of the original, so the pcb is still laid out to the original version.
What’s the best way of keeping the edge.cuts layer and some of the silkscreen layer.
Is it best to start a new pcb. But copy and paste the edge.cut layers details etc from the old pcb to the new.
I always work on my updated versions starting with the original design. After you will complete your schematic work, just update the PCB and continue your work. Unused footprints will be removed, new footprints will show up. Probably parts of your previous design will still be relevant. You can also adjust your edge.cuts if needed.
It depends on your actual design an the differences between the versions. I would delete some parts of the layout selectively and do the normal update from the schematic.
Just save the entire project as a new version (mydesignV2 or so) and work from there.
Parts in the PCB get automatically added or deleted.
I use git for versioning (and other stuff) and it works perfectly.
I have never understood ‘git’.
Could you help me, and what its all about.
Thanks
So when you are finished with a V1 you just make a tag? Or new branch?
What files do you push into git? During development, all kinds of things accumulate like gerber or bom/pos production files, datasheets, some tools whatever, do you put them into git also?
I use git for software, not sure how well it would do for KiCad. Of course git (particularly when pushing to a remote repo that has proper backup) seems the more organized approach than save as. Maybe one thing is that when you order a PCB, this is a natural checkpoint that fits the save as approach: When you order a PCB, save the entire project as V+1.
This also has the advantage that when you want to look at like the layout of V2 (and you are working on V5), you can just open that folder, while with git you’d have to switch to that branch or check out a specific tag.
You realize that this is somewhat like asking a EE that you don’t have a clue what a soldering iron is? (EDIT it’s not at all a stupid question, but probably far out of scope here)
Git is a software versioning tool that is quite popular at the moment. I suggest you search for “git tutorial” and go through a few of those. Git adds some complexity by having multiple levels of repositories and the biggest problem for a beginner is to find out which 1% of the functions git offers are relevant for you. I am sure if you ask more specific questions you’ll get more helpful answers, but that most likely will not be tolerated here as it is OT. For starters watch those tutorials.
My workflow is like this:
I have all my libraries as submodules. I.e. power, MCU, etc. Because I order mostly from JLCPCB, I use jlcpcb2kicad tool, to create both footprints and library symbols. For more “interesting” parts I have Inventree installed to keep track of datasheets, notes, etc…
Then for KiCad itself, I use git to store all design files, but not the outputs. So basically my repo is full of submodules and KiCad design files.
When I need output files, I have an automation setup. It uses teamcity and kibot as well as some my own scripts. I can use it to “render” outputs from any git commit - it will check it out, run scripts and store outputs.
I do commit often - not after every change, mostly after some logical blocks, but definitely after each “session”. This makes it possible to just checkout on my notebook if needed.
When sending the PCB to be made, I just copy the outputs into a separate folder (not a git repo) and tag the repo with info about the order (date or order number).
When I do some significant changes, I use branches. I try to not merge branches as it is a pain in KiCad, so I try to keep the repo design like a tree. Sometimes it is easier to just copy/paste or even redo some things from different branch.
If I need to see any older version or branch, I just use git clone …
And a bonus tip, for working with git on windows I use TortoiseGit and git from command line. Something is better visually, something is better using CLI,
I have to add, that making PCBs is not my main job, I am a software developer, so I am using things/workflows I know from there for KiCad also.
git works fantastically for KiCad, as all its file formats are human-readable text.
Of course, it still suffers from the fact that diffs are mismatched from the normal visual presentation, but tools like kiri and kicad-diff-visualizercan help with that.
IMO the repo should contain everything needed to regenerate the project at a point in history - things like BOM, position files, gerbers are build artifacts and should be excluded, although I would bend this rule depending on whether you have a lot of manual steps involved in generating outputs.
Ideally you use something like kibot to generate these CI-style.
One note, I would say that the outputs generation should not involve many manual steps, it should be as automated as possible…
I would strongly recommend to commit all production released files (gerbers, pick-n-place) to avoid situation that some further changes to the environment do influence output results.
I do keep a separate archive of production filesm as I find it hard to feel complete safety otherwise.
However, this is an admission that you don’t completely understand/control how your outputs are produced - which means you can only have confidence they are correct from post-production testing.
this situation (non-reproducible/deterministic release outputs) would be unthinkable in modern software dev, but it’s rather more accepted in other engineering fields.
The thing is lots of factors can determine the final outputs. As you have validated outputs available (validated by thorough inspection and by post-production testing), you’d have to perform the same testing each time you will generate your outputs using e.g. updated version of the software. For example, KiCad frequently nags for zone refill when generating gerbers. Are you sure an update to zone fill algorithm will not change your clearances? It may be that your archived project will trigger some bug.
The same factors apply in software (new compiler bugs, library updates), but nobody would suggest shipping old binaries rather than compiling. But it’s true software has a much faster/easier time validating output correctness.
For things like this, it would be nice to have CI DFM checks, just like we do automated tests for software. KiCad is one of the better platforms to enable this, but the process definitely needs more standardization and streamlining.
I would. I do not see any reason for recompiling something that works and is tested. I am using in production binaries, that are 10 years old, just because they just work. And millions do too, I just chekced my Windows installation and in system32, there are DLLs from 2005.
Well, there are game companies, that rather released cracked version of their games, than try to recompile it. And I am not sure about larger scale production, my PCBs are made by the tens, but it is important to take into account, that the outputs are only part of the manufacturing process. For example, the chip availability and manufacturing process changes at your fab can render your previous outputs unusable.
But back to the topic, I did not mention it enough in my previous post. In my workflow, I store the outputs sent to the fabrication in a separate folder and my automation puts the current version of the KiCad project into the artifacts zip file. So if really needed, I would not need any git and this zip file should be self-sufficient. And when I needed to regenerate one set of outputs after I sent it to the fab (with a footprint change because of availability of the USB connector), I used diff mode in gerber viewer to check that the rest of the PCBs are identical.
do you have a .gitignore file you’d like to share? (For the non-git-aware that is a file you place in your repo root that names all the files you don’t want to have tracked in git. Like in a C project all the compiler generated stuff like *.obj etc.)
Another vote here for version control. The fact that kicad databases are all ASCII means it’s perfect for this method and means you can easily roll back to an old version without having millions of zip files backing up old versions. It’s also really good when you’ve not issued a particular version for going back to a previous time in the dev cycle.
I use Mercurial rather than git, but both are very similar distributed version control systems. Tortoise hg is a nice GUI that makes it very easy to follow what’s going on. One place I do some work they even use svn on Altium binary files and that works too.
I do not have any super finetuned one, just what I am using (and it works for me):
.gitignore (351 Bytes)
Is it too difficult to do a net search for “gitignore kicad”?