How to handle US vs Chinese parts?

Hello all,

I am doing work for a client. They lost the original design files but they have PDF copies of the schematics and gerbers. I am essentially recreating what they had in KiCAD (the previous person used Altium)

I have run into some parts that they sourced from Chinese companies. They want to go to manufacturing relatively soon. Anyways, given the current US and China political climates (tariffs, leaders, etc.) I strongly advised against using Chinese sources for components as sourcing the components and getting finished boards in the US may prove to be difficult in the future.

They mostly accepted that idea. They are going to have other CMs (non-Chinese) work on doing the PCBA. However, for the components, they do want a US option available should things really go downhill. There are a few components that are not a 1:1 sub.

So since I am working on the schematic right now, I would like to have a way to include the Chinese components and the US components. What are some ways that I can setup the project/schematic to reflect this? Or should I have 2 separate projects?

You can include both on the schematic and select them (make them Fit or No fit) based on the “variant” US/China.

I use a plugin called KiVar to help me do something similar.

This caters for your schematic and BOM, it won’t make changes to your PCB in terms of layout. . . .

Thanks, can you explain it a little more by making them Fit or No Fit?

For components that are a direct replacement it’s easy, you place and connect both on the schematic, for the US variant you mark the Chinese part as “No fit” . . . Exclude from bill of materials and Do not populate

image

For parts that are not a direct replacement you could use dual footprint on your PCB and do the Fit No fit option.

Perhaps this way is “overkill” for your application, but I’ll mention it anyway since it is kind of the standard in the commercial world:

Use a PLM system which creates and tracks internal part numbers (IPNs) for any components you use in your designs. In your CAD tools, only refer to IPNs, never to manufacturer part numbers (MPNs). The PLM system will let you designate one or more MPN for each IPN, and is the “source of truth” for your bill of materials.

This adds complexity and layers, but since CAD tools (including KiCad) are really not built for managing supplier data and other part lifecycle requirements, having a tool that is meant for this can be really helpful.

If you go this route, then you no longer use the BOM exported from KiCad as the source of truth for what to manufacture. Instead, you import this CAD BOM into your PLM tool (usually) and then from the PLM tool you download the “real” BOM which includes multiple possible manufacturer parts for each internal part number.

Note: this method only works where you are concerned with form/fit/function compatible alternate parts from multiple manufacturers. If the alternates you are concerned with are not actually compatible, then you need to actually have two different (slightly different) CAD designs. This would be accomplished with a variant system once KiCad has one (which it doesn’t yet, at least not built-in, there is the KiVar plugin though) or a DNP-based method can also work as @RaptorUK described.

4 Likes

My private solution would be to first make the full project with elements from the source that they are generally bigger. Then I’d copy project under different name and replace these elements. Changing from bigger to smaller should be easier then the other way around.

As was said, it really depends on whether you have only one footprint for each part and two possible sources, or two components which require different footprints.

In the simple case the most simple solution is to just have two different fields, for example PartNumberC and PartNumberU. I don’t see anything special here. Just select one of those two fields for the BOM.

You can even give the same Label for both in the BOM generator so that the field name is always the same and doesn’t depend on the symbol Field name:

I haven’t used database libraries, but I think this system, too, can be combined with a database and two different “house part numbers”.

Hello,

I like your ideas. I am trying to visualize how this would work on the actual schematic part. I think that there are alot of ideas in relation to the BOM and I like their appraoch.

One thing to note is that for some of the components, these are ICs. Their functions may be similar but their pin outs (and packages, and footprints) are all very different from each there (ok, maybe not that different. One is a QFN 24 and another QFN 64 for example). And then the next question is how this would look like for the BOM

So I am wondering if I should have 2 sheets of the “same” circuit. One for US and the other for Chinese.

I’m getting the feeling that the layout is going to be sufficiently different that you are going to end up making 2 projects in the end . . . maybe make one then use it as a basis for the second. Pity, as if you then need to make any mods you will need to do it twice.

1 Like

I would not make this kind of change in the BOM. I would make two entirely different projects.

Sometimes it’s too much work to turn a terrier into a parrot. Search for “Monty Python pet conversion” to understand. :crazy_face:

Another option is to use KiBot and its variants feature. I’ve used it in the past and it was very easy, because I used KiBot in my setup already.
The only issue is, that the variants works great for schematic, but do not work in PCB. So you basically need to have both footprints in the PCB and it will manage to set the correct flags in BOM, position files, etc…

Hello all,

Thanks for the feedback. @Kedarius I haven’t used Kibot yet but I did look into it some time ago and I do feel that it is a very useful thing for me to start using. I will take a second look at it. Maybe this will get me started using the tool

I also was thinking that since I have this under source control, I can just develop it out using Chinese components (also noting the US subs). Once I have the schematic where I want, I can create a branch off of the Chinese one that is for US components. That way I can kinda have 2 different schematics/layouts under 1 project.

Unfortunately, the biggest drawback of using KiCad with version control is the merging. While I advocate for using git with KiCad, and it makes it easier with the automation, etc… the biggest issue is that the KiCad files are not made for text editing (obviously). The format got better over the years, but still merging two branches is tedious work… So expect that if you split it into two branches, you will never merge them again, and you will need to do all changes in both of them…
I still think that it is the best option, but I just wanted to give you an advance warning :slight_smile:

This is only a drawback if you try to merge things. While this point is a common thing raised, in my experience it is perfectly possible to use version control while never merging anything, which works quite well with KiCad (and any other software where merging is non-trivial)

This limitation with merging is inherent to any format which tries to represent 2D or 3D data. Text or binary, the file is always one dimensional. It’s not about optimizing the file format. I mention this in Pros and cons of using a VCS (git etc.) with KiCad and it’s explained with examples in Tools for cooperation?.

That’s exactly what I wanted to say, I hope it did not sound any different…
I strongly advocate to use Git with KiCad and I am using it for all my projects, however the inability to merge things is a big obstacle in a multiuser environment. While with for example software development you can have multiple people working on the same project at the same time and “all” you need to do is to merge their work afterward, the Git+KiCad workflow is limited to one engineer or very small team, that can manage to avoid conflicts without the help of the versioning system…

I disagree here. Git+KiCad workflow is fine for a large team. The only scenario it doesn’t work well for is the scenario where you want to have more than one person working on the same thing at the same time, which in my experience actually just doesn’t come up that much.

At work we keep all our CAD designs in a single Git repository and have many people working out of it. It is far more common to have many people working on many different projects, than several people trying to work on the same PCB layout at the same time or something like that. In fact we almost never try to do the latter, and it’s fine.

I know and I partially agree. While it would be a nice theoretical debate, how many dimensions does the file have, the most important part is how good are the tools for merging.
For example, if KiCad would have a nice UI for merging two/three versions together, it would be very easy to merge KiCad projects, and it would not be important whether they are 2D,3D or nD…

And that is exactly what I referred as

You have rules/colaboration techniques (“Hey John, you still working on that PCB?”) to avoid the conflicts by not working on the same files…