Nice and useful description Andy_P
And that idea of a local Master Library, should be endorsed by each E-CAD package in existence.
Independently on how every one works, each as their own work flow peculiarities, we all have the same goal: to never fall into the trap of ordering or using the wrong part (A.K.A component).
However, I believe the problem is in application work flow, how it was designed and why.
Current work flow, is something like this ( in a very reduced form):
1 - Create schematic, using components (AKA Symbols), NOTE: components have pin numbers.
2 - Associate Footprints to components (implicitly matches pin numbers with foot print pins )
3 - Create PCB using the above.
The problem, as I see it, is in point 1 and 2.
Point 1: From a logical (schematic) perspective , we shouldn’t care what the pin number is, but what its’ function is in the device (example, 74xxx family with several gates per package).
Granted that having pin numbers is nice to review or debug the PCB later.
However, from a logical perspective we could do without them, and this would avoid some problems (I’ll explain more later).
Point 2: The big NO-NO in this step is the “(implicitly matches pin numbers with foot print pins )”.
Pin numbers, should never be implicit, either someone already did that mapping or it needs to be done.
The component should never assume anything, since this is what causes problems.
Once someone associates a component (symbol) to a specific package type, using “Pin Mapping”, then there is no doubt, that “component” is applicable to that package type, else it’s not, and we shouldn’t see pin numbers on the symbol.
It doesn’t matter what name you give the part, each one to his own liking.
What I’m saying, is that is that instead of 3 steps, we should have 4.
1 - Design Schematic using (AKA Symbols), NOTE: (with or without pin numbers)
2 - If not already done,Associate/Map component pins to Package Type. NOTE: Once done this is saved within the component definition.
3 - Associate Footprints to components/Pin Mappings (no implicit conversion here).
4 - Create PCB using the above.
Points 2 and 3, will be done only once for a specific device/package type pair.
And once done, you will never do it again (for that component/package pair).
This still maintains the logical and physical separation, so that we can re-use symbols or footprints, to define a new “real part” software representation, but still allow to correctly associate components/pin numbers/footprints, without any assumptions.
And better yet, it allows several possibilities of work flows, with just the logical symbol, or the symbol already associated with a package type, with some specific pin mapping.
The real problem is that pins, implicitly have pin numbers, and footprints associated those without any human verification, and that is where the problem is.
