I have no intention of embedding spice models in KiCad symbol files. The current method of assigning spice information to symbols using fields works very well so I don't see any reason to change it.
Cheers, Wayne On 1/2/2019 5:32 AM, kristoffer Ödmark wrote: > I agree with Carsten Here, > > The same way the footprints are not part of the symbol, the same way > SPICE models should be defined separate. > > I would rather have a new atomic file-format or storage format, so one > could actually send a complete part in an easy way, that would include > 3D-Files, SPICE data, symbol and footprints, and it would also mean that > one could do the mapping to pins in that directory or file instead. > > And since the discussion about adding a manufacturer part number to > libraries went nowhere, I cannot see how adding a SPICE model would fit > here, and if SPICE models are added. Well then I suggest we add 3D-Files > and Footprints as well, no use in half-assing it. > > - Kristoffer > > On 2019-01-02 11:27, Thomas Pointhuber wrote: >> Hi Carsten, >> >> Unfortunate, I don't think the reality works like that. While my >> experience with SPICE is quite sparse (especially inside KiCad), I do >> NOT think in this case about open and free spice model for IC's. Not >> everyone uses the KiCad supplied libraries but their own, and simple >> spice stuff like putting some resistors together for an R-Network can be >> done in the official as well. >> >> Fully separate spice out of the symbol would not work anyway because >> from what I noticed spice pin does not map to symbol pin in many cases. >> You need to link that somewhere anyway. I'm heavily in favor of >> simplifying handling of simulation for users. Integrating this into one >> file would be less error-prone than separating simulation into multiple >> additional files. Including external SPICE models would then be an >> option, but not necessary. >> >> A modular approach where SPICE is only one of many possibilities is in >> my favor, but in a different way than you proposed (integrated in the >> symbol). There is for example the topic of digital simulation, which >> would require different types of models. We should at least think about >> it so it can be integrated later in a nice way. >> >> Regards, >> Thomas >> >> Am 02.01.19 um 11:05 schrieb Carsten Schoenert: >>> Hello Thomas, >>> >>> Am 02.01.19 um 10:39 schrieb Thomas Pointhuber: >>>> * I do not see anything related to SPICE in this document. I would vote >>>> to add it including the possibility to embedded spice models >>>> (BASE64-encoded) into the symbol itself. >>> I disagree on that. >>> Please do not mix two different main purposes and add more complexity. >>> >>> Schematic simulation is a add-on, not a primary key feature of a symbol >>> format or within Eeeschema. >>> >>> Including such stuff into a schematic symbol make it harder to maintain >>> the symbols in along term as you always need to touch the symbol no >>> matter what peace need a update. But the (new extended) symbol format >>> can get of course a new field of course for a referenced file to look >>> at. Like similar done for associated footprints. Add a new environment >>> variable like SPICE_MODEL_DIR to add a default folder. >>> >>> Currently it's not clear how a open and free spice working model can >>> look like, I really suggest to not create a own world for spice models. >>> Make it modular so work needs to be done more than needed. >>> >>> I also suggest to get in touch with Holger from the ngspice project >>> about his thoughts and possible suggestions on this topic. >>> >> >> _______________________________________________ >> 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 _______________________________________________ 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