Trying to update PCB from schematic

So, I find I made a mistake in my schematic, but trying to translate the fix to the PC board has been a headache.

I generate a new netlist and load it into PCBNew, selecting ‘Keep existing symbol…’ and ‘update footprints’, and it insists on generating a complete duplicate ratsnest.

The one time it didn’t (can’t recall what I did), it instead broke the layout of all the through-hole parts.

A full duplicate ratsnest is also generated when I click ‘Update PCB from schematic’ button directly.

Fine, it won’t update the ratsnest to add the grounds I’m missing.

So, I go and try and manually route the traces to ground, and the trace will NOT complete at all, the ‘shove’ routing function kicks in.

Now what?

(macOS Big Sur, KiCAD 5.1.7)

I’m not a Mac user, but you should be able to update the schematic, Save the file. In Pcbnew click the update icon and that is all you need to do. In 5.1.x you don’t need to netlist.

PCBnew will not let you connect items unless they are on the same net. You can’t run a trace to Gnd unless it is connected in the schematic.

Is there a chance you have multiple files and the names don’t match?

First:
The direct “Update PCB from Schematic” is the normal and quicker way. First creating a netlist and then importing it in Pcbnew is the old way, and it is mainly maintained as an interface to external programs and scripts.

There are two ways in which KiCad can match schematic symbols with footprints on the PCB, and you can switch between these two by selecting the “Match Method” during “Update PCB from Schematic”.

( * ) Keep existing symbol to footprint associations
This uses the “Timestamp” (KiCad V5) or “UUID” (KiCad V5.99 / V6) to make the match. It is just a unique number that is both present in each schematic symbol and each footprint. This is the default way for synchronization.

( * ) Re-associate footprints by reference
This uses the RefDes (A.K.A: Reference, Reference Designator) to make the match. This method can be used to repair broken links.

If you have for example deleted a diode from the schematic, and then put a scottky diode in it’s place, then both the Timestamp and RefDes are lost. In this case you have to change the RefDes to the same name as it first was, and then use the second match method (Re-associate by reference) to create the links between Eeschema and Pcbnew again.

You also have to fix the footprint links. One way of doing it is:
Pcbnew / File / Export / Footprint Association File … and then:
Eeschema / File / Import / Footprint Association File …

You probably used the “Re-associate by Reference” method here, but I do not know what you mean with “broke the layout of all the through-hole parts”. The “Update PCB …” does not change anything of the copper tracks on the PCB.

If you’re still stuck after this, then save the “Changes to be Applied” from the “Update PCB” dialog (there is a button for that) and post the file here, together with a description of what goes wrong.

You can also zip the whole project and post it here, and I’ll have a look. You can also do this with a copy of you project which has most of the schematic and PCB removed to make it smaller. Just make sure there are a few of the problematic components left.

1 Like

I just tried a technique and now I wonder if it should be the suggested method for changing a symbol in EESchema because it maintains both the Ref’D and the Timestamp. (FWIW, I’ve only tried this in 5.1.8 thus I’m using the term Timestamp. I haven’t tried in 5.99 because I haven’t installed that anywhere.) For the screenshots in this example I’m changing an OP07 to an OP77.

  1. Enter the symbol properties editor: Right click on the symbol and select Properties/Edit Properties... or press E while hovering over the symbol.
  2. Change the library symbol: Next to the Library Reference field, press the button with the books icon, circled in red. Select a new symbol from the Choose Symbol requester.
  3. Take note of what has changed and what hasn’t. In the screenshot the only thing that changed is the symbol library reference, boxed in with green. The Ref’D, Footprint, and Timestamp (labeled Unique ID in 5.1.x) have not changed, and we don’t want these to change, boxed in with blue. The Value and Datasheet also have not changed but we do want to update these, boxed in with peach. Now press the Update Fields from Library button, circled in red.
  4. The screenshot shows the default values. Change the selections to what you want. In this case I would unselect Footprint (I know that I’ll be using the same footprint) and select Value and leave datasheet selected.
    2020-12-05 14_25_45-Update Symbol Fields
  5. Take note of what has now changed. The Value and Datasheet have been updated with the correct values for the OP77, boxed in with green. All the things boxed in blue did not change since the last step, most importantly the Timestamp (Unique ID).

Using this technique one doesn’t have to remember to change the method of updating the PCB with the new information. One just needs to remember to use this technique instead of the impulse to delete and replace (like on paper where one would erase and redraw).

Indeed, just changing the library reference in the properties of a schematic symbol maintains the link to the existing PCB Footrprint as SembazuruCDE wrote, and is therefore the preferred method.

Beware though, that the new library reference may have the pins numbered differently.

This function is also available in KiCad-nightly V5.99, but the button is in a slightly different place:

Yeah… for simplicity of my example I used a symbol and its alias (Graphics don’t change). And not knowing the parts, I really don’t know if the footprint that I chose is appropriate for either opamp. I chose one from the filtered list in cvpcb to have as an example and pretended it didn’t need to change.

Not sure how Sembazuru’s posts pertain to my issue, but okay…

I’ll just leave this here in the meantime.

pcb update issue.zip (93.4 KB)

Any suggestions for my issue?

Found another rookie error (used the ‘AAC’ LED symbol instead of the ‘ACA’ one I intended); after the prior round of posts I simply wound up having to redo the whole board layout from scratch. I’d REALLY like to avoid doing that again.

You’ve apparently been sitting on this for two weeks.

I’m not sure what the issue is, apparently some things can’t be routed to GND.

Maybe I’ll figure something out when looking at the posted project…
First thing I noticed is that the executable flags of 4 of the files are set ???

Is that a thing of that fruit brand computers?

paul@medion:/home/3TB_WD_Blue/projects/kicad/FCT_Board$ ls -hl
total 808K
-rwxrwxr-x 1 paul paul  43K Nov 27 14:32  Emetcon.lib
-rwxrwxr-x 1 paul paul 633K Dec  3 20:44 'FCT board.kicad_pcb'
-rwxrwxr-x 1 paul paul 3,8K Dec  2 08:04 'FCT board.pro'
-rw-r--r-- 1 paul paul  99K Dec  7 05:31 'FCT board.sch'
-rwxrwxr-x 1 paul paul 3,3K Dec  2 20:44  Grayhill.kicad_mod
-rw-r--r-- 1 paul paul  14K Dec  7 05:42  report.txt
-rw-r--r-- 1 paul paul  567 Dec  7 05:55  summary.rtf

After that I noticed a bunch of [ ?? ] symbols in the schematic:
image

This looks alarming, but is quite normal if a library is missing.
It wants to get those symbols from a resque library, which you’ve probably removed from the project, and the [project]-cache.lib is also missing.

After that I had a look at the PCB.
It reminds me of a project mentioned here recently with 20 IC’s and a bunch of 7-segment displays, and a change from 2 to 4 layers.

Then I did: Eeschema / Tools / Update PCB from Schematic, in combination with Re-associate footprints by reference. This fixes the issue with the netlist missing. After update of the PCB, lots of ratsnest lines appear:

The 7-segment displays look un-routed, when looking closer at the left top corner, it looks they got moved at some time after routing:
image

Apart from that it looks like the standard issue with Auto-routers. They route 90% percent of the board, can’t get the last 10% done and leave you with the mess and no room for the last 10%. Looking a bit further at the upper left section it does not look as bad as I first thought. The pins there look like they’re routed but still show ratsnest lines. I have not looked into that further.

Follow the highlighted track, typical auto router artifacts:

So the issue seems to be that synchronization between the schematic and the PCB got lost, and I fixed that by using the Re-associate footprints by reference radio button during the Update PCB from Schematic process. I think that is the point where you got stuck. The rest is just some hard work to get the routing fixed.

[Edit] Indeed, here is your other thread:


After the radio button you missed in re-synching the PCB with the schematic your biggest issue is probably your expectation of the “autorouter”. It’s not a “run and finish” thing, and your current result is fairly typical for a beginner in PCB design. Lot’s of experienced users do not even bother to use an autorouter even if it is available, and that is part of the reason there is no autorouter in KiCad itself.

1 Like

That might be a case of “copied from FAT formatted thumb drive”.
I believe even those fruit computers can handle POSIX permissions.

Look more like the footprints were rotated 180 degrees around pin 1.

Rotated… could be, on the other side there also was a connector that looked rotated.

Looking at the original PCB these footprints look fine, so apparently I did it myself during update and syncing.

Apologies for forgetting this thread… let’s just say it has been an inauspicious couple weeks.
Hope my oversight of this thread can be pardoned.

iabarry’s note above made me realize what has been happening, and I am sorry for wasting everyone’s time.

As KiCAD currently lacks an autorouter, I’ve been using DipTrace for that functionality, importing the board then exporting it back out as an Eagle file for reimport into KiCAD.

Clearly, the multiple file format conversions are stripping critical information from the file, causing the links back to the schematic to break. (and playing merry havoc with designator placement!)

(…as atrocious as autorouters can be, and I’ve seen a few beauts in my limited experience with DipTrace, they are still useful for suggesting where the traces need to go, after which said traces get relaid cleanly and correctly)

Now, just hand me a dunce cap and I’ll go and stand over there in the corner.

Nonetheless, if you insist on this workflow and can figrure out why that rotation of footprints happens, (I assume rotation information gets lost during the diptrace cycle) then you can reload the netlist after the autorouting and continue from there.

I’m not sure where or how you got that rotated footprint.

I had to go back to the drawing board once more, and this time, I was careful to go over every inch of the schematic during the layout phase, and had to swap gates around a couple times to help with the rat’s nest arrangement. Once I was satisfied with the physical / electrical layout, THEN I went through with the cycle through DipTrace.

I just need to be [censored] certain that the schematic and layout are set in stone before doing the export and re-import cycle, and expect that I will have some cleanup to do once re-imported.

Incidentally, this cycle introduces an interesting artifact - the original designator gets broken off as free text, but a second, hidden, copy of the designator is left underneath the footprint. Part of my post-import cleanup entails removing the broken-off designator and moving / making visible the other designator (done while addressing concerns pointed out by the design rules check).

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