I made a symbol for TPIC6C596 and would like to contribute it to KiCad repository, but I’m lost how to do it. The instructions on the KiCad page didn’t clarify much:
[x] Get a GitLab account
[x] Fork the symbol library
[x] Clone to the local computer (managed to do it with GitHub Desktop)
[x] Create a new branch on the local copy of repository
[ ] Include all the changes to the files in branch
And this is where it gets confusing. What is software to open/modify the local repo? None of files in repo seems to be openable with KiCad. If I’m opening those as plain text (like if I would like to copy-paste exported part to the library), I see the difference in the syntax for part description. There is also a different file extension:
.kicad.sym for library in the repository
.lib for libraries of KiCad at location “C:\Program Files\KiCad\share\kicad\library”
Could anybody help with / explain this?
P.S. These are files created by KiCad (5.1.10) after creating the symbol and exporting it: tpic6c596.dcm (220 Bytes) tpic6c596.lib (986 Bytes)
Kicad 5.99 (future version 6) has a different symbol file format than v5. This is the .kicad_sym (v6) vs. .lib (v5) difference you see.
The library team is currently only accepting submissions for v6-compatible symbols (extension .kicad_sym). The v5 library (.lib/.dcm) is frozen at this point.
They don’t have enough people to maintain both, and v6 is considered close enough that all effort is being directed at prepping the libraries for the v6 release.
If you still want to submit it, you could convert it to v6 format by downloading a kicad nightly release (many caveats apply!) and doing the merge request with the converted file.
The library (or libraries) is basically the same than in your KiCad installation from the Windows installer. The installer should install the libraries in C:\Program Files\KiCad\share\kicad\library. But you shouldn’t mess with that; clone to some other location which you can read/write. If you compare the locally cloned repository with the packaged library you can see they are similar. Therefore they can of course be used in the same way in KiCad.
There may be several possible workflows. I would try this (with 5.99):
Select all .kicad_sym files but nothing else; or only the libraries you are interested in.
OK.
Now they should be reachable from your project and you can use the symbol editor to add symbols. After you have saved the symbol/library you can check the result in your local repo clone with git diff.
You can import your .lib file: open the context menu on the target library in the symbol editor. Import Symbol. Choose the .lib file.
After you have imported it or created a new symbol, save the library. Then check the result with your git frontend. Then push the changes to your gitlab fork.
`Checking symbol 'Interface_Expansion:TPIC6C596':` ` Violating S3.1` ` Origin is centered on the middle of the symbol` ` Symbol unit 1 slightly off-center` ` - Center calculated @ (0, -50)` ` Violating S3.6` ` Pin name position offset` ` Pin offset outside allowed range` ` - Pin offset (15) should not be below 20mils` ` Violating EC02` ` Check part reference, name and footprint position and alignment` ` field: reference, @ (-350, 550), recommended @ (-100, 625)` ` field: reference, justification center, recommended right` ` field: name, @ (250, 550), recommended @ (-100, 550)` ` field: name, justification center, recommended right` ` field: footprint, @ (650, -650), recommended @ (50, -650)` ` field: footprint, justification center, recommended left`
It looks like the other symbols have violations, too, so you probably haven’t done anything wrong with your merge request.
There’s still this:
Fast-forward merge is not possible. Rebase the source branch onto master to allow this merge request to be merged.
It’s a bit more tricky. You have to add the original official kicad symbols repository as a remote to your local repository, fetch it, then rebase your branch to the official master branch (i.e. apply the latest changes of the master to your own branch so that your local commits will still be on top of the history). Then push again to the fork.
Yes there are assets in the official lib that violate our rules. But this is not a reason why new contributions should not be held to a higher standard. In other words: just because other assets have similar or even worse violations does not mean the contribution at hand is correct.
What is however true is that one does not need to fix issues found in assets that were not changed in the merge request itself.
In the past the scripts were rather good in only showing messages about things that were really changed by the contributor. It however seems that this is no longer the case. This will definitely need to be investigated as reports like the one given for this pull request are not really helpful.
Now lets look at the report that is relevant to this symbol.
The violation to S3.1 is a minor one. It results from the fact that the symbol is asymmetrical. This is something that can be ignored if there is a good reason not to ensure symmetry (the contributor needs to justify their decision)
Violating S3.6 was a quite serious rule at least while we designed with version 5. I am not sure how relevant it is in current nightly. If the pin offset is still set global to the symbol then i am convinced it is still as relevant as it was before and must therefore be corrected.
Violating EC02 is something that is new to me (most likely something introduced as part of the v6 preparation). I can also not find the rule in the KLC so i am not sure what to make of it. This is something that will be left for the whoever does the review here (i will continue to concentrate on the footprint generator scripts and on footprints in general).
Update: I investigated further regarding EC02. This rule was present in the old checker but it was disabled. Compare the old __init__.py to the new __init__.py
