Adv custom spice

[failiz]

This code is just an initial implementation for feedback.

This commit (with the respective commit in the parts repository) implements parts where users can adjusts their spice models without creating new parts. This can be useful in debugging simulations. Each part defines its own property "spice model" which thus can be different from other parts. For now, two of the parts are implemented: diodes and NPN transistors, but there are several more if this is proposal is accepted (see ngSpice manual).

[failiz]

One issue with just having a unique moduleID for all the custom spice parts is that the only thing that you can change is the source model.
The immediate solution would be to create different module IDs for each type of component: DiodeCustomSpiceModuleID, TransistorCustomSpiceModuleID, etc. Then, we could change the spice model field and other relevant properties (e.g., max current, max power, etc.) through the inspector pane.
A better long term solution (but much more difficult to implement) would be to modify the code of the properties and let each fpz file to define if a property is editable.
What do you think? Should I implement the first option? We can always change the parts and reduce the number of module IDs when the serving option is implemented in the future...

[KjellMorgenstern]

There is already an something similar: "Editable pin labels". But I am not sure if this would help or is needed.

Lets look at the use cases:

1. Easy experiment with spice models.
2. Share parts with custom spice models, eg a FZZ
3. Provide "ready made" parts that have preset (somewhat reviewed) spice models, via Fritzing releases

