>> In my opinion, a solution similar to how eSim does that, would be completely >> sufficient for start. As I've already mentioned for several times, that's not >> much code, so it could be implemented relatively quickly. (But using eSim for >> that is not a solution, because eSim cannot fulfil the task without changes in >> KiCad itself. And especially it cannot provide standardisation.) > >I cannot comment on eSim. I've never used it.
Basically, eSim *dynamically* creates a tabbed dialog that allows to choose the simulation type, to set properties of power sources, and also allows assigning spice models to complex components like ICs. And that's all, essentially. > The decision to provide agnostic symbol > libraries was made a long time ago due to objections from both users and > developers. The main argument for agnostic symbols was that no one > could agree on what we should provide which meant most users would have > to remove the stuff provided by KiCad and add their own fields which was > more work than just adding their own fields. ..... > My guess is most board layout users will never use the > simulator so the spice field(s) would only complicate things. You meant probably "against agnostic", not "for agnostic". I think that all these problems arise from the fact that KiCad has no official support for simulations, yet. Once it is decided which simulation engine is officially supported and some work is done on that, most of the resistance will disappear. Because everyone will understand that if KiCad supports a simulation engine OFFICIALLY, this gets reflected also in the KiCad libraries. >> * There's no need for having to explicitly place voltage sources into the >> schema for the purposes of simulations, the way how LTSpice or eSim do that. >> If the netlist generator sees e.g. a "+12V" connector/net, it could generate >> the 12V voltage source for that automatically. > >This is limited to dc analysis. What about ac sources for transient and >sweep analysis. This would require a lot of additional symbols to >represent them. I'm not saying that it is always that straightforward as I drafted that, but I believe it is doable. Actually, I'm using the same approach even for AC analysis, though I haven't tried the more complex types of analysis yet. But I guess there won't be much difference. I've also tried tools like DViewer (a simulation of digital oscilloscope for LTSpice, a really helpful tool, http://www.spot.pcc.edu/~ghecht/LTspice.html), and they could be generated in automatically too when needed. If the automatically generated component won't be appropriate, the user will always be able to disable it. Anyway, now I shall modify the netlist exporter the way you suggested. Then we'll see what next. 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
