“Reset Existing Annotations” messed up my PCB

In my case the source of the problem was clear. I had the “Reset Existing Annotations” check box ticked from earlier on, so when I updated the pcb from schematic it first reannotated everything. When this was subsequently loaded into the pcb editor it made a complete mess of everything - a part that was previously C4 say became a different capacitor somewhere else, so all of the connections and everything was completely wrong. It was so bad, I’m sure my blood pressure spiked pretty high that day.

I couldn’t/didn’t CRTL-Z back because I’d made quite a few changes to the schematic, so while I might have been able to revert the pcb, the schematic was not going to be that easy. In the end I used an autosave.

Not strictly a crash but it was a significant software fail, I guess initiated by me but I’m sure it wasn’t expected software behaviour. Apart from that I haven’t had many real crashes (ie core dumps back to OS) at all, maybe two over the years.

Lastly while I’m happy to upgrade each time an official release comes out, I steer clear of the overnight builds or the beta builds. You’d want to be pretty keen to use those unless you really need one of the ‘new’ features.

1 Like

Faulty diagnosis.
That is not a problem at all. re-annotation on itself does not break the project, because normally KiCad uses (invisible to the user) UUID’s to track the connections between symbols on the schematic and footprints on the PCB. Nearly always the real problem here is the Re-link footprints to schematic symbols based on their reference designators. That option should (nearly) always be OFF. It should only be on (once!) in some special cases, such as re-synchronizing the PCB with the schematic when both are imported from some external source.

3 Likes

Just had a look - this option is indeed on. Not sure when it was turned on, or why it didn’t make any difference any of the other times I subsequently used the “update pcb from schematic” function after my issue. However I’ll keep an eye out for it in future.

Assuming this is indeed a user error then I have to say my experience with new versions to be even less problematic.

As long as both the RefDes and the UUID’s map symbols to footprints in the same way, you don’t see any problems with Update PCB from Schematic [F8]. But if you re-annotate the schematic and the update the PCB while the re-annotate is on. You change all connections. Symbols with the new RefDes get connected to footprints with the old RefDes. And this will definitely create a big mess in your project.

Sometimes I wonder whether it would be better if this checkbox was cleared automatically each time the dialog is opened, or at least each time KiCad is restarted. This reduces the chance on errors, while effect on real use is very small. Normally it’s used only once to repair a broken project. Maybe it can be run a few times after each other when there are problems with repairing a project.

For many years I used it (Re link by reference) practically all the time. I run Update without this option set only once near the end of design when I re annotate all symbols to have “better number order”.
My rule (to avoid some kind of mistakes) is to not change anything in symbol after it is placed at schematic. So if I want to change 1k into 1k5 I delete one symbol and insert new one giving it the same reference (then during Update reference have to be used and not UUID).
In V5 I had to write this reference manually. Later (V6 or V7) after I deleted one symbol then inserted automatically get the same reference (if there were no other free numbers).
I don’t know since what version there is Replace symbol with other one and if I remind it before just deleting the old symbol (for years I used to delete/add so it happens me to do it before I remind about Replace) than I use Replace. After Replace UUID is preserved and I can do Update with this option switched off.
I don’t know why I am doing it. This is against efficiency.
Del and then ‘A’ is faster then searching the replace function symbol in context menu. I didn’t noticed time difference in Update depending if this option is on or off so simpler/faster is to use del/a and Update with this option set.

This is a quite horrible workflow:

Each time you delete a symbol, you break the connection to the footprint on the PCB. And as a result you have to repair it again with the Re-link option after you inserted a new symbol. The value of a symbol (part) is just a simple line of text. It’s a quite convoluted workflow to throw away all the other stuff and break your project just to change a text string.

I’ve noticed quite a few times that you have … “unconventional” workflows. For example with layer usage and page layout (I do understand / like this last one)

This whole workflow you describe here seems “against efficiency”.

If you want to change a value:

  1. hover over a resistor, press v to edit the value field.
  2. Add a new text string.

