kicad-developers team mailing list archive

[xarx@xxxxxx]

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


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.

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)

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