kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 11/9/2015 6:30 PM, xarx@xxxxxx wrote:
> 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.

I don't think Mark's changes help in this situation.  Plugin or no
plugin, you still need a way to export spice netlists.

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

You are proposing adding a third field to an already questionable design
in spite of not liking the design either.  This was my point.  I don't
have a issue with breaking the current behavior.  My concern is keeping
the code in KiCad manageable.  I doubt fixing this in a sane manner will
effect many users.  I just looked at the Eeschema documentation and none
of this is documented so most likely the only person who ever used this
was the person who committed the changes.  You may be the first person
other then the dev(s) that committed these changes to even use this.  I
doubt many users would have the skills to sift through the kicad code an
find the spice netlist exporter and figure out how to use the custom fields.

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

As long as it's an option in the spice field, I'm fine with that.  I
don't want it performing this translation by default.  I personally
would be upset if I exported a spice netlist and my component values got
changed without my consent.

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

This is exactly why I am asking you to come up with a better design.
The last person to commit the changes five years ago made those changes
because it "worked like a charm" for them.  However, they failed to see
beyond their own immediate need.  As project leader, I don't have that
luxury.  I have to think about the long term maintainability of the
kicad code base.  This kind of thinking is why parts of the kicad code
base are so ugly.  They are a series of "works like a charm" patches
with no regard to design and maintainability.  I'm doing my best to
reverse that.

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

This one is a no go for me.  I grepped all of the symbol libraries and
there is not a single spice field defined in any of them.  If you want
to copy your modified symbols to pspice.lib, that's fine but don't want
you spice field in the standard symbols libraries.

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

If you are going to make the changes I suggested, please consider
updating the eeschema documentation so that users will know how to
define a spice field and what the options will allow them to do.
Otherwise, the only people who will know this even exists are you and
the few folks who followed this thread.

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