KLC S6.2 & S6.3: How to handle datasheet?
Closed this issue · 8 comments
It seems that there have been some changes in how KiCad handles the datasheet url. AFAICS, originally there were two places:
- The "Documentation" setting for a symbol, which is saved in the .dcm file and configured using the symbol properties. This is required by S6.3, which also has a screenshot of how this looked.
- The "Datasheet" field, which is an actual field placed on the symbol (usually invisible) and stored in the .lib file. This is required to be empty by S6.2.
However, it seems that (in 5.1, I believe) the "documentation" property was removed, and automatically migrated to the "datasheet" field by eeschema and the symbol editor. In the nightly build this causes the datasheet field value to show up in a symbol whenever you edit the symbol (and copied into the lib file), making it violate S6.2.
I guess these policies should be updated? In particular, I would think:
- S6.3.3 could be removed
- The screenshot in S6.3 updated
- S6.2.4 should specify the datasheet rules removed from S6.3.3
Maybe S6.2 should also specify something about the location of invisible fields? These are created at the origin automatically, where they typically obstruct other parts of the symbol, so moving them outside of the symbol somewhere makes sense?
See also https://bugs.launchpad.net/kicad/+bug/1830078 and https://bugs.launchpad.net/kicad/+bug/1841369 which relate to this change in KiCad.
You misunderstood hbow kicad works.
There are two places in the current file format where a datasheet can be added.
One is in the .lib file and one in the .dcm file.
KiCad v5 copies the .dcm setting into the placed symbol field if the .lib definition is empty.
Since v5.1 .lib setting can no longer be set from within the graphical interface. (It can be set from scripts or other kicad external tools and also by older versions of kicad) This means i see no reason why this rule should be changed as it does not reference the graphical interface but the result in the file format.
The nightly build is not allowed to be used for contributions to the official library. So we can ignore its features completely.
I think I understood, but maybe not completely :-)
KiCad v5 copies the .dcm setting into the placed symbol field if the .lib definition is empty.
AFAIU, KiCad 5.0 (and I think also 5.1) copies the field in the schema editor, when placing the symbol. But the nightly build does this in the symbol editor, automatically making the symbol violate S6.2.
I can see how this part does need to be reflected in the KLC yet, but this will become relevant once KiCad v6 is coming nearer (though perhaps all this becomes irrelevant, since I think there's also a newer library format in the works. Or maybe there will be a 5.2 where this is included?
Since v5.1 .lib setting can no longer be set from within the graphical interface. (It can be set from scripts or other kicad external tools and also by older versions of kicad) This means i see no reason why this rule should be changed as it does not reference the graphical interface but the result in the file format.
Hmm, you seem to be correct: If I edit the "Datasheet Field" in the editor, it only edits the .dcm file, not the .lib file. However:
- Given the change in the nightly build, I suspect that it is not the intention of the devs to only edit the .dcm file, it seems like they intended to really unify both fields.
- In the 5.1 GUI, I can no longer edit the "Documentattion File Name" metadata, as instructed by S6.3. The only place I can still edit is the "Datasheet Field", which I am instructed to leave empty by S6.2. You say the rule does not reference the GUI, but the resulting file format, but the screenshot in S6.3 suggests otherwise, and nowhere in S6.2 it is indicated that this appplies to .lib files rather than .dcm files (I guess it is mostly confusing that most fields are stored in .lib, but the datasheet ends up in the .dcm file). Furthermore, people using the KLC will be looking at the Kicad GUI, not necessarily at the library files directly?
I think this means that the KLC should at least be adapted to 5.1. If the intention is unchanged (Empty field in .lib, datasheet in .dcm), the changes suggested above could work. Alternatively, S6.3 should specify that the documentation field is actually edited through the "Datasheet" field and S6.2 should indicate that the "Datasheet" field cannot actually be edited in 5.1 or something like that.
If the changes that are now in the nightly build make it into a stable build, the current intention (keeping the datasheet field in the .lib empty) can, AFAICS, not be maintained, so should be reconsidered, or KiCad should be changed to allow it again?
For reference, here's how the symbol properties window looks for me with 5.1. It has no documentation metadata, but only the "datasheet field":
You ignore the most important part above: We do not care about nightly here on the official lib. Head over to the bugtracker and report your issues there. (See rule http://www.kicad-pcb.org/libraries/klc/G1.8/ which i will word much stricter shortly as it is not at all allowed to even use nightly at all to contribute not just when using non supported features. This is because nightly creates a mess in the git history.)
We do not care about nightly here on the official lib.
I've understood that, but most of this report is about 5.1, not the nightly. When using 5.1, the KLC does not currently clearly indicate to me how to handle the datasheet field.
Additionally, to me it would seem valuable to know what is coming up in the next release, so you anticipate by either thinking how you want to adapt the KLC, or by reporting bugs at KiCad to make sure it supports what the libraries need (before such problems appear in a stable build and become harder to change). But regarding this second point, this issue is just a heads up, feel free to use or ignore it as you see fit. As for me reporting issues at the bugtracker: I do not really know whether the change made in KiCad is actually problematic. I believe it conflicts with the current KLC, but perhaps the "empty datasheet" restriction is something that could be lifted? This is a discussion that I think should be here, not in the bugtracker?
I will update these rules with screenshots of v5.1 and will slightly reword the rule.
If nightly does indeed not allow having the .lib entry empty as you indicate above then this must be reported on the bugtracker as it would not allow having different datasheets for aliases (would be a re introduction of a 5.1.0 bug)
@matthijskooijman
@poeschlr has updated KLC with changes intended to resolve this question. Can you please review https://kicad-pcb.org/libraries/klc/ and close this issue if you have no further feedback on this topic?
Looks good to me, so I'll close this. There is still the issue of changed (and possibly problematic) behaviour in the nightly, but I don't have time to dig into that and report a bug about that (if there isn't already), so I'll leave that to others.