[ Belatedly changed the subject, to look better in that thread hijacking trial. ]
Thanks for your description. Now I understand better where those "heavy symbols" come from. Okay, not crazy. Not at all. But still flawed ;-) I agree that CPNs make things a lot easier, but managing them also has a cost. I don't quite agree that doing everything manually is very nice for casual users. Granted, the damage a mistake can cause is small, but I think we should be able to do better than this, without creating too much of an administrative burden. Now to the main issue, the "heavy symbols." It seems that there are two ways to get the CPN into a symbol: 1) put it already in the library, or 2) add it in the schematics. 1) has the benefit that you can also populate the fields for all other parameters. 1) has the big drawback that your library contains lots of duplicate information. 2) avoids this problem, but has a high risk of the visible information in the schematics and the invisible CPN diverging. To help with 1), one could separate the CPN-specific field values from the symbol and have a table of field values for each symbol. E.g., you'd put, say, your R, and then you could pop up a parametric search over a table with entries like CPN12345 R=100k TOL=5% FP=0402 V=50V CPN12346 R=100k TOL=1% FP=0402 V=50V etc. In many cases, that table could even be auto-generated from the CPN/OPN tuples from the MPR and a universal table that maps OPNs to parameters. Quite often, the latter can be machine-generated as well. To help with 2), the MPR could use the same kind of information to check if things really do match. The system I've written in actually quite similar to 2), only that it doesn't make the CPN explicit. Am I making sense so far ? Particularly 1) has the issue that the same CPN can be associated with multiple sets of parameters. E.g., the CPN12345 from above would also be compatible with a specification of only R=100k FP=0402. Now, do you a) include all CPNs that are compatible with the requested parameters (leave it to the MPR to pick one it likes), b) oblige the user to specify more parameters until only one CPN is left, or c) introduce a separate CPN if the list of parameters isn't identical, e.g., CPN12345 R=100k TOL=5% FP=0402 V=50V CPN23456 R=100k FP=0402 ? By the way, for narrowing down under-specified parameters, the price is often a useful guide. Common parts tend to be cheap, > A BOM generator in KiCad should really not be over complicated. For case 2) with an implicit CPN, very little would be needed in eeschema. The existing BOM format is already good enough. All other information can live outside of eeschema. 1) would be much nicer, because it also eliminates all sorts of data entry mistakes (or at least moves them away from the process of making the schematics), but it would be more invasive for eeschema, because you'd need the parametric search dialog. By the way, regarding use cases, let's not forget collaborative projects, where a design is shared with a large audience that may have wildly different preferences for manufacturers and distributors. Case 2) with an implicit CPN would be ideal here. - Werner _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
