Cleaned up resistor networks script

[fauxpark]

After https://github.com/KiCad/kicad-symbols/pull/833, I decided to take a look at the resistor networks script. It now generates valid symbols as of the v5 libs (mainly old footprint/filter assignments and symbol names), but apart from the regular R_Network symbols, they are not quite identical to the ones currently in Device.lib. Seems to be mostly rounding or off-by-one issues, and even-numbered R_Pack symbols are centered on different resistors.

The individual drawing elements are annotated with comments now, so you can more easily tell what line produces what part of the symbol. Hopefully this makes it much less of a pain for someone else with more math skillz than myself to jump in and fix things.

[fauxpark]

By the way, the script does not generate the glitched resistor bodies I fixed in the above PR. I have no idea how those two symbols came to be that way, but it doesn't appear to be an issue with the script.

[poeschlr]

Just for the future, there is a nice library for abstracting the symbol file format. https://github.com/KiCad/kicad-library-utils/tree/master/schlib/autogen/KiCadSymbolGenerator I think it would make this sort of generator a lot more readable. (Have a look at the connector generator for an example of how it can be used if you are interested.)

[fauxpark]

I did see that. I'll leave it for now :)

[evanshultz]

Does this make incompatible symbols? Meaning the symbol body size/shape or pin locations are different? If so, this can still be merged but we won't use it just yet to avoid making breaking changes to the library.

I'll try to take a look at this tomorrow.

[fauxpark]

The only difference IIRC is that it doesn't order the pins in the way KiCad likes them. Other than that they are basically identical to the current symbols. I'll double check in a bit.

EDIT: Nope, they are not.

[fauxpark]

@poeschlr @evanshultz I finally bit the bullet and migrated the script to use the symbol generator.

As an aside, it seems the off-by-one errors were something to do with Python 2. Since the generator requires Python 3 they have disappeared and the symbols are now 100% identical bar the unordered drawing lines. 👍

[poeschlr]

It is suggested to open the generated library in kicad and save it to get the current kicad line ordering. (I could not find a documentation about that. I fear the devs make it up as they go along.)

[fauxpark]

This is ready to merge, I think.

[evanshultz]

Thanks for the ping. :) I'll put it on my list to check in the next two days.

[evanshultz]

R_Network.zip Here is an archive of the output files from the RNetwork.py script and a cut-down version of Device.lib containing only the R* parts. The line ordering is a off, but I skimmed it and it seems fine to me. Visually they looks good too. Nice!

One thing I'll mention here that could be done now, but I will happily merge as-is: The ref des and value could be oriented right-side up, stacked, and placed above (if there's not pins) or to the right of the symbol. The auto-place algorithm may move them around but if this feature is turned off in KiCad at least the text is not on its side which is ugly and atypical for the library.

And a few minor notes which I plan to turn into an issue but perhaps you want to comment on now (?):

1. The R_Network* symbols don't describe the configuration of the resistors. I would call them "bussed".
2. Similar to an above point, "R_Pack" doesn't tell the configuration. I would use the word "isolated".
3. The points above refer to inconsistent naming. Perhaps we should define a naming convention like R_Network<number of resistors>_<configuration such as Bussed, Divider, or Isolated>[_SIP]? We could replace Network with Array for brevity.
4. The divider resistors are named by the number of divider elements while the others are named by the number of resistors. I don't see this as helpful and it's unclear to me what the naming means without seeing the symbols. It also wouldn't work to describe the "8 terminal, 6 element" parts at https://www.susumu.co.jp/common/pdf/n_catalog_partition02_en.pdf#page=4 versus what we have now (maybe these are uncommon and we don't care?). DigiKey just goes by the total numbers of resistors in the part (symbol), regardless of the configuration, and that may be a better way to go. I've incorporated that above.
5. Why do the divider symbols end in "_SIP"? There is only one version of divider symbols so this doesn't add anything.
6. It appears "_SIP" for the "Pack" resistors relates to the pinout of the symbol, but I associate "SIP" with the physical package which, in KiCad, is separate from the schematic symbol? Perhaps there's a better word to use if we want to refer just to the symbol pinout? (I can only think of "Inline" right now but I don't love that.)
7. I don't know how common the usage of this configuration is, but DigiKey turns up over 1000 parts that are 2 resistors in a divider configuration, such as http://www.vishay.com/docs/60001/mpm.pdf. No other dual-resistor configuration they list is missing from the script. Perhaps the divider script should pop out a dual-resistor symbol?
8. The script updates don't generate the US resistor symbols.

[fauxpark]

The answer to most of those is: this PR is only meant to get the script up to date and generating the symbols as they currently are in the lib :)

For point 7, we already have Device:Voltage_Divider[_CenterPin1|3]. Is there a use case for one that looks like these symbols?

[evanshultz]

Sure! I just wanted to write down what I was thinking and will transfer it all to an issue.

I'm not sure. If the symbol has more than one resistor inside it, I'd search for a common term like "network" or "array". It's a good point and thanks for mentioning that symbol.