How to use KiCad with larger teams

Community
1

Dear KiCad Team,
Dear community,

even tough I have some years of daily-job experience with KiCad in multiple industries, I got some questions that I was not able to answer by myself.

I recently switched job and now work in electromagnetic compliance / quality management in a big automotive supplier. In production projects we use some really expensive and “heavy” piece of EDA software that is integrated in all of the business processes and linked to the ERP, but also needs a lot of setup and even more training. So, apart from that we have a collection of not so “heavy” tools which are mostly selected based on preference of the different departments in different business areas and countries and are used for development of internal projects (like proof-of-concepts or house-developed test equipment like communication partners or some field-bus-to-fibre converters for emc-testing). We also test ASICs and other components that are protected by non-disclosure agreements or in very early development stage and of course our company wants to keep related information in a safe space.

My department now would like to get rid of all those different EDA packages that were collected for internal projects over many years and use KiCad instead of them as can import all of the data of the other packages and is actively maintained. However, this leads to the issue of setup and library / data management in a bigger team (in first stage around 30 to 50 people), where most engineers have many years of experience in hardware development and testing, but not with solutions like git (which of course we still have available as tool).

I would like to have one or more (moderated) repositories for sharing all the data where git-inexperienced users can use any git GUI-tool to pull or merge-request, and where all settings are stored in to easily setup the environment on new computers.

So, here are my questions:

  • Are there people working in other companies in the community that have solved all these problems? In my previous jobs I have always worked in small teams with other (mostly younger) engineers that had a lot of experience using git and Linux.
  • Is there any way to share all KiCad settings with minimal effort to a new employees computer?
  • Is there any guide on how to set up a non-public KiCad Plugin- and content repository and is it possible to include any authentication like ssh keys in git to protect the repository from unauthorized access?
  • Is it possible to specify the location of global sym-lib-table / fp-lib-table and the location of the file containing the environmental variables? In that case I could use a repository to clone all libraries at once.
  • Are there any features planned that will make the situation easier to handle?

Thank you very much for all your answers and suggestions in advance! Of course I also know that there is KiCad Services Corporation, but for now it is too early to approach a solution like this (even tough I will propose it to my management at a later stage).

RacingJoe

1 Like
2

I am using KiCad in team of 1 person (only me) :slight_smile: at Win10 PC and I don’t know what git is.
I believe that wherever KiCad keeps its configuration it is always simply one folder. Copying that folder should share all KiCad settings to the new computer.
At C:…\AppData\Roaming I have two folders: kicad and kicad_default. When I want to run KiCad in default configuration (to report a bug it is better to use default, I think) then I change this folder names kicad → kicad_Mm and kicad-default → kicad and when I run KiCad it uses different settings, and any modifications made are saved there. Of course changing the names back gets me back to my (MicroMade) world.
It was only one your question that I was ably to say something. I don’t know if it helps you as it should be obvious, but you surprisingly included that question among others.

3

If all member of your team are connected to the same network you don’t need git (however it may be helpful for libraries and projects versioning). A network drive is enough to share libraries, projects, etc
Do all of you use the same OS? Copying user files will transfer settings (including library settings).

As @Piotr says above - in Win10 it’s:
C:\Users\username\AppData\Roaming\kicad\6.0 (or 7.0)
In Linux (Ubuntu):
/home/username/.config/kicad/6.0/ (or 7.0)

Make a backup of the original directories and when KiCAD is closed copy them across from a computer to a computer. That should clone the settings.

Bare in mind that user.hotkeys file (user’s defined keyboard shortcuts) is also located there. It’s probably worth not to override that file as different user may have different shortcuts predefined.

There is also a few topics here discussing how to use KiCAD in a database driven environment. This may be helpful in your situation.

1 Like
4

Regarding git and network shares for libraries, it’s not a matter of either-or. You can combine them to best effect.

Questions are:

Who are the writers?
Who are the readers?

The writers would be the librarians. Even if you have only one librarian, git or another VCS is worth it to be able to recover previous versions.

Now for reader access, they could each have a git clone, but that imposes an extra duty for them to keep up to date, and inevitably they will forget. Also a git clone is a copy of everything so consumes disk space. So network shares can be useful here to share a clone that is updated by the librarian from git whenever something is modified.

5

At this stage in the development of the kicad, this is not a good idea. To begin with, there are constant errors when working with the same library on different machines, plus when updating a stable version, backward compatibility requires finishing libraries and projects with your hands… When you alone are solved relatively not difficult when 30 people are already a different situation and a lot of manual work… The simplest and cheapest option is nas storage for developers…

6

