Netlist severely messed up

I don’t know how I did it (See my previous post: Cutting and pasting part in schematic makes new part in PCB - #8 by RChadwick7)
When I ran DRC, it found a lot of wrong nets, mainly on these driver chip outputs. When I fix those, every one I fix makes an extra schematic parity error:
Warning: Pad net (Net D12-A2) doesn’t match net given by schematic (D12-A1)
So basically when I fix one error, it generates another. When I fix the second error, it brings the first one back. Update PCB from schematic seems to just make things worse. At one point I had all the errors gone, everything looked good, then I ran Update PCB from Schematic and I had a ton of errors. To complicate matters, I have non-polarized parts on the output of these chips and I thought I could fix the errors by switching the pin numbers, then realized the net numbers look based on those parts. If it was a small PCB I’d just re-do it but it took a while to make. I’d also like to know how to fix it and/or how to avoid doing it tin the future. Any help would be greatly appreciated!

It sounds like the root of most of the problem is the use of cutting/pasting symbols and/or footprints without doing the appropriate re-linking step afterwards.

KiCad normally uses unique identifiers (an internal code that is not really shown to you, the user) to establish the link between a symbol and a footprint. This allows you to re-annotate symbols (i.e. change a reference designator from R1 to R2) without KiCad mixing up which footprint is supposed to map to which symbol.

When you cut and paste a symbol, you are actually deleting one symbol and creating another one that is new. The pasted symbol will not have the same unique identifier as the cut symbol, even if it has the same reference designator assigned.

To handle this, the “Update PCB from Schematic” dialog has a special function: Re-link symbols to footprints based on reference designators. This function should be used with care, as keeping it turned on normally can cause other problems, especially if you are changing the annotation of symbols later.

The general process when you want to move symbols from one place to another within a schematic using cut and paste is:

  1. Make sure, before you start, that the schematic is fully annotated.
  2. Make sure, before you start, that the PCB has been synchronized with the schematic. In other words, “Update PCB from Schematic”, with the “re-link based on designators” box un-checked, should report that there are no changes.
  3. Now you can cut and paste symbols in the schematic. If you skip step 1 or 2, you will run into problems!
  4. After you have cut and pasted all your symbols, and before you do anything else, Run “Update PCB from Schematic” with the re-link checkbox turned on
  5. Now proceed with the rest of your design work, making sure to turn the re-link checkbox back off the next time you update the PCB.
1 Like

I already posted step 4 yesterday in the thread he linked to, and added that step 5 there also when you were still typing :slight_smile:

I guess it would have been better to not start a new topic here, or maybe even merge it back into the old topic.

Thanks for the help. I was debating whether or not to continue in the original thread as this seemed to be a separate issue from the title of the thread. I have run Update PCB from Schematic without the re-ink checked. No extra parts arrived this time. I still have a lot of issues in the DRC. So, hopefully these will stay fixed if I fix them now? It was just leaving the re-ink checkbox checked?

After some work, it seems I still have the same issue. As an example, D11-A1 and D11-A2 are outputs of this driver chip, going to the non-polarized part I spun around to make 1 connected to A1 and 2 connected to A2, and the output connector, which I needed to cut, mirror, and replace. I run DRC, and it seems the output pad of D11-A1 is connected to traces that are D11-A2. I check on the schematic, and this pin is supposed to be D11-A2 so I change the traces to D11-A2. DRC shows problem is gone. I do more of these, The number of errors is dropping in the DRC. I run Update PCB from schematic and I get more errors. Errors show up as unconnected nets as the traces connected to the pads are connected to different nets.

Yes, it is just a checkbox, and it does not change by itself.

After clicking a bit, it appears to be a system wide setting. If you set it in one project, then switch to another project, it has the status you set it to in the first project. I think you could consider this to be a bug.

But the more important issue:
I do not know the cause of your troubles. I can examine it closer if you are willing to zip up the project and upload it here.

FreedomWavePD-1.3.zip (907.5 KB)
Here it is, thanks for the help!

I never would have figured it out without the project.

During editing you made a few mistakes, and these mistakes got hidden by an unfortunate combination of circumstances.

First, you used different orientations for the TVS diodes in the schematic. Some were “upside down”, but you can’t see that in the schematic, because the symbol for this bidirectional TVS diode is symmetric. I put them all with pin 1 on the right side of the PCB, and rotated and mirrored some of the schematic symbols where needed.

The second mistake is that you mixed up the wiring between the “electronic part” and the “connectors”. I temporarily fixed it by drawing the wires to 6 of the motors in an “X” configuration.

The problem got a lot more confusing because KiCad generated the net names from the TVS diodes that were swapped. KiCad also got confused because of the crossed wiring between the motor drivers and the connectors.

On top of that you also have some library issues. Your project has a FreedomWavePD_2.kicad_sym-2.kicad_sym file in it, but it is not used. If you look at Project Manager / Preferences / Manage Symbol Libraries / Project Specific Libraries then you see that the library that is part of the project is very far away in some backup directory of an older version. In newer versions of KiCad this does not matter much because the schematic has local copies, but it is not the way it should be.

Below is your modified project back. As written above, I rotated some of the diodes, and changed wiring in the schematic (the 6 “X” parts where wires cross).
2023-10-27_FreedomWavePD-1.3.zip (313.1 KB)

Thanks so much!!! I had this completed and ready to go (No serious errors) when I realized I wired the driver chips and output connectors randomly. It could have been fixed in software but my prototype wouldn’t work. I also needed to flip the numbers on the output connectors, which led to cutting, mirroring, and pasting. I tend to get confused with a lot of wires and somewhere I lost control. As an attempt to fix it, I noticed the nets seemed to be based on the TVS diodes so I purposely flipped some of them in an attempt to fix the issues. Obviously that just made things worse. Seriously, I GREATLY appreciate your help and time!

1 Like

It is indeed likely that it started with the flipping on the pins of the motor driver schematic symbol.

But do consider I only fixed the DRC problems. because of the “X” connections I made in the schematic, some of your motors will probably turn in the wrong direction. It’s easy to fix now you know what happened. If you get confused again, use the highlighting function in KiCad to sort out connections (combined with the cross probing when both the schematic and PCB editors are open at the same time). The highlighting function quickly showed that pads belonging to different nets were connected with copper tracks. If this happens again, an easy way to sort it out is to remove some copper tracks, so any copper is only connected to one net, and KiCad can properly name the copper tracks.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.