kicad-developers team mailing list archive

[xarx@xxxxxx]

Wayne,

thank you for your reaction. Here I'll state how I see it and comment your
answer.

At first, I'd like to say that I tried to make no revolution, but only to
extend the functionality that already IS in KiCad the same way it is
implemented NOW. I can imagine a better realisation of the functionality I
implemented. Especially, if KiCad supported plugins, I would create my own
plugin and didn't try to persuade you to accept my patch. Hopefully, if Mark
Roszko implements a general netlist generator he announced, the problem might
get resolved.

In point 3) you write that you don't like the user field
"Spice_Node_Sequence". Neither do I. But this user field IS already supported
by KiCad, I didn't make it up. And there is also another one, "Spice_Model"
(or rather "spice_model"). They were introduced in a patch five years ago, see
my bug for the reference. So I only added a third field. And tried to stay
backward compatible. Technically I could do it the way you suggest, but this
would require diversion from the way how the functionality is implemented now.
I tried to avoid that in the perspective that my patch will be accepted more
easily.

In point 2) you suggest not to translate schematic values. My view is this:
When you draw an electric schema, you follow customs of electric schemas -
e.g. you use "Q" for a transistor reference and "2M2" for a resistor value.
Why should you break this convention only because you're going to use the
schema for Spice simulation? My idea is that the schema should be "agnostic",
it should look the same and use the same components whatever the purpose is
for which it was created. Of course, you can say that you don't want it to be
agnostic. But why, if this can be achieved quite easily?

There is also another way how to look at it. KiCad uses a language, Spice uses
a different one. The intent of the netlist exporter is to do the translation
from the KiCad language to the Spice language. If you speak English and your
collegue speaks Chinese, you would use English words in your speach, and not
mix it with Chinese words to make the task of the interpreter easier. The same
way, there's no reason for why you should use Spice values in your KiCad
schema, you should keep with standards.

I've already tried to create several schemas with standard KiCad libraries in
my patched copy of KiCad and simulate them directly in NgSpice and LTSpiceIV.
And that worked like a charm. So why to defend against that possibility?

In point 1) you mention mainly maintenance problems of the libraries. In fact,
I patched the libraries only because I thought it might be a good idea to help
beginners with KiCad. As I remember myself how much effort it was to learn
that I cannot use the standard libraries for simulations. And then to find
libraries that work. Because e.g. the KiCad "pspice.lib" does not work either
(the diode there has an incorrect order of pins). But the modified library is
not a merit of the patch, it's just a bonus that could help others. I accept
that there may be a problem of maintenance. But also, I'd like to emphasize
that the libraries are not altered in any way, they are only amended with the
information on Spice fields. They will work and look the same as before.

To summarize it:
Some of the changes can be performed in a post-processor. But not the
correction of pin order and of reference prefixes. Because this information is
not available to the post-processor. It should be part of the component
definition, or be manually inserted into the el. schema.

Anyway, the (code) patch is rather small and - in my view - makes working what
should have been working already.

Best regards,
         Martin.


----- Původní zpráva -----
Odesílatel: Wayne Stambaugh <stambaughw@xxxxxxxxx>
Příjemce: kicad-developers@xxxxxxxxxxxxxxxxxxx
Datum: Mon, 9 Nov 2015 16:10:24 -0500
Předmět: Re: [Kicad-developers] Bug #1511552 - Fixes to Incorrect export of
Spice net-list from EESchema


> 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, xarx@xxxxxx 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@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> > 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


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