I feel like this must be a solved problem - either with multiple working solutions or one go-to solution…
I’m planning on adopting KiCad as the PCB CAD system for the company where I work. I’m looking for advice on how to set up KiCad for work sharing amongst a team. We already use git for our software, so ideally we would use that tool with KiCad. For a variety of reasons (including ERP) we will need to maintain our own component & footprint libraries. At this point my primary concern is making sure that different people will be able to share these libraries and not have parts not show up when they take over someone else’s work. In a very basic sense I think that a lot of my concerns/worries could be dealt with by making sure that each user has their PATH variable set properly to include wherever they keep their checked out libraries, but that might be a naive solution that will cause problems that I cannot foresee at this point.
I’m also happy to read all of your horror stories on how not to do this!
There’s no problem in having a shared “company” library for all users. All the PATH stuff is trivial.
The problem is keeping your library intact.
You need to appoint a librarian, no one else should be able to modify the library.
It’s a workflow/discipline issue, not a technical one.
The other alternative is that you have a defined process for handing control (write access) of the library around between multiple people in the team.
Some ways of implementing this are:
Using a centralized VCS that implements file locking (for example SVN, Perforce, etc)
Use a communications channel (team chat, etc) to record who currently has write access. This mechanism can work when using a decentralized VCS (Git) or when using a shared network drive.
Yes, that solves the workflow issue.
But it does not solve the disciplinary issue, which is whether the added library parts conform to the company standard.
we use kicad libraries together with git for years now. a librarian is helpful but not strictly necessary if your team defines clear library rules. for us the best workflow for now is every team member can generate and add his own symbols, footprints, 3DModels to the libraries and the additions will be checked semi-regularly but latest before the design goes into production. Ensures everyone sticks to the standards at least somewhat as it gets a real pain if you have to fix your design after it was discovered your symbol mixes up pins etc.
Perhaps relevant to discuss. I as solo Kicad user am not aware of ‘company standards/rules’. What kind of standards do companies maintain for symbols and for footprints? I am curious to an example or two. I cannot think further than a predefined silk text size…
I try to re-use the default library items whenever possible to safe me time. If I would be a librarian I would propably build all from scratch… I think .
Concerning sharing projects. Not long ago I posted my Best possible workflow to re-use not only schematic but also pre-routed board parts. As you can imagine it would not be really fruitful that 20 coworks design different 5V buck converters again and again. It is better that the librarian makes one (or somebody does this for him) and that the others can import the schematic and board part into their projects. This safes time and elimitates potential design flaws.
Each symbol has a field to identify a part in the ERP system. This can often be changed in the schematic since a symbol maybe used for different parts.
Placement rules: In a project a symbol may have some indication on which PCB variants it is placed or nor, or which exact part is placed in which PCB variant. This should be standard format so you can use a script to generate multiple BOMs automatically, one for each PCB variant.
How and when to split a component into multiple symbols.
Which identifiers will be used for which type of component.
Rules about SilkScreen width, text height, distance to copper, …
Where exactly to place the centre.
Default rotation.
Additional layers for mechanics, placement info, …
…
but also pre-routed board parts. As you can imagine it would not be really fruitful that 20 coworks design different 5V buck converters again and again. It is better that the librarian makes one (or somebody does this for him) and that the others can import the schematic and board part into their projects. This safes time and elimitates potential design flaws.
This is a reason to also standardize sheet numbering so that every 5V converter on every PCB has the same identifier.
.