kicad-developers team mailing list archive

[<xarx@xxxxxx>]

>> 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