Closed dbrgn closed 6 years ago
Hmm I'm not sure if we should add "generic connector" packages - Generally packages should represent packages you can really buy, for example pin headers.
The corresponding Component could still be named "generic connector" because Components are kind of abstract/generic things.
Btw, pin headers are already available in the demo workspace because I imported them from Eagle ;) Although some adjustments would be needed to make them looking nicer...
Generally packages should represent packages you can really buy, for example pin headers.
Hm, I thought that pin headers and socket strips would be devices that reference the same package? The footprint is the same for both.
Also, pin headers are usually not really products, since they are very generic. You don't usually buy pin headers of a specific brand, you just want a 1x4 2.54mm connector.
In my case I even need a 3 pin connector which I won't even populate using a header or socket strip, I just need three pads onto which I can solder a custom cable (for a desk lift).
Btw, pin headers are already available in the demo workspace because I imported them from Eagle
For such basic elements, I'd prefer to generate the packages, since you can easily adjust the parameters and re-generate them.
Hm, I thought that pin headers and socket strips would be devices that reference the same package? The footprint is the same for both.
You could use the same for both, but actually the packages differ in two things:
Also, pin headers are usually not really products, since they are very generic. You don't usually buy pin headers of a specific brand, you just want a 1x4 2.54mm connector.
Sure, but all pin headers look very similar, so one package for all of them should be enough. But other kinds of connectors (like socket strips) really look different, so they should have a separate package.
In my case I even need a 3 pin connector which I won't even populate using a header or socket strip, I just need three pads onto which I can solder a custom cable (for a desk lift).
In that case I would probably just use the package of a pin header (or any other package which fits). Or even create a "soldered wire connector" package - the 3D model of such a package could then even contain some wire ends soldered into the pads ;)
My opinion on generic packages is not too strong - maybe it still makes sense to have generic packages, but actually it feels wrong.
Regarding your PR:
{{NAME}}
and {{VALUE}}
Silkscreen (different outlines)
Ah, you mean because the pin headers have this irregular shape while the socket strips are plain & rectangular? Fair enough, although that could be handled by footprint variants, since socket strips and pin headers are often used interchangeably depending on your needs.
3D models (not yet supported, but later packages will have 3D models assigned)
That's a good point. But wouldn't a 3D model be a separate element that would be linked to devices (not to packages)?
Or even create a "soldered wire connector" package
That's a good idea.
The packages don't contain the texts {{NAME}} and {{VALUE}}
Will add them.
Will you also add the corresponding symbols, components and devices? Because the packages are useless without these other elements.
Sure, I just wanted to get some initial feedback on the approach.
Ah, you mean because the pin headers have this irregular shape while the socket strips are plain & rectangular?
Correct.
Fair enough, although that could be handled by footprint variants, since socket strips and pin headers are often used interchangeably depending on your needs.
Footprint variants are intended to be used for the same mechanical part, just with different landpattern (for example because it is mounted differently). But pin headers and socket strips are different mechanical parts, so they should be different packages. If you want to replace a pin header by a socket strip, you have to replace the Device in your board, not the Package (remember: a board contains Devices, not Packages).
The rule when to create different packages or not is actually very simple: If two mechanical "things" you mount on the PCB look equal, then one package is correct. If they look different, you should create different packages.
For example a TO220 always looks the same, no matter if it's a transistor, a diode or a voltage regulator. And also no matter if you mount it vertically or horizontally, the mechanical package is still the same.
But a socket strip and a pin header looks really different, so they must be different packages.
Don't take the land pattern into account in this decision - it doesn't matter whether pin headers and socket strips have compatible footprints.
That's a good point. But wouldn't a 3D model be a separate element that would be linked to devices (not to packages)?
No, the 3D model will be part of a package - that's basically the main reason why it's called "package" instead of "footprint" ;)
Sure, I just wanted to get some initial feedback on the approach.
:+1:
Btw, I would change the order of the pads so pad 1 is at top, not bottom.
Updated library with latest version of https://github.com/LibrePCB/librepcb-parts-generator/
Oh, not yet fully done, needs some more format updates.
Well done! Here my feedback (starting with highest priority) :smiley:
Most of these points aren't critical, so feel free to create corresponding issues at the generators repository instead of fixing them now ;) But of course it would be nice to have them fixed soon...
Btw, I'm still struggling with the different types of connector components :( I wonder if it would be better to use the same symbols and components for pin headers, sockets, soldered wire and many other types of connectors. The advantage would be increased reusability and flexibility because devices are interchangeable (for example you could draw a schematic without knowing what connector types you want to use, and choose the exact type afterward in the board - even different connector types for different board are possible). The only drawback is actually that the same symbol needs to be used for all connector components, so in the schematics it wouldn't be possible to distinguish between header and socket. Any other thoughts about that?
All devices have an invalid category
Oh, good catch!
I would still set the origin to the exact center, just for consistency.
Can do that.
So couldn't we rename them to just "Connector"?
Hehe, we picked that name because you didn't like generic connectors :slightly_smiling_face: But yes, I think that's a good idea.
Default value of pin header/socket components should be set to "{{PARTNUMBER}}".
What is the part number exactly? The MPN? If yes, do you really want that in the schematics?
I wonder if it would be better to use the same symbols and components for pin headers, sockets, soldered wire and many other types of connectors. The advantage would be increased reusability and flexibility because devices are interchangeable (for example you could draw a schematic without knowing what connector types you want to use, and choose the exact type afterward in the board - even different connector types for different board are possible).
Yep, I agree, and this is what I originally proposed. In practice you don't usually pick a specific pin header from a specific company, you just want a "debugging connector". Connectors are actually a case where I think that generic library elements are a good thing. Especially for headers/sockets that are interchangeable hardware-wise.
Hehe, we picked that name because you didn't like generic connectors
No, I wrote that generic packages should not be used, but generic components are fine:
Hmm I'm not sure if we should add "generic connector" packages - Generally packages should represent packages you can really buy, for example pin headers.
The corresponding Component could still be named "generic connector" because Components are kind of abstract/generic things.
What is the part number exactly? The MPN?
Yes, MPN. But actually I'm not sure if this attribute will really be names "PARTNUMBER", "PART" or "MPN", so forget my comment ;) We can change the default value later...
If yes, do you really want that in the schematics?
It depends. Sometimes one wants to see the part number in schematics, sometimes not. And it's easier to clear the VALUE of a component than changing it to "{{PARTNUMBER}}", and as long as you don't choose an exact part, it stays empty anyway.
Yep, I agree, and this is what I originally proposed.
I'm really not sure if you sometimes confuse symbols/packages/components/devices :stuck_out_tongue_winking_eye: I guess you originally proposed to have generic packages, which is definitively wrong from the concept point of view. But for components it's not that clear whether they should be generic or not, and that's what I'm talking about.
In practice you don't usually pick a specific pin header from a specific company, you just want a "debugging connector". Connectors are actually a case where I think that generic library elements are a good thing. Especially for headers/sockets that are interchangeable hardware-wise.
This also sounds like you are talking about packages, not components. For components it's completely irrelevant whether their packages are interchangeable, because components don't know their packages anyway.
So after all, I'm not sure if you really understand what I mean :wink: Did you already studied the diagrams of the library concept?
Long story short: Having generic connector components would mean that schematic symbols always look the same, no matter if the connector is a pin header, a socket strip or any other kind of connector.
No, I wrote that generic packages should not be used, but generic components are fine:
Yeah you're right.
Yes, MPN. But actually I'm not sure if this attribute will really be names "PARTNUMBER", "PART" or "MPN", so forget my comment ;) We can change the default value later...
Changed already :slightly_smiling_face:
You're right that I mixed up devices and components btw.
What if we just have 1 component for headers/sockets/generic connectors, but with three symbol variants?
Applied the requested updates (see https://github.com/LibrePCB/librepcb-parts-generator/commits/master).
I'll stick to having different symbols and components for now, they can always be deprecated later on. That's easier than removing symbol variants or something like that :)
Thank you very much @dbrgn! :+1:
:tada:
Generated, see https://github.com/LibrePCB/librepcb-rfcs/issues/24