pcb-rnd knowledge pool
Terminology: footprint, element, subcircuit
| footprint by Tibor 'Igor2' Palinkas on 2017-08-15 | Tags: insight, footprint, subcircuit, terminology |
Abstract: Describe the existing PCB terminology for elements, footprints and the new term subcircuit in pcb-rnd. This article also reveals why new term "subcircuit" is introduced instead of calling it "footprint2", "footprint+", "new footprints" or "pcb-rnd footprints".
Quoting the original suggestion from Peter Stuge:
I only write to ask that you consider calling subcircuits "footprint+", "new footprint", "pcb-rnd footprint" or somesuch. What exactly the name is is not so important, but since all future footprints will be subcircuits I think it *is* important to maintain the existing terminology.
Current situation: element vs. footprint
The good thing is that there are two terms in parallel, even in pcb. This terminology is in pcb since the late 90s.
On the user-level, they are called element and footprint . A footprint is the generic implementation you store in your library, an element is a specific instance that is on your board. You place a footprint on your board, but as soon as you place it, it becomes an element.
On the code-level, the same two things are called element and "library entry". The actual implementation is called element everywhere. If you grep the code (pcb-4.0.0), you will find 161 hits on footprint, mostly in comments and user messages plus a flag called "is_footprint"; then 2686 hits on "element". This is because the code is rather consistent about separating the two concepts and the interaction with footprints is really that small.
It is important to note the difference between the two things, and I was glad to find the original software did make the distinction. For example pcb-rnd started to support more than one footprint format, but in the memory, after you load a random footprint from the lib, the resulting element will have only one format, the native format. This means a footprint -> element is also a format conversion. So for pcb-rnd, when loading from a file or lib or web, a gEDA/pcb .fp is a footprint, a KiCad module is a footprint, an eagle package is a footprint, a mentor graphics cell is a footprint. (Yes, as you see, every single CAD package has a different name for the same thing).
The other aspect is that an element is always an instance, a copy of the original footprint, with modifications to apply to the local situation. For example you will always change the base coords and almost always will change the refdes and the value.
A third thing is how they are stored. In pcb a footprint is stored on the disk, an element is stored in memory or on the disk (when the board is saved). In pcb-rnd a footprint is on the disk, on the web or lives as an element within another board (in whatever format, e.g. KiCad or eagle).
How does subcircuit affect this?
On both the user and code level subcircuit is an element replacement. So it doesn't affect the footprint concept at all.
User level: a subcircuit that lives in your local disk library, on edakrill or in an another board is called footprint, just like your KiCad module or eagle package is called footprint too. In this specific case the actual implementation is a pcb-rnd subcircuit.
Code level: all the code that handles subcircuit are new, written from scratch; at the end the old element code will be removed. We are having a few months when they run in parallel. Since all new code calls itself "subc", it won't cause any collision with the old code that calls itself "element" or "elem".
Conclusion
What is a footprint for pcb, is a footprint for pcb-rnd and subcircuits are footprints and there's zero change on that side. What's an element for pcb will be a subcircuit for pcb-rnd. Renaming that to footprint+ or element+ would make more confusion than using a different name, like subcircuit. I also plan to support hierarchical pcbs, where subcircuit will be a level of hierarchy, so that would cause more confusion if they were called footprints.