KiCad in Industry use

Software
1

Background / context
At work, our default tool is Fusion 360. We use it for mechanical design and PCB design (i.e. the Autodesk electronics module). All our existing circuit designs, PCB’s, and libraries are built in that system. But we frequently run into frustrations with the PCB side of Fusion: features are lacking, the tool misbehaves in edge cases, etc. Still, management is reluctant to switch away because it seems like a big investment—especially since Fusion already “works” for everything (at least superficially).

One of the main objections is: KiCad doesn’t have a solid built-in version control / collaboration interface. Also, there’s no turnkey organizational system or workflow, so switching means someone needs to build process and tooling. The leadership doesn’t want to invest much time in that.

So here’s my ask:

Questions / things I’m hoping you can share

  1. Team workflows in KiCad — How do you organize a multi-person team using KiCad?

    • How do you share and maintain common libraries (symbols, footprints, 3D models) across the team?

    • How do you keep them versioned / synchronized?

    • Do you use Git (or other VCS)? Any tricks / conventions / best practices to avoid merge conflicts?

    • How do you control who is allowed to make changes to core libraries vs local project libs?

  2. Collaboration on a project — When two or more engineers need to work on the same PCB or other parts of the same project, how do you split work to avoid conflicts? Eg separate sheets / modularization strategies?

  3. Bridging Fusion / KiCad workflows — Since our mechanical design (in Fusion) is integral, is there a decent way to integrate or interoperate?

    • Can we import/export relevant data cleanly (e.g. 3D models, footprint shapes, board outlines)?

    • Is there a path for migrating existing component / footprint libraries from Fusion to KiCad (or regenerating

  4. Tools / infrastructure — Are there existing plugins, services or infrastructure that make KiCad more enterprise-friendly? (e.g. visual diffs, library hosting, web previews, review systems)

  5. Caveats & challenges — What issues or pitfalls did you run into when using KiCad in a company / team context, and how did you mitigate them? E.g. merge conflicts in PCB files, broken library updates, compatibility issues, onboarding new team members, etc.

  6. Migration strategy — If you were me and wanted to propose a gradual migration, how would you phase it? What’s the lowest-risk path to get started with KiCad in a team that’s already heavily invested in Fusion?

If you could share your real workflows, scripts, repo structures, or war stories from your professional environment, that’d be amazing. Thanks in advance!

1 Like
3

You switch from the libraries distributed with KC, to a set of tightly controlled ‘company libraries’, you also switch to a Database Library, since your organization has one central DB for sure.
Some man hours could be needed to achieve this. :slight_smile:
You organize one person / small group that is the only responsible of library editing.
You deny direct push on the libraries by the general public of designers.
You define the KC version all the designers/library maintainers should use.
You do not allow the use of local libraries.

this is a question that can be answered studying how the versioning SW works, in my organization we use Git and SVN both for SCH/PCB/3D libraries and projects.

we (small design laboratory of around 10 persons, integrated in a much bigger organization) managed to do the complete switch in around 1 year (but it was very clear from the start what we needed to achieve and we didn’t have to convince any corporate 3^rd part body of the change)
and we had very compelling reasons to do so.

this does not sound as compelling enough to me. Also in KC features are lacking (see github tracker to have an idea of how many) and edge case are just like that, edge cases.

This is the most valuable suggestion.
I’ve experimented a lot with porting form $$$$CAD1 → $$$$CAD2 → KiCad, since a direct importer was not available. It was a painful experience, lots of details were lost in translation
and now i doubt it was worth the effort.

3 Likes
4
  1. You have a common repository that everyone creates PRs for the part they want to add. Then you have someone else check that part to make sure it’s correct and then merge to main. You do not allow local libraries and you shouldn’t be allowed to push to main if not authorised.
  2. I actually made a post about this here. Works but you need to be careful with certain things. I think it’s the best way of collaborating we have right now.
  3. You can export DXFs and import that as a graphic to your PCB layout. Not sure about the rest of the things you mention.
  4. There’s KiRI which is a really cool tool that does visual diffs for both schematic and layout. For web view you have KiCanvas but I remember there was another project manager thing that I’m not able to find now. EDIT: Found it, cadlab.io.
  5. Worst part is versioning because you can’t really read what someone changed in a git diff. You would have to use KiRI each time I guess but it would be nice if it was more integrated.
  6. I don’t know unfortunately as I’ve never used Fusion for PCBs. Check if KiCad can import Fusion schematics or layouts. I doubt the parts libraries will work. Lowest risk path would be to try to convert current projects to KiCad and if that’s not available then just start new projects with KiCad and over time the migration will happen.

Good luck!

1 Like
5

Use Git to store all library data (symbols, footprints, 3D models) as well as all project data. Can be one big Git repository or multiple, just a matter of preference. You need policies/procedures in terms of avoiding merge conflicts, more than technical measures. There should be a small number of people with permissions to change the library and those people should collaborate to avoid merge conflicts (e.g. two people trying to change a symbol library at once).

Don’t use local project libs.

My first take is that in general, you don’t need to do this on 99% of projects. One person does one project. But in the rare cases that it can help to have multiple people do a schematic: One person sets up the overall structure, then you use human communication to say “person B, you can work on the subsheetA sheet”.

Use STEP to go from KiCad to Fusion, use DXF to go from Fusion to KiCad. Same is true if you replace Fusion with any other mechanical CAD tool.

If the libraries can be exported in EAGLE XML format, then yes. If Fusion Electronics uses some new format and does not support exporting compatible with EAGLE, then probably no.

Others have already listed some, but I will also note that “enterprise friendly” means different things to different people, and e.g. we don’t consider any of the features you listed that critical at my workplace.

You need to make sure to agree as a team on what processes to follow (true of any EDA tool) and what KiCad version to use. You can’t just say “go download KiCad” without specifying a version since you don’t want random teammate X to be the one who decides when to move from KiCad 9 to KiCad 10.

If you have a multi-platform team (like Windows/macOS/Linux) you need to make sure to make a process for deploying onto new machines that accounts for the differences in paths between those platforms, and make sure that people set up their workstations the same way. There is some one-time configuration to do on each machine (especially if you use database libraries) so writing up a step-by-step procedure to follow is helpful. You can also include customization of KiCad’s settings from the default in this step, if desired.

Otherwise I’ve found there to be fewer pitfalls for KiCad than with some other tools. People teach themselves the basics of KiCad without needing any coaching or specific training, or they already come in knowing KiCad because they used it in other jobs or school/hobby projects.

First see if it is reasonable to share libraries (I’m not sure whether or not Fusion can use the same libraries as EAGLE or if they are changed in incompatible ways). If so, you can consider doing some kind of gradual migration of the libraries. If not, you need to make a plan for how to set up your KiCad libraries from scratch, and gradually start adding parts to them as needed for new designs.

My suggestion for migrating projects and PCBs is: don’t do it. Keep Fusion around for all existing projects. Use the new tool for the new projects. Migrating designs is in my opinion a waste of time unless you no longer have access to the old tool. Migration from any EDA tool to any other EDA tool is never going to be perfect and is always going to take up time to carefully check for the imperfections and fix them up. If you don’t 100% need to do this, it seems like a bad use of resources.

2 Likes
6

For the libraries… For a company it’s often better to use the database driven libraries. KiCad “only” provides an interface. This has the flexibility that it can be integrated with an existing database. There are quite a lot of companies who used a database with some other system, and with a few changes to the data could use their whole database in KiCad. With an external database you also have much more control over inventory management, parts ordering, substitutes, etc.

For working on the same schematic / PCB by multiple people at the same time, there is no direct solution for this. Maybe you can find a partial solution in the new “Design Block” system in the Post-V9 New Features and Development News - #45 by mikebwilliams thread.

As a Post V9 thread item, this is only in the nightlies. KiCad is in very active development, and there are now already over 50 new features in that thread. And this is common, >50 new features are added to each mayor KiCad release (released once a year around February).

7

This was answered already, but you can find some basics in the FAQ Pros and cons of using a VCS (git etc.) with KiCad.

8

Some impressively helpful suggestions already, given the scale of these questions! Effective team workflows are hard won, regardless of the team or the workflow!

My 2c:

Subversion works fine. Having text based files is glorious. Other VCS would be fine too, but Git encourages processes like merges, which aren’t necessarily constructive outside software development. My number one strategy for avoiding merge conflicts is to avoid merges. Instead, use human coordination to avoid working on the same thing at the same time. A KiCad library consists of individual 3D models, individual footprint files, however the symbols are in one file. So you might want to coordinate changes to that file.

For example, at one point we allowed one engineer per project with free reign over a local library, and then would batch “promote” parts from project libraries to the common library. These days I prefer working directly with the common (database) library, but if you don’t coordinate and communicate changes to a common library you’re asking for trouble. One rule saves a lot of heartache - always grab the latest before starting a change.

If and when coordination fails, a merge is still possible, thanks to the text file format. Just don’t trust git to do it.

Subversion also supports the old lock-modify-unlock workflow, which could be worthwhile here.

I’m certainly not interested in enterprise-friendly, but I know those that are see a lot of appeal in AllSpice. It was probably created to allay exactly the kind of concerns your organisation might have. It’s basically Git for EDA tools, designed for teams without existing good version management practices, and comes with a thousand enterprise-friendly buzzwords built-in. Surprise, surprise, it’s “AI-powered” as of fairly recently.

9

KiCad does have a built in diff that can show differences both as text and graphical for symbols and footprints. It is in the Inspect menu.

10

That’s awesome. It’s just between the footprint/symbol and the one in the library right? Not, say, between versions of a library or versions of a pcb/schematic?

1 Like