| ID: | 4731 |
| From: | rn...@igor2.repo.hu |
| Date: | Sun, 31 Jan 2021 06:06:43 +0100 (CET) |
| Subject: | Re: [pcb-rnd] Kicad Import |
| in-reply-to: | 4730 from smilie <sm...@posteo.de> |
| replies: | 4732 from smilie <sm...@posteo.de> |
Hi Smilie, On Sun, 31 Jan 2021, smilie wrote: >Hello Igor2, > >then in my opinion... >pcb works not properbly. Sorry, you are wrong on this, pcb-rnd does work properly. Different EDA software have different data model, different way they work. You can never do a 100% lossless transfer between them. KiCad clearly has a different way of using its library. pcb-rnd doesn't try to copy KiCad's library mechanism, we have our own mechanism. (You'll find a detailed reasoning why I won't copy KiCad on this alter in this mail). If you use pcb-rnd, you use pcb-rnd's library mechanism and your project must use that too. In your case, you have a schematics that is not designed to work with pcb-rnd (or in fact with anything else than KiCad) out of the box. This means you will need to invest some time to get it work with anything else than KiCad. If you read back a few emails, I gave you a list of options how to handle this. If you want KiCad's library mechanism or KiCad's GUI, you will have to use KiCad, not pcb-rnd. >In the Footprint description we have a general problem. >In different directories can be files with the same name. > >Vendor_1_Furzbacke/SMD_0603.fp >Vendor_2_Arschkriescher/SDM_0603.fp Yup, this is how it always worked, ever since PCB had library support. We do a simple library search path mechanism here, very similar to how most shells (even command.com on dos and windows!) always did: you specify an ordered list of library directories and we search them in order and we pick the first hit. So if you can't have unique footprint names in your lib, you have three options: 1. set up the order of Vendor_1_* and Vendor_2_* in your library search path so pcb-rnd will find the footprints you prefer 2. fix your library, rename files 3. create symlinks with longer, real unique names pointing to the redundant files and use the symlink names in your schematics; you can place these symlinks outside of Vendor_* directories; that way you can have unique names without having to make any change within the library. About redundant footprint names, outside of eeschema import flow: In theory this could be a problem, in practice, because how our users tend to use pcb-rnd (and previously PCB, for decades), this rarely is a problem and when it is, it can be fixed quickly without code modification. So in practice this is not a real problem. About the eeschema netlist import flow: It is important to understand the purpose of the code. The purpose is that if user A and B are working together as a team, and user A decides to use eeschema for drawing the schematics and user B decides to use pcb-rnd to do the layout it is possible. However, this does require them to work together, and the schematics must have footprint names that will make sense in pcb-rnd. You simply have footprint names that are designed for pcbnew (KiCad's layout program) and you are trying to use pcb-rnd on it. That won't work without you doing some change in data somewhere. Either in the schematics or by setting up the library manally (using file names with colon in them). >The Kicad footprint definition has a "solution" to write directory:file to allow kicad to find and specify suche footprints. >Kicad allow also to abbreviate such constructs to: > >Vendor_1:SMD_0603 >Vendor_2:SDM_0603 > >in the manner of uniqueness. > > >Kicad use : for abreviation in the footprint-definition. >So we do not parse and differ this, then we assume, the directory name is a file-name? >Its not a propper way. The short answer is simply NO. What pcb-rnd does on this is right and we are not going to try to copy KiCad's library search mechanism. Note: I did think over all aspects, even before this email as I did know about the generic problem for years - we even have an experiment about this in the library window for many years based on tags. So this NO to KiCad's library search method is a decision (in other words: there is no point in pushing for it, it just won't happen). Now the details behind that "no". First, you need to understand that we are not talking about how the eeschema netlist is _parsed_: the plugin that understands that netlist does NOT do any library search. We have a common mechanism for library search that is the same regardless of where you got your footprint name from. The library window (GUI) uses the same search mechanism that your import from eeschma or gschem or xschem or orcad netlist. So what you ask for is changing our, pcb-rnd's, global library search mechanism to match KiCad's because you happen to have a KiCad schematic file that doesn't import 1:1. I hope you see why this request won't be fulfilled... Hint: the other day some other user would come who is importing from orcad netlist (yes, we support that) and says orcad has a different library search method and we must implement that. At the end we'd either copy one EDA package's (usually broken) library search method and all the others will fail or we'd have to provide options to emulate many different softwre. Unnecessary complication... On the other hand, we may once, long term, introduce something for the redundant footprint name problem. But whatever we do must be a generic solution because pcb-rnd is not developed as a series of ugly, limited hacks. What KiCad does is the wrong solution to the problem. Just like what we see in their file format and data model, they had a problem and implemented the narrowest possible fix that happens to somewhat solve the current problem, without really caring if the same amount of complication could be used to also solve a bigger domain of problems. That's how they get themselves into features that can be used only to solve narrow problems, unable to combine and that's why they have to add more and more such hacks. I have seen this kind of thinking a lot in PCB and I spent literally hundreds of hours by now cleaning up after such bad decisions. So no, thanks, we are not copying such a broken-by-design idea. Here are why their solution is just too limited and ugly: The first problem here is that what they do is library:footprint. So you are not choosing a directory, you are choosing a library. Which is a rather inflexible way of doing this, as in pcb-rnd with fp_fs a library is just a directory, potentially with a tree of subdirectories and you can reconfigure things so that a subdirectiry becomes a library or a library becomes a subdirectory of a library (a parent directory). This solution is unable to handle any of these. The second major problem is that with pcb-rnd we are not limited to one type of library: we have fp_fs, fp_wget and fp_board at the moment, but we could add further plugins. With fp_wget, using edakrill or gedasymbols, you will get tons of redundant file names coming from the same library, being in differnet directory. So in general: there is no guarantee that file names are unique within a single library! (Not even on a simple file system library). I understand that KiCad introduced limitations about this, but we won't, we are not going to copy limitations of KiCad. The third problem is that this method is limited only to file names and library names while we do have a lot of other metadata to work from: attributes (or tags), unique ID (source ID), file format. Conclusion: KiCad's solution to the problem is just too limited and we are not going to implement it in pcb-rnd. If we ever solve this problem differently than our current library search path solution, the new solution will definitely need to be a more generic one that allows narrowing down the choice between redundantly named footprints based not only on library name but at least: - path pattern (directory name) within the library - attributes/tags - UID Best regards, Igor2
Reply subtree:
4731 Re: [pcb-rnd] Kicad Import from rn...@igor2.repo.hu
4732 Re: [pcb-rnd] Kicad Import from smilie <sm...@posteo.de>