kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #21229
Re: Bug #1511552 - Fixes to Incorrect export of Spice net-list from EESchema
On 11/11/2015 5:26 AM, xarx@xxxxxx wrote:
>>> 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.
>
> I meant this post: https://lists.launchpad.net/kicad-developers/msg21148.html
> If I understand him correctly, Mark wants to replace the current netlist and
> BOM generators with plugins coded in scripting languages. In that case I could
> create my own plugin and generate netlists my way.
>
>> 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.
>
> My patch has an option in the netlist dialogue. So it's not a property of
> component definitions.
I missed that. A dialog option is fine.
>
>> I just looked at the Eeschema documentation and none of this is documented
> ...
>> 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.
>
> I agree that everything like this should be documented in the eeschema
> documentation. But actually, the user fields are not (and haven't been)
> completely undocumented. When you open the generated netlist, you'll see the
> documentation there.
Expecting users to open a netlist in a text editor to see the
documentation is a bit of a stretch don't you think?
>
>
> Anyway, it seems to me that your position is that KiCad should be for PCB
> creation only. If anyone wants to use KiCad for circuit simulation, that's his
> own fight, and you're not going to provide support in KiCad for this, Though
> you are able to tolerate some, like the "spice" user field we were talking
> about. I don't mean it as an attack against you, but it would be fine to
> clarify your position about this. Can you confirm that or explain your view of
> possible KiCad - Spice integration? Because every other your answer in this
> area depends on your general view of this integration. (When answering, please
> completely ignore my particular patch, for the moment.)
>
> If I'm right, that would explain:
> * why you are so strongly against any modification in standard libraries
> (changes that are not connected to PCB)
> * why you prefer that people used their own libraries for simulations (the
> KiCad ones being reserved for PCB creation only)
> * why you prefer that people used separate libraries for simulations and PCB
> creation (currently there's no other option, so they have no choice)
> * why there's no standard way in KiCad for integration with Spice (and
> everyone does that his own way; that's why you may be right when saying "You
> may be the first person
> other then the dev(s) that committed these changes to even use this.")
> * why there is still space for eSim (though it adds so little value)
>
> Again, please do not take that personally. But I feel that further discussion
> would lead nowhere until you clarify your general position.
This is just flat out false. I'm not sure how you made the leap from me
asking you to make some changes to your code and copying some symbols to
pspice.lib to Wayne thinks "KiCad should be for PCB creation only".
Here is my position. I am the project leader for better or worse. When
I ask you to cooperate with me and make changes to your code for long
term maintainability, that means I will not accept them until you make
said changes. I'm not doing this to make your like difficult or to
stoke my ego. I'm doing this to make my life and the and the life of
the next dev that works on the spice netlist exporter easier. I
actually like what you changes do. I just don't like the way that you
are doing it. I do not know how to make it any clearer than that. If
you are not interested in making these changes, just say so and that's
the end of it. My feelings will not be hurt in the least. You can
always keep your changes in your own working branch and publish them if
you wish.
>
> To be constructive, my idea is different (than that I've described above). I'd
> like:
> * to have "agnostic" component libraries that could be used both for PCB
> creation and simulations
> * to have the integration between KiCad and Spice standardised at the KiCad
> level (so that new KiCad users can start simulations immediately, without a
> need to prepare their own libraries and post-processing scripts)
The KiCad policy (although it is unwritten) is to provide generic symbol
libraries. Virtually everyone I know creates there own custom symbol
libraries. Myself included. This not just KiCad. This is true for the
commercial EDA products as well. We've been asked in the past to create
fully qualified symbol libraries with fields defining manufacturer, part
numbers, etc. but have declined due to the huge amount of maintenance
involved. I don't see the spice fields being any different in this
regard. My bet is most users will end up creating custom symbols for
their spice simulations. It's a fools folly to try to accommodate the
requirements of all users in this regard. That's why our symbol
libraries are minimalistic.
>
> I imagine that when one is creating an el. schema, he can copy a part of it,
> simulate it, correct it and copy it back. (The functionality that allows to
> copy a selection in a schema and paste it elsewhere is missing in KiCad, yet.)
> That would allow KiCad to be used during the whole circuit life-cycle, without
> a need to switch to another application.
>
> Thanks,
> Martin.
>
>
> ----- Původní zpráva -----
> Odesílatel: Wayne Stambaugh <stambaughw@xxxxxxxxx>
> Příjemce: kicad-developers@xxxxxxxxxxxxxxxxxxx
> Datum: Tue, 10 Nov 2015 19:29:09 -0500
> Předmět: Re: [Kicad-developers] Bug #1511552 - Fixes to Incorrect export of
> Spice net-list from EESchema
>
>
>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
>
References