The current Eeschema - ngspice interface has been defined three years ago and has not seen any update since then.
In my view it is a good idea to start a new thread discussing user friendly improvements.
So once I (not being a PCB designer) had the view that one might add an additional layer in Eeschema that allows to encircle a portion of the complete schematic. And only this portion is to be simulated. The circle crossing any interconnect line would cut it. Then either an extra input to this line is to be set or the line allows a measurement, acting as output. This would (hopefully) make different schematics for PCB design and simulation obsolete.
I guess many other, better ideas might surface up, and your inputs are welcome. Solid ideas should then move to the KiCad bug tracker, that now will serve as our input for the developers.
I still like the independent of running the ngspice simulation while work with eescheme. It not blocking the app, and it can be plot, and doing math under console. I only wish the piloting windows in ngspice improve it way for refreshing the draw to avoid long delay every time windows move, or change focus. Like doing a image buffer for draw graph instead or redraw every points all the times, and every mouse clicks.
As far as the entry in launchpad (https://bugs.launchpad.net/kicad/+bug/1814188) is concerned, my thoughts are:
Multiple plots would be nice, especially if different scale to the axes are in order (a mV signal is lost if there is a V signal plotted at the same scale). Hiding a signal easily would be as well. I feel point 8, the legend, is very useful.
My own thoughts:
It would be nice to be able to set the path to the ngspice library somewhere in the gui. It would probably be handy to include that specific to a certain schematic with a global default. It would be good if the version of the ngspice libs was show somewhere, for instance as part of a first line in the simulation output at the bottom left.
As far as your suggestion for limiting the simulation to a part of the schematic, I would like to suggest to use a sub schematic for that as an interface. It is not ideal, but it is probably easier to implement and easier for the developer to discern which signals/connection are added specifically for the simulation and which belong to the schematic.
Hmmm. I will have to think about this one, I guess: It would be need if we could find a way to set up a schematic for simulation and PCB generation without the need to change in between. There currently is a “do not use for simulation” field in the properties of a part; perhaps we need a property “do not use in netlist for PCB” as well to prevent pcbnew from complaining about parts that are only there for the simulation.
One other thought is the annoying need to fill in “alternate node sequence” on many of the real world parts. It would be neat if the alternate node sequence would be included in the parts definition, but I hesitate to mention it, as it requires a library change.
After the change from KiCAD4 to KiCAD5, which was a huge improvement by the way, but I think I prefer the libraries to be more or less stable… Perhaps it is better not to tinker the library definitions, again.
Needless to say:
Any change in the gui, please do not break existing schematics. Some have been a lot of work to get working in the simulator (searching for lib’s, alternate node sequence, etc.etc.).
Yeah, it sucks that the need for the alternate node sequence can’t be eliminated since there is a natural disconnect between SPICE netlist order and pin numbering on real parts. Simplest example I can think of is a SOT23 BJT. Almost always the pin order is 1-Base, 2-Emitter, 3-Collector. In SPICE, the netlist order is 1-Collector, 2-Base, 3-Emitter.
I do like your idea of putting the alternate node sequence in the part library. To avoid your concern of breaking existing schematics, the alternate node sequence on the schematic level (if existent) can simply override anything provided at the library level.
At the minimum, I think simply changing the way of entering alternate node sequences into the program can make things much easier for people. Instead of an cryptic ordered list of numbers, you can have some GUI method of presenting to the user “Hey, which pins are collector, base, and emitter?” after you tell the program that this device is a BJT. Maybe a dropdown or something for each terminal…I dunno??? Should be able to work for most other basic semiconductors and even opamp subcircuits. Numbered list should still remain for advanced users.
I am talking from the point of view of a passionate, in my opinion some focus should be put on making a base library with transistor/mosftet (pnp and npn), zener, Schottky, optocoupler, etc.
Every time i simulate a circuit i put the symbol in the schematics then i lost half an hour to find a suitable model for that part. If kicad could manage this it would be a great improvement
Providing models is not our job. (The kicad library is there to provide symbols/footprints for kicads core job which is creating a pcb. For that we need to ensure we are following industry standards which are in a lot of cases counter to what the spice side would require.)
We can not take models of third parties because of licensing and even patent concerns. It is not feasible to create our own models because we do not have the data required to make anything above the most basic models which are of no use for anything but teaching. (And these basic models are already part of ngspice.)
A simple small signal model is possible from values of the datasheet. Such models are supplied with ngspice (Or at least i assume they are.) and are easily filled with the parameters given in the datasheet. (read the ngspice documentation for details)
What is impossible without manufacturer support is a model outside the normal operation range (where linearization no longer works)
This means if you want a model of a part, talk to the manufacturer (They are the only ones with access to all the required documentation). In a lot of cases part model access will require you to sign a non disclosure agreement (For getting access to unencrypted models).
The only things we can feasibly provide are example symbols filled with example values like we did with voltage/current sources recently.
In general i feel it is not a good idea to just simulate the schematic used for creating the pcb. Creating a pcb requires a different set of information compared to simulation. (In a lot of cases you might want to simplify your circuit for simulation. And with the pcb definition side getting more powerful with v6 this need of simplification will grow further.)
Agree
Usually I do only digital simulation with not more then 5 components in a separete project. I will talk about what happened yesterday, but this is not a complain or a request of help, it is to show what kind of problems an enthusiastic face with kicad: I drove a simple schematics with a voltage source, transistor, a few resistors and a zener diode. I already had the transistor model, then i started the simulation, but there was something odd, after 30 minutes of various check i understood that the problem was with the zener diode (I assumed that it was like a resistor and i didn’t need a library/model for it), so after understanding my error i found a library online, i added it to the simulation and it worked
we do not have the data required to make anything above the most basic models which are of no use for anything but teaching
Now (and before) I am talking as a complete profane to ngspice, but in my humble opinion this won’t be so bad as a starting point.
Also coming back to the problem of licensing/patent, am i wrong or kicad is becoming better and better day by day, more and more people are using it, it is founded by the CERN, isn’t this enough to ask to some manufacter if they want to contribute with some open source model and release them with a license that is usable by you? They will get visibility and, more important, a pcb designer is more inclined to use their product because he knows that them worked in the schematics
Most semiconductor manufacturers (Including the one i work at right now) are in the mindset that anything that is published can lead to them loosing an advantage over competitors. This at the least means they want to stay in control who gets what and that is exactly the opposite mindset to anything related to open source. (One of the reasons why pspice added support for encrypted models. The kicad devs categorically dismissed any support for something like this as it would violate the core idea behind open source.)
Take the license of ltspice as an example. It gives nearly everyone a pass to use it with one major exception. Anyone associated with a competitor of theirs.
I am too far from this context to deeply understand all the motivation behind the manufacturers choice. (I just know that open source in same context improved the advantages over competitors)
Anyway I am not sure if my comments in this post are useful (if not, just say, it is not a problem), so I will try to add the last idea:
Would it be possible to collect a list of parts from open source libraries or anyway patented with a compatible license? For example I just found this http://espice.ugr.es/espice/src/modelos_subckt/spice_complete/ from the university of Granada which, if usable, is already quite a good starting point.
Once a kicad library will be created and shipped with the program when the user is in eeschema and try to add a component it would be perfect if an icon appear near it, meaning that that part is already present in the kicad-base-library (and so simulation-ready without any hustle of googling modules buried deep inside old forums). A concept of what I am talking about:
Then the Spice Model Editor should be already filled with all the needed things like file path to the library and model (and I don’t know if more is needed)
If at this point of history we are able to collect only 30-40 modules it is always a starting point, release after release more libraries will be added, more people (who knows how to use a ngspice) would contribute and finally the eeschema-ngspice integration would be stupid (like me) free
It only parses the lines with a dot in front of them and ignores the rest. I found an old article that suggests that KiCad 4 was able to use a “+PSPICE” string before the text block to help with this. But a followup article from the same author said this functionality was removed in KiCad 5.
The forum is in no way the right place to add feature requests. It simply does not have the required feature set to double for this task. That is what the bugtracker is for.
@holger started this thread to ask for suggestions. That’s all I’m doing. It’s up to him if he wants to add them to the bugtracker himself. I’m not suggesting this is some sort of official repository of feature requests, and neither was he.
As far as providing spice models for parts is concerned:
The question “which model” would arise for every part. There is not only one possible spice model for each part, because the model used would depend on what it is you are simulating.
A simple model would suffice if you are trying to verify the functionality of your schematic. However, if you are doing, for instance, a noise analysis, you would need different models for almost every part, because they would need to include noise specific behaviour.
Same for simulations at grossly different temperatures, to verify the schematic will continue to work under extreme circumstances.
Same for simulations under vibration.
Etc.
In short: The models used for a particular part depend on what you want as a result of the simulation. It would be nearly impossible for the KiCAD library development team to provide all possible models for all possible parts. Indeed, it is almost impossible for manufacturers themselves, because it is a lot of work to develop all possible models for all parts in all extreme conditions.
