Problems update symbols and value in subsheet v6.0

[ASJ]

Hello everyone.

1. I imported a project with a subsheet from KiCAD 5 to 6 (no errors)
2. I added some elements (e.g. resistors) to the subsheet. (no problem)
3. I changed the numbers and values of the newly added and old elements. (no problem)
4. I saved the schematic and closed the Schematic Editor in the main project. (no problem)
5. I opened the subsheet in the new Schematic Editor - not in the project. (and I see the problem:
   The numbers and values have not been updated! Parts newly added in KiCAD 6 had no values).
6. I reopened the subsheet in the main project and added more resistors with numbers and values (no problem)
7. I saved the schematic and closed the Schematic Editor in the main project again. (no problem)
8. I opened the subsheet again in a new Schematic Editor - not in the project. (And I still see the problem with the update: Parts from KiCAD 5 are still not changed. I noticed that parts imported from KiCAD 5 never change numbers but lose values. Parts newly added in KiCAD 6 have no value, and parts added in point 3 already have a value - chaos in update subsheet!).

After having a look at the schematics in the text editor you can see that these values are overwritten by the section: symbol_instances. Also the values of all parts from KiCAD5 have been deleted.

I care to make sure that this data is stored correctly in the subsheet because they are separate subprojects for me and have separate PCBs. Watching manually is tiring and will lead to an error one day.

Can I hope that these problems will be fixed in the next versions of KiCAD 6?
How can I solve the subsheets update problem now?

[ASJ]

1. Because it is a large project consisting of many smaller PCBs. This allows it to independ on the development of each one while maintaining the integrity of the main project.
2. I want to send someone a piece of the larger schema (e.g. for testing or development).
3. Changing the main schema dependend on options (change subsheets = change versions).

This is object-oriented thinking about the project, just. My apologies to KiCAD programmers for it

[SembazuruCDE]

You are using a misfeature (or quirk) of KiCad v5. I played around with this once or twice to create multiple boards from a single system-level project, but I knew I was abusing KiCad in an unexpected way. I’d have to play around with my old project to see if I can figure out a work-around, but I’m not sure when I’ll get around to it.

I was wondering if or when this undocumented quirk of v5 would break. Seems like from your description my answer is v6. Sorry, dude.

[ASJ]

Yes, it was an undocumented quirk of v5 but it worked fine! Now there is a mess of data.
A schema is an object of data, stored in a file. It should be independent and complete.
Now a sub-schema file has the same data written three times. In itself twice (section: symbol and symbol_instances) and in the master-schema file (section: symbol_instances).
This data is updated at different times by different processes. Who invented this?!
In my opinion, in computer science and life, the best solutions are simple in their logic that create a complete and independent object.
I am seriously considering whether to do a downgrade to V5. (An alternative is to write a macro which synchronizes all this data.)
That is why I am asking here what are the chances that this data chaos will be brought under control.
Is there anyone from KiCAD team here and can relate to this?

[paulvdh]

I have also done a few examples with nested projects to experiment with a multi-pcb project.
It did work in KiCad V5, but I have not tried it in KiCad V6.

A common request was to be able to have a single schematic, but with different part values, and maybe even change parts with D.N.P (do not Place).

A simple example for different values is for example a graphic equalizer, which can have 20 or more filter sections, but each filter section has different values for the parts. Even footprints may change (bigger capacitors may need bigger footprints).

I think KiCad is moving in the direction to support that.
However, Storing part values in the root sheet does seem weird to me. To me it seems much more logical to keep al info belonging to a schematic file into that schematic file itself, and then have a way to communicate and switch between the different variants of a (sub) schematic.

Sometimes some of the KiCad developers make weird decisions. One of them is to use “net tie” (with a space! as a special identifier for a temporary (and understandable) ad-hoc solution.

I do not know what the end-goals are in this schematic variant stuff. Schematic variants, design blocks, and panelization all have some overlap and there should be some architectual overview of how such parts should fit together. Maybe such a draft exists, but I’m not aware of it.

Another “weird” and historical thing, is that a schematic symbol is the “root” of a “part”. This probably becomes problematic if database driven part management is ever implemented.
To me it makes more sense to have a “Part” as an empty container with just an UUID, which can then be dressed up with graphics for a schematic symbol, links to a footprint, etc.

KiCad started some 30 -odd years ago as a quite limited and simple application. Now it’s turning into a fully featured “professional” design suite and to get there changes have to be made, sometimes even on a conceptual level. Sometimes it’s better to change and go though that pain once then to wrestle concepts into a form they were not designed for.