kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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
>