I would highly recommend to teach them how to use git or any other VCS. With or without GUI doesn’t really matter (probably better with a GUI in your case). If you can teach them or convince your superior that it is worth it, it will pay out. It can be used in other projects as well. Taking a few hours (i needed about 3 days) to learning it properly is a good investment, for your company and for the engineers as well. It makes it so much better to develop something, to test new features in a separate branch, go back to older versions and to document a project history. I even use git when i am working alone, in a single directory.

2 Likes
7

Generally yes; I have worked several places where Git was the standard for the hardware teams, and people could learn it like any other tool no matter their age. If an engineer is unwilling to learn a new tool or technique, they are not going to get very far in my opinion.

We share libraries and project templates, but not settings (i.e. things like color theme, mouse behavior, etc). We have an internal “wiki” that people can put tips and tricks on (things like “did you know you can turn off the warp mouse cursor on zoom feature?”) but we have people configure their own settings to taste.

I don’t know of a guide yet (maybe someone else does) but PCM uses HTTPS to retrieve files, not SSH, so to protect an internal repository the best way is to set it up on a server that is only accessible to internal IPs (and then people working remotely can access it over a VPN, for example). This does not provide access control inside the company, like if you wanted Department A to access the PCM but not Department B. There is not an easy way to do that at the moment, I think (besides just not using the PCM, and instead storing plugins in a Git repository)

No. This is one way where KiCad could improve in the future, but for now my recommendation is to make a “template” global table with your custom libraries, and then deploy that to all users. If you are all on the same platform (Windows, for example) you could create a script to deploy it if you didn’t want users to have to do it themselves.

