Open evanshultz opened 5 years ago
To be honest, if a module is to be mounted on a header than i would guess a template might be the better choice.
As this is planned for v6 we might be lucky and get something similar to eagles design blocks. (A kind of hierarchical block that allows adding a pre defined pcb side to it. This would be ideal for things like these.
Maybe I've misunderstood or not written the above clearly. I thought the Module repo captured footprints that were for a module (PCBA) that would go onto the PCB being designed in KiCad.
Some examples:
So the board being designed in KiCad would hold/contain one of the above modules, and it would be helpful to have a footprint that shows the outline of the module. The module would be one part of the BOM for the product being designed in KiCad.
The header or other items to support the module would also be parts of the BOM for the product in KiCad, and thus all should be individual components with their own ref des.
Sorry if that was overboard. But I don't see how a template would work since a template defines the product to be designed in KiCad, including the board outline. If the footprints in the Module library had Edge.Cuts, like templates, they would punch a hole in the main board being designed in KiCad and that's not what is desired. At least how I understand it. But am I not getting it?
I think this plays in the same ballpark as my issue https://github.com/KiCad/kicad-footprints/issues/1307 (at least if I am not mistaken)
Imho a concrete definition for what a module in footprints and a template should be made, otherwise it is a complete clutter of different understandings and therefore implementations.
@poeschlr said:
To be honest, if a module is to be mounted on a header than i would guess a template might be the better choice.
Not sure. I think that if the module becomes a component of your PCB design, a footprint is the right way to go. I can't see how that would work with a template? Maybe I'm missing something.
@herostrat said:
I think this plays in the same ballpark as my issue #1307 (at least if I am not mistaken)
Yes, and I think that we both think the same. See my attempt to explain the difference between footprints and templates for modules on https://github.com/KiCad/kicad-footprints/pull/1066#issuecomment-435628391. I think it's pretty much the same that you say.
Thanks!
With a single footprint you only get a single entry in the pos file. So if the part in reality needs two connectors placed then you will not be able to use a single footprint for it if you plan to use automatic assembly. The only option offered by kicad that allows having multiple footprints (and therefore multiple pos file entries) imported at the same time is by using templates.
I don't think we've ever mentioned two connectors, or at least I haven't. I was referring to 1 connector plus the module.
Modules footprints, i.e. for arduino boards, have often times multiple headers.
As we do not just have to include one style (pcie, m.2, etc.) all possibilities have to be thought through.
Modules footprints, i.e. for arduino boards, have often times multiple headers.
That's true. Yes, that makes it a bit worse :) OK, we'll have to think it through.
Good discussion.
There are two methods, right?
What exactly is a templates vs a footprint and the other related topics are also important to figure out.
See https://github.com/KiCad/kicad-footprints/pull/1066#issuecomment-462539470 and later comments.
The Modules repo currently has footprints showing the outline and other important features of the module (such as mounting holes). In addition, they all include the header to which the module is mounted.
Should the header location be captured in the module footprint but not the header itself?
Joining them means the module footprint must be different for a SMD header vs a THT header, for example. In addition, the header is not a unique item on the BOM even though the module and the header are purchased separately and have unique part numbers (and ref des). It seems to me the mounting header and the module should not be joined together.
The trouble is in placing the two parts so they align. The module footprint would need a target to know where to place pin 1 of the separate header footprint. Right now in Pcbnew if the grid is "correct" or you are grabbing by a pin, or you can use the Move Exactly command, it may all work out nicely. But there's not, as far as I know, an easy way to grab a part by any desired element (or filter out undesired elements) composing the footprint to easily align multiple footprints. It would be a great addition and I think I recall something about this on the KiCad roadmap. (I use Allegro and it has a powerful "pick by" feature.)
So having the header and module outline together may be the easiest way to ensure users don't make a mistake with the current capabilities on KiCad. Especially as we will hopefully have filters and more tools in v6 to make this better it may be worthwhile to revisit this so I marked it as a 6.0.0 milestone. If there is reason and agreement to split up the module outline and header, and it will work nicely for KiCad users, we can target a future KiCad release.