Once the spice model is an editable property, case 1 and 2 should already be covered.
One problem might be that incorrect spice models can not be parsed, and might lead to crashes? ( If someone would like to create a Parsing Expression Grammar (PEG) for this I'd be happy to integrate such a syntax check. But a less engineered solution might be possible as well )

For 3. we already have the possibilty to publish parts with spice models, no changes needed.

[failiz]

"But I am not sure if this would help or is needed." Not sure if you are talking about the editable pins, the modifiable spice fields or the special spice parts.

I really think that there should be a way to modify the spice field of, at least some, parts. I am not sure if all of them should be modifiable or just a few special ones.

Regarding the necessity of modifying spice fields, this come from the fact that some times you want to use a specific model (for example, a model of a specific diode). Then, you need to add the spice model to the part. This is very common as most of the licenses of the models do not allow redistribution. Right now, the only solution is to create a new part, which is time consuming. And if there is an error or you want to modify something, back to edit the part and regenerate the database...

If we allow that all parts can modify their spice fields, there are a few issues. First, a specific part that has a specific model for that part could be changed to something to doors not model that part. E.g., you have a model for the 1N4001 diode and the user changes it to be another kind of diode. It's the user mistake, but a person who recovers that sketch will guys that the model still represents an 1N4001 diode af the part of called 1N4001. If the model cannot be modified, this error disappears. Second, another source of error could come if, as you said, the spice model is not correct. Then, the simulator will not work and an error message will be shown, I do not think that it will crash Fritzing. But users could complain about things not being able to simulate. A parser for the spice model is a possibility, but I do not think it is very useful and it will take some effort to program. As most models are copies from a library/internet, most of the time it is just copy and paste a line of text. Most persons do not change the different parameters of the model. Third, the readability of the spice file (the spice circuit) decreases. If each instance of a part had its own spice model, the models cannot be reused. A circuit with 3 transistors (all the same kind) will get three different spice models, even if the models are the same. We could clean up this, but it will need some code.

The above reasons put me to think in only some special spice parts, where the source field is a property. The drawback is the multiple moduleIDs necessary. Also, if the user wants a special part with a different BB or PCB layout, it will need to generate a new part.

Maybe an intermediate solution would be to have to do something to enable the modifiable spice field, like check an enable or double click on the spice field. But this would require more changes in the code.

More complex spice models would also require a text box rather than just a line of text. For example, you may want to create spice models which are made with subcircuits and need several lines of text.

[KjellMorgenstern]

Sorry I was unclear. I am not sure that we would need a switch to make the spice field editable.
For example, there could be 'generic' spices parts with editable field, in addition to the parts we already have.

[KjellMorgenstern]

The main issue I think comes from not being allowed to redistribute SPICE models. Does this apply for each individual model, or does it apply for the collection of spice models (similar as with collection of CAD files for electronic parts) ?

Of course we should allow users to enter their spice models. But we should not encourage people to copy and redistribute those protected models.

[failiz]

Sorry I was unclear. I am not sure that we would need a switch to make the spice field editable. For example, there could be 'generic' spices parts with editable field, in addition to the parts we already have.

Ok. So basically you are ok with the current pull request: Normal parts do not have editable spice fields and there are special parts for that.

Then, the only issue is that I would like to create several new module IDs: DiodeCustomSpiceModuleID, TransistorCustomSpiceModuleID, etc. If there is only a generic CustomSpiceModuleID, the parts cannot edit other properties (like max. current or max. power). Or can you imagine another option where we indicate somehow that the part has an editable spice field. Maybe "editable=yes" in the spice tag of the fpz file?

[failiz]

The main issue I think comes from not being allowed to redistribute SPICE models. Does this apply for each individual model, or does it apply for the collection of spice models (similar as with collection of CAD files for electronic parts) ?

Of course we should allow users to enter their spice models. But we should not encourage people to copy and redistribute those protected models.

This is one of the reasons why I want to make this parts with editable spice fields. We cannot redistribute the spice models, but if the users can find them, we can allow then to just copy and paste that model into the part.

More models that I have seen come with a copyright notice. You can find them sometimes in the datasheet of the component or at the manufacturer website. I have seen collections of spice models, but they usually come with copyright.

We should not encourage them to redistribute the models, but if they do it it's not our fault. In any case, we should be careful when committing spice models to the repository.

[KjellMorgenstern]

How about a table

PartID	SPICE
XYDiodeModuleID	spice default
XYDiodeModuleID	spice other popular model
XYDiodeModuleID	<custom model 1>
XYDiodeModuleID	<custom model 2>

A diode would use the default model, but you can select a different one.
Users could also add their own models, and they will appear in the select box.

I think the UX problem (adding an own spice model) could be solved easily, e.g by just having <add> included as one of the options.

This would avoid the confusion about having multiplte identical looking diodes, but one has a fixed spice model, and only the other can be edited.

This would be similar to existing property.xml presets e.g. for capacitors.

[failiz]

Mmm, I'm a bit confused. The table seems that you are proposing to make this for all parts and not have parts with editable field and others without them. Have you changed your opinion (or maybe I understood you wrong before)?

I am not sure if a table is a good idea. It seems less intuitive to have to modify a table. And if an user needs several different diodes, he would need to use several different parts to get all of them (I'm guessing that one part ID will only have a spice field). I think it is easier to understand that the spice model is defined in the fpz file and bit in a table somewhere else.

If we add an for the spice model, we should explain if the new spice model affects all the parts or just that instance.

Regarding the issue of having multiple diodes and some with editable spice fields and others not, we could add "custom spice" label or a small symbol next to the part to differentiate those custom spice parts from the normal ones.

[KjellMorgenstern]

Currently, I tend to avoid treating them as different parts. My concern is, there would be no visible difference, and it would be confusing why sometimes the spice field can be configured, and sometimes not. Also, we would have to manage all the duplicated parts.

The table would not be displayed directly, it would just be a better data structure to use, with less duplication.
The table could store: Actual spice model, associated part / possibly part family , icon, short name, description

If you select the Diode, it would have the default spice model. The spice model would be a property where you could select different options, premade and custom.

For example: You have a part with ID "XYDiodeModuleID" , and our internal table would have four matches for that ID, then those four matches will be shown in the Spice property selection in the inspector. A fifth option to select would be "add" or "manage" ... users could add their custom model there, and it would be available as an option for all other "XYDiodeModuleID" in the Fritzing project.

A little extra could be to display different icons of curves next to the select options, eg for diodes:

Would you like to have a visual representation in the breadboard / schematic view, if a different spice model is used? We could enable the part label for that by default.

[failiz]

Currently, I tend to avoid treating them as different parts. My concern is, there would be no visible difference, and it would be confusing why sometimes the spice field can be configured, and sometimes not. Also, we would have to manage all the duplicated parts.

That is true, but we could add some "SPICE" symbol over the schematic or the part in the BB view. I am not sure if we need to duplicate a lot of the parts. The editable spice parts would be generic and we would only need a part for each type of spice instance: resistors, capacitors, diodes, different kinds of transistors, power supplies, etc., and maybe a generic IC part for spice subcircuits.

I agree that making all of the spice fields editable is maybe neater from a UI point of view, but it is much more work to implement:

1. The spice field of the parts should behave like the properties.
2. Move from file-based spice models to global-based models. The default spice contains lines and models. Lines define spice components and models define spice models for the spice components. From the ngspice manual:

For these more complex device types, each device element line contains the device name, the nodes the device is connected to, and the device model name. In addition, other optional parameters may be specified for some devices: geometric factors and an initial condition (see the following section on Transistors (8 to 11) and Diodes (7) for more details). mname in the above is the model name, and type is one of the following fifteen types

Right now, the spice model of a part is applied to all the instances of that part and each instance generates a spice device. But if we allow being editable, the modified model needs to be applied to only that instance. To do that, in this PR I modified the name of the model to be "MODEL_{instanceTitle}". The {instanceTitle} label gets replaced by the actual instance title of the component when generating the netlist: e.g.: MODEL_D3 for diode 3. Thus, we avoid having several models with the same name (but being actually different models).

3. Check for unique model names: Right now, there is no check that the models are unique and ngspice does not care about this (I think it uses the last one, but there is no error). This could be a problem. For example, the same spice model name but with different parameters can be used in two different parts. If these two parts are present in the circuit, both of them will end up using the same model. If we move to a global-based model we could check for this. The same applies to subcircuits.

4. Gathering models from the part files? A way to not have a global file with models for components could be to generate the table when regenerating the part database. This could trigguer the an error if the model name is already defined and, if not, add the model to the model list.

5. If the models are removed from the files, the line needs to indicate the model to use. For example, the line of a transistor is
   Q{instanceTitle} {net connector0} {net connector1} {net connector2} NPN_DEFAULT and it should be changed to Q{instanceTitle} {net connector0} {net connector1} {net connector2} {MODEL_NAME} where {MODEL_NAME} is the model to use.

6. If I understand the manuaL correctly, subcircuits can use local models. Can we allow local models when using a global-model approach.

My bigguest concern is that what it could work for some kind of devices, it could not work for others. For example, transistor and diodes use models, there are subcircuits and there are other devices that do not need models like resistors, voltage sources, etc. A part could require one line (a resistor or a transistor) and other several lines (e.g., potentiometers are two resistors, a 4x nand gate component needs four nand gate devices). Making something homogenous that works for all parts needs to be well thought.

Others:

The table is nice to give several spice models (e.g., a model for the 1n4001 diode, another for a Schottky diode, etc.), but as most models are proprietary we will not have a lot of them. There are some spice models available here (some of them are public domain, but not a lot of them): https://ngspice.sourceforge.io/modelparams.html

Making graphs for the diodes is nice, but too complex for being scalable (there are several parts to simulate).

Displaying the spice field could make sense, but it is probably too long. Maybe we should only show an alias of the model.

In my opinion, having all parts with modifible spice fields seems a big change that requires a lot of code. Thus, I am not sure if it is worth the effor as only a few people will use this functionality. But maybe you have a nice way of implementing these changes.