Nothing is specifically planned at the moment to make it possible to centrally manage user settings, however there are some existing feature requests such as Library table chaining (#3935) · Issues · KiCad / KiCad Source Code / kicad · GitLab that will make it easier to deploy global libraries to lots of users.

Regarding library management: there are various ways to do this, but my preferences is to use Git (and not network shares). Everyone has their own local clone of the libraries, and some users are also authorized to make library modifications (i.e. they have commit rights on the Git repo server). Library changes can be reviewed using a merge-request workflow if desired (just like is done on the public libraries) if the organization is using a private GitHub / GitLab setup. Or, this can be done with just Git and some human-enforced workflows/best practices.

We also use database libraries at the current place, and it works the same way (users still have local Git copies of the library artifacts) and all connect to a private SQL server that holds the library metadata (links between symbols and footprints, internal part numbers, etc).

We use the Git server instead of any network share for various reasons, but one downside to this is that you need an “out of band” system for locking files, as nothing technically prevents two people from attempting to change the same files (and EDA files can not typically be merged together like source code files). This is something that I have seen worry a lot of people in forum threads, but in my experience it is not an issue in practice. It is rare that two engineers are working on the same design at the same time, and when that happens, it is trivial for them to just communicate about who is going to be making modifications to which file(s).

8

Git is de facto thought of as the only VCS but it’s not always the best choice. It was designed for developing the Linux kernel and other large code bases. Out of the box it doesn’t have many convenience features - although there are plenty of GUI tools available. There is no file locking and, although it’s powerful, it can be a bit arcane - although you only need a small subset of commands to use it effectively for EDA. If you code, it’s an essential skill - as is dealing with merges. In EDA design, the last thing you want is a merge conflict so your work patterns should try to avoid this.

SVN, although old, has sme advantages as it allows for file locking - Altium support SVN based libraries with locking to avoid double editing an asset.

Finally, I will mention Fossil which is a well supported and actively developed SCM from the author of SQLite. It has an inbuilt GUI, chat and Wiki as well as bug tracking and a forum feature. It’s FOSS, cross platform, fast and lightweight - a 3MB binary download. It can work interoperable with Git.

I’m also quite interested in Allspice which is designed for team working and is flagging up KiCad beta support - but I have not yet tested this.

2 Likes
9

The general problem is weak support for the kicad of this function, not git or another accounting system…
At the moment, there is no full-fledged support between the kicad version even in one branch… In disguise, problems pop up with libraries and plugins… And once you start sharing, it’s all there. I do not discourage the use of sharing the experience of using in a team of 3-4 people… A lot is solved by programming and requires a lot of manual work of time and experience… But out of the box, it does not fully work unfortunately

10

I’ll just mention that I’ve used Git (gitlab/github), SVN, and Fossil with a variety of EDA’s for work. At my workplace, SVN has been in use for a long time for document management and some design file management. Git is used widely in the software side of things, less so elsewhere. Fossil is not used at all. Of the three, I find googling for answers to Git questions to be much more fruitful than the others.

I personally love Fossil, best of both SVN and Git in my opinion. Unfortunately, the effort required to teach people a new version control system on top of a new EDA is just not worth it, so I’ve been emphasizing using Git with KiCad (mostly using one of the variety of git desktop apps). SVN probably is a better fit in terms of the ways EDA files are produced and used, but the gitlab/github web tools are worth that sacrifice in my mind.

1 Like
11

This is the main reason we use Git, along with the fact that most of our EDA users also need to be conversant with software development practices (microcontroller firmware, board bringup/testing Python scripts, etc) so it’s easiest to just use one tool for both hardware and software.

2 Likes
12

At my current job we are four active users of kicad (i.e. we design boards) and a few more that use it just to view schematics and pcbs. All kicad projects are git repositories.

We use private repositories in gitlab and github, SSH keys for authentication and different permissions and roles (for example, users that only view schematics can not push to the remote repository).

I can tell you how we manage libraries and share files: we have a repository called Kicad-libraries that has schematic symbol libraries (kicad_sym), pcb footprints, step models and even files used by kibom and other plugins. We include this folder as a git submodule in every project. We do not use global libraries, when we need a symbol from some of the global libraries we create a copy in our own library.
This has a few advantages:

  • Every project is self contained once you pull the submodule. It does not matter if some members use linux and others windows.
  • We can make modification to symbols and keep track of this modifications (for example, we add custom fields to schematic symbols like the code of the component in our ERP, information about location in our warehouse, etc).

The main disadvantage is that every kicad project has a local copy of our libraries, but kicad_sym and pretty files are not big so this is not a big problem. Step files are bigger, but even with those files the whole submodule weights around 30 Mb.

Some comments about possible conflicts:

  • We usually have no problems with modifications to the libraries because every footprint is a different file so it is rare that two persons modify the same footprint at the same time. Merges work fine 99% of the time.
  • Conflicts on board and schematic files could be a problem, but we avoid them because our team is small and we can coordinate who is working in each project. I guess bigger teams should need something like locking a file and I don’t know if git allows it.

I hope this is useful.

2 Likes
13

Regarding the experienced engineers who can’t or won’t learn a new tool like git, there are a couple things I’ve found when it comes to handling these types of folks. (This is coming from my experience in various larger teams and dealing with personalities.)

  1. If they are in the can’t learn camp, put together detailed procedures for how to clone a repo, make a branch, make a commit, and pull changes. You (or one of the other git-knowledgeable engineers) will need to help them do this, but hopefully the procedure will answer most of their questions. Also, leveraging a tool like SourceTree or similar will help avoid the command line, and make things easier for them.
  2. If they are in the won’t learn camp (stubborn, feel they have better tools, etc.), having manager buy-in and then having the team reach a critical mass of users will hopefully help motivate them to comply. Unfortunately, this only goes so far in motivating. It might get to a point where the person’s manager needs to step in and make it a “do your job and your job includes using git/KiCAD/etc, or else…” type situation.
  3. Even if you get buy in, do expect that you will be hand-holding a bunch of folks in getting these things up and running. Learning a new cad tool is daunting for most, and they do get worried about making mistakes and whatnot. Also, you probably will be adjusting/massaging the libraries/projects/etc as those other-EDA folks will be bringing the other paradigms into git and KiCAD and it probably will result in some weird situations.
  4. Use an off-the-shelf git hosting service, even if you’re running a local instance within the company’s network. Having those folks be able to search for “gitlab add file” or “github clone repository” and apply it will save you time. In the same vein, don’t use a mono-repo type paradigm. There is a lot of pain involved in managing it, and having one project per repo makes things much easier.

Best of luck, and congrats on having the department want to move to KiCAD.

14

git is not a cad tool and was not… Training engineers to use git is not part of designing PCBs or learning new cad… The absence of this function is a disadvantage of kicad no more and no less… And given the great work on implementation and setting up kicad to work with git, you need to think very well… From each new version, bugs appear and library formats change and all this can be changed with your hands, and if you have a team of developers, then change each

1 Like
15

I like learning. I have a long list of things I’d like to learn. I’d like to have a skill in using LibreCAD, FreeCAD, Inkscape, Gimp and even a LibreOffice writer with using all possibilities. I also planned to learn Java, C# and Python.
Unfortunately day has only 24 hours. When I came back from work (typically 21…22) not a lot of time lefts. This year I have made a big decision - I stopped going to work at Saturdays and with a few exceptions, it does.
About git I have read first time about 2…3 years ago here at KiCad forum. Never heard about it before.
Please give me some arguments that will make me add git to my list, and to the top of it.
What I should read to understand basic concepts of git?
Learning details is much easier when you see the whole picture and I think it is often hard to find at first such not focused on details information.
Have you some such “git for dummies” links?

1 Like
16

When I came back from work (typically 21…22) not a lot of time lefts

What do you do for work? Since you know a lot about electronics, i assumed your work is also in that field and that would make learning such tools part of work.

Please give me some arguments that will make me add git to my list, and to the top of it.

Why a VCS in general:

  • Know when, why (assuming you write your commit messages in a good way), exactly what and, in case of a team, by who a commit (change) was made / a line was changed/added.
  • Go back to any previous version in case something breaks. Not only that, but you can remove single commits of the past when a single change turns out to cause problems.
  • One single folder for a project, without 100 subfolders for each version. (Which also reduces disk space usage). And there don’t exist a “large” amount of files which all have the same name, but have different version in different folders (reduces potential confusion on which version you actually used to do something).
  • Test new things in new branches. A simple command or a few clicks, and everything you do is only applied to a test branch and you can switch between your test branch and master branch easily.
  • In case you go back in history (or use a different branch): You can apply single commit from a different branch or from the future.
  • You can merge (combine) different branches.

Why a distributed VCS, such as git:

  • Work on a project without access to a server and with less worrying if you have to latest version (in many cases, you can later merge both versions).
  • It is easier to backup and keep multiple repositories (where your project and the history is stored), since you can easily compare them, when only one repository has commits not done by the other, you can apply this commits to all of them and when both have commits not done by the others, you can merge them.
  • Easy to share your work with others. You can continue to work on your project, someone else can clone it, makes his improvements and when both parties agree, you can import his improvements back to your project.

Note to the merges and applying changes from other branches: This works well with software, written in normal languages (not something like labview), with EDA and CAD (except something like OpenSCAD) it is harder, and depending on the format impossible. It is somewhat possible with KiCAD and there are improvements in this regard when you move from KiCAD 5.1 to KiCAD 7.0. But other VCS features still work well.

I knew i had to learn a VCS, after a long time i finally started to learned git, took a few (work) days, and since then it improved my workflow a lot, i don’t want to develop software without a VCS and i use it also for PCBs, CAD and other projects.
In case you write software or work in teams, i highly recommend it, it is almost a must. In case you don’t do software and your KiCAD projects are done alone, it is still very useful tool but not as important as it is for software.

2 Likes
17

For many years I thought I was an entrepreneur (word from Google translator - I have never seen it).
But once an economist made me realize that what we do is really a form of self-employment.
We (I, my brother and my friend from study) have a small electronic firm, and instead of being a manager we do ourselves a lot of work needed in such firm. All our devices are designed by me and my brother. My friend takes care of manufacturing and selling.
Designing schematics, selecting elements, library managing, PCB design is typically enough for one man. But I also have to be up to date with EMC, LVD, RoHS, RED directives and have to read current versions of standards harmonized with them, and I also write all programs we use during manufacturing and some to configure our equipment by users (embedded programs are written by my brother and programs for system users are written by our employee).
There is so much work that no matter how much time you spend on it, you won’t be able to do it. Specially last year when AtXmega disappeared and we are trying to make as fast as possible new versions of all our products we designed during last 10 years learning to use new microcontrollers.
We never had enough capital to simply invest in a large and rapid development of the company (before we set up our firm in 1988 I was academic teacher earning about $13 per month (not a mistake)).

As I have never taken part in any software writing team I know nothing about git.

At the beginning of main file of my production program there is 2000 lines comment with dated information of each change I made.

As I have daily backup I can easy get back to my source from specified day.

I have only one folder and one (current) version.

+ for git.
I can’t do it without making a second copy and then it would be hard for me to tell difference. But I never do it.

I planned to note other git pluses but suddenly (not intentionally) I posted what I was writing. So I stop here.

18

Working with VCS/git is something you have to learn before you can really understand the benefits. It involves a way of thinking with branches, versions and commits in a way that is hard to describe to someone that never learned to used any VCS properly. And you do it a lot faster than with daily backups. (switch back 30min or so)

(I was about to post a really long comment (again), but since it is hard to understand when you are not familiar enough with git, i don’t).

19

Ok, can’t let this one lie untouched. This reads like “can’t learn” = “won’t go scour the internet and figure out how git works”. The documentation and set of clear instructions for your design flow is a requirement for a professional environment, not something you stoop to so that the old engineers can learn. If you can’t document the process, then it means that either the process is too complex, or that you have not thought it through well enough to document it. If you won’t document it because you are too busy, why would you assume others are not too busy to learn?

John

20

As they wrote above, the main problem is not git but support from the kicad… This requires a lot of manual work and without any guarantees that when updating the stable version, everything will work with the projects done before… In fact, you just need to see how it is done in other cad for a percentage of labor costs and the expected result