Pulls/magjacks hr

[karlp]

Replace this line with your commit message! Please provide a description of your pull request
^^ commits contain commit messages, github doesn't fill them for multi commits

---

Thanks for creating a pull request to contribute to the KiCad libraries! To speed up integration of your PR, please check the following items:

• Provide a URL to a datasheet for the symbol(s) you are contributing
• An example screenshot image is very helpful
• Ensure that the associated footprints match the official footprint library
• If there are matching footprint PRs, provide link(s) as appropriate
• Check the output of the Travis automated check scripts - fix any errors as required

[CLAassistant]

All committers have signed the CLA.

[karlp]

see also: KiCad/kicad-footprints#1091

[karlp]

Travis explanations:
For rj45-magjack:
S5.1, this is a generic part, shouldn't have a footprint per my understanding
s6.3: can't have docs on a generic?

For the hanrun part itself:
s5.1 see matching footprint PR
s6.2/s6.3: I can't understand how to work with these fields on kicad 6 rc nightly builds,

[poeschlr]

Have a look at my "how to make a symbol" tutorial over at the forum. I used a recent nightly and showed how to set the documentation fields.

TlDr: The documentation and keyword stuff are now managed in the symbol properties dialog. For the main symbol all of it is done in the general tab. For aliases the same fields can be managed in the aliases tab.

Edit: I asked the devs for clarification just in case that you are right and this can indeed not be done anymore (and i have the feeling you are right)

---

For generic parts the datasheet field can be left intentionally empty. For this place a "~" character in it.

The footprint field should be left completely empty. But the footprint filters need to be set.

[karlp]

Have a look at my "how to make a symbol" tutorial over at the forum. I used a recent nightly and showed how to set the documentation fields.

TlDr: The documentation and keyword stuff are now managed in the symbol properties dialog. For the main symbol all of it is done in the general tab. For aliases the same fields can be managed in the aliases tab.

Edit: I asked the devs for clarification just in case that you are right and this can indeed not be done anymore (and i have the feeling you are right)

So... I just ignore the travis errors from S6.2/S6.3 then?

For generic parts the datasheet field can be left intentionally empty. For this place a "~" character in it.

ok, so, not blank, if you want blank, a special not blank, blank value. ok got it :) (this is not covered in the KLC, and is completely undiscoverable, why would one not leave a value blank when one wants it to be blank?)

[poeschlr]

For now you would need to either manually move the datasheet field from the lib file to the dcm file or use a stable release.

[karlp]

even if I do that, (highly doubtful) what's the roadmap going forward? how is this meant to work in the future? You're not planning on making another repo for the symbols again, and forking it all again are you?

[poeschlr]

Why should we make a new repo? Last time we made a new one was because the old one had the 3d models in it as well and the name kicad-library is not really fitting for something that only contains symbols.

---

Regarding the dcm file problem: we can not accept the stuff as it is now. The devs are aware of it and there will be some fix in the future. (Will depend on how busy they are with other stuff) For now we need to accept that we need to manually change some files in a text editor until a real fix exists. (with we i mean contributors running nightly builds)

[myfreescalewebpage]

Hi @karlp, thanks for contributing

I have not yet reviewed the symbol because I want to ask @poeschlr what we should do with this contribution ? This is a new RJ45 magjack, but for me a generic one (to be reworked according to me) is enough, isn't it ? Only specific footprints should be accepted in my opinion. What do you think ?

Screenshots for remembering:

Existing Amphenol symbol in the lib (to be removed according to me):

Generic symbol proposed by this PR:

Pin length, pin number and symbol very large are the three points to be reworded for me, this symbol should be the only one to be kept.

HanRun specific symbol also proposed by this PR:

Cheers,
Joel

[lorenz]

What still needs to be done here to get this merged? I need the HanRun jack and I'd like to avoid PRing the same thing all over again.

EDIT: This is also noncompliant with KLC since the HanRun magjack has a footprint, but no associated symbol

[karlp]

There's no symbol, because it relies on a resolution on whether there'll be a generic magjack or not, (see the linked PR) from my point of view, take any part of this you like and submit it as your own, I consider my workk in this area to be licensed under the receivers choice of public domain, ISC, MIT, X11, Apache2, BSD 2Clause or GPLv2+ whatever amkes their life easier.

I'll get back to the project this needed eventually, but the hoops here are not the top of my todo list at present.

[myfreescalewebpage]

@poeschlr can you have a look to this PR to get a decision, particlularly at my comment #1146 (comment) ? Thanks.

[myfreescalewebpage]

No news of the original author, indicate the PR is abandoned.

[karlp]

Aren't we waiting on @poeschlr for a decision on a generic magjack? It's not abandonded.

[myfreescalewebpage]

@poeschlr ?

[poeschlr]

@myfreescalewebpage i agree with you on the idea of using a generic symbol for future additions. We might want to go with a similar pin "numbering" scheme as used with the audio jacks. Meaning use logical "names" which should then also be used on the footprint side as i guess manufacturers will have differing pin numbering schemes used in their datasheets. At least the symbols shown above give this impression. (These pin numbers would need to be documented in the KLC, see KiCad/kicad-website#433) My suggestion would be using the same "numbers" as the current names except for the shield pin where i would follow our normal standard of using pin number "SH".

[karlp]

So, @myfreescalewebpage is going to take refactoring the existing symbols to a generic magjack symbol (is that tracked anywhere or is this it?), this PR can be closed, and the footprint PR KiCad/kicad-footprints#1091 can then just be rebased on @myfreescalewebpage 's new symbol when it becomes available? Have I understood correctly?

[myfreescalewebpage]

I do not plan to make a symbol, but you can do it in this PR :) The footprint is independent.

Since the beginning of this PR I personally proposed SIM card connectors (#2519). @poeschlr I have doubt common numbering can be done for Ethernet and SIM connectors, there is plenty of different possible devices. For SIM card connectors there is also double and combo connectors, etc. @karlp maybe you can make a proposition of standard Ethernet connector symbol and we can discuss.

[karlp]

I'm not currently planning on spending any more time on these.