That is all. Because it preserves everything else (including connection to the footprint on the PCB, location of text strings in the schematic and more, there is no need to repair anything either. At some future point you will have to Update PCB from Schematic [F8], but there is no need to do that often. KiCad just treats the Schematic (inclusive the UUID’s, RefDes, Values, etc) as the reference, and from there information propagates to the PCB.

There are two caveats I know.
Update Schematic from PCB is against the normal workflow and you have to be a bit careful of when and how you use it. The other is with database driven libraries. If you use those, then a “resistor” is a “real” part, which can have ordering info, tolerances, substitutes and other meta data attached. When you use database driven libraries then simply changing the value of a resistor is not an option, because then the old resistor may still be present in the BOM. Database driven libraries are powerful, but I have not used them (yet) as they need quite a lot of work to set up and maintain.

May be it is against efficiency in a speed sense of efficiency but is pro efficiency in a sense of stock you keep and limiting risk of ordering wrong PCBs.
For many years we assembled our devices ourself. If in some time before (for example to set LED current) I have used 1k3 then I inserted 1k3 into my library. If (years later) in some design I see a need to change 1k into 1k2 (more standard than 1k3) then if I would do it by just editing text I will force us to store one more value, but if (according to my developed over the years habit) I will try to replace it with new part from library than I notice that we have never used 1k2, but we used 1k3 and noticing it I have a chance to not unnecessarily expand our warehouse. Those times (90s) we were changing from 1206 to 0805 and 0603 so the number of separate resistors were bigger than it would be nowadays.
Before we decided to use only that way of changing values it happened that the electrolytic capacitor value was only text edited and we had 50 PCBs to thrown away as there were no enoug space for capacitor.

But, generally it happens very rarely to change element value.
If I know the LED currents before drawing schematic than I use correct values just from the beginning.

Next week I will be changing 4 capacitor values. But if experiments to find their values take me a week than I can loose some seconds to change them at PCB.

I use F8 more times because I have added something to schematic than because I have changed the element value.
Changing values is very, very rare, but because I have it in mind I just have this flag always set.
I switch it off only after re-annotating the whole schematic what I am doing as the last operation on schematic when everything (including PCB being designed) is done.

I don’t know what KiCad database driven libraries offer and probably will never be looking on it. I have no time to learn things that I really don’t have to.

Database libraries are designed for exactly the workflow you are describing. You are already using a custom library with all your preferred parts. When you use database libraries, you go one step further. Database driven libraries are an absolute must for adoption in the “professional market”. Take a bigger company, with for example 10 PCB designers, and also people who are dedicated to creating parts, ordering, cost optimization and finding substitutes. Those people interact with the database, but not necessarily with KiCad itself.

In such a database, you can also add extra meta data. For example parts you do have on stock, but want to phase out or replace. Can you remember all the meta data for the parts in your library?

I don’t use database driven libraries myself, but I guess that replacing one resistor with another via a database is the same Change Symbol menu as you are using. It’s just that the database holds more information.

Don’t delete and replace, but use “Change Symbol”. It replaces the symbol with a new one, keeping both the reference and the UUID.

Looks like Piotr is already doing that for some time. I guess his “Replace” is actually the “Change Symbol”. It always helps a bit to avoid confusion if you use the same names as used in KiCad’s menu’s.

I have just written that hitting Del and then ‘A’ hotkey is faster than searching in context menu the correct function for Change Symbol (and you have to remind that such function exists while Del and ‘A’ you always use so by default remember them).
In both cases you then have to find in library the correct new symbol so this part is the same.

Unfortunately I write from home where I have Win7 PC so last KiCad I had here was V5. Now (after one (partial) system catastrophe) I don’t have here even V5.
I didn’t remembered that this Replace is named Change Symbol (for me both terms mean the same).
Do Replace means something different (than Change Symbol) in KiCad?

Change Symbol is something you can find in KiCad’s menu’s, and I know what it does. I do not know what KiCad does with a Replace. That is open for interpretation.

1 Like

Sorry but had to move these posts to a new topic as they are derailing the topic they were originally posted to . . .

1 Like