Martin, I've expressed my concerns about your proposal in the bug tracker but I will elaborate on that on the dev mailing list so other devs can give you there feedback as well. Your proposed changes may solve your immediate problem but the present more of their own. What I am proposing is a robust solution that doesn't rely on heuristics and assumptions and does not create maintenance issues for our library devs. Here is what I would accept:
1) Create a custom spice library with the appropriate symbols with custom spice fields. I prefer not to have spice fields in the stanard symbol libraries. If you need footprints to correctly match you spice symbol library, than you should create them as well if you want to product boards from your spice schematics. Most users that I know will create separate circuits for simulation. This also removes the burden of the lib devs to add the "Spice_Node_Sequence" field to every new symbol that requires it. 2) Do not attempt to convert schematic values to spice values (1M to 1MEG). This is a solution in search of a problem. It obfuscates how spice works and will lead to as many problems as it solves. 3) Rather than use a specific field like "Spice_Node_Sequence" to set a single spice parameter, use a generic field name like "spice" with key/value pairs so that you can include any spice specific settings in a single field. For example a "spice" field of "node_seq=C,B,E trans_type=X model=/path/to/spice_model.sp1, ..." could be used to set the node sequence, the spice transistor model type of a transistor symbol, and the spice model file for a symbol. No need guess about the transistor spice model type. This would be fairly straight forward to do with wxStringTokenizer. You would need to decide on a separator that makes the most sense. A space would probably not be the best choice if you want to use file names and paths. A ; or : might be a better choice. On 11/3/2015 10:44 AM, x...@sms.cz wrote: > Hello, > > I reported the bug #1511552 and suggested to provide a patch. I'd like to hear > your suggestions and objections to what I was to going to do. > > In short (details in the bug report): > > In EESchema, it is hard to create a schema that can be used simultaneously for > Spice simulations and Pcb creations. For instance, because the pin order of > the components for Pcb and for Spice needs to be different. The following two > patches have resolved some of the problems: #706558, #743027. But there are > still other problems that persist: > > 1. Prefixes of component references in schemas follow different conventions > (e.g. https://en.wikipedia.org/wiki/Reference_designator) than those required > by Spice. > > 2. Component values (like 3k3 or 2M7) commonly used in schemas don't work in > Spice. > > 3. The default KiCad component libraries are not prepared for Spice > simulations. Which is a problem for a KiCad newbie who a) does not have his > own modified libraries b) isn't even aware of the need of such library > modifications and wonders why the simulation doesn't work (like me some days > ago). > > So I'm proposing to create another patch in the line of the two already > accepted patches, as described in the bug report. I'm aware that the current > Spice netlist exporter is poorly designed and that the two already accepted > patches are kind of hack. And my patch will be no different. But I don't have > time and energy to implement a full-featured Spice support. > > Please, read my intended patch design in > https://bugs.launchpad.net/kicad/+bug/1511552/comments/2, and provide comments > and suggestions. So that I don't spend my time on an improvement of a feature > that will be rejected then. It's possible to implement only some of the > suggested points, and leave the rest for a post-processing. > > Thank you, > Martin. > ______________________________________________________________________ > Vystup z řady a zřiď si taky originální email! @bigboss.cz, @dablik.cz, > @potvurka.cz, @tajny.cz... zdarma na http://email.sms.cz > COMDOM Antispam - www.comdomsoft.